Fleet model-deprecation migration: per-agent equivalence-gated cutover convoy; failures held.
Scored across 7 tools
The core pipeline (screen → readiness → port → cutover) and the off-path tools (status, ledger, disposition) each have a distinct role, and descriptions explicitly clarify boundaries such as screen being ordering-only versus readiness being a verdict. The main soft spot is the readiness/screen/status triangle, where an agent may hesitate over which to call first since readiness composes inventory + screen.
All seven tools share a uniform convoy_ prefix with snake_case names, which is highly predictable. The only minor deviation is mixing action verbs (cutover, port, screen, disposition) with resource nouns (status, ledger, readiness), though each remains readable and unambiguous.
Seven tools is well within the ideal 3-15 range for a domain workflow. Each tool maps to a discrete stage or view of the migration lifecycle, so nothing feels padded or missing on count alone.
The surface covers screening, readiness, porting, cutover, disposition of held agents, plus status and ledger visibility, which is a solid lifecycle. However, there is no rollback/revert operation after a cutover, and no explicit agent inventory/listing tool separate from the aggregate status view, which are notable gaps for a deprecation-migration workflow.
Cut over an agent that passed its equivalence gate. Held or ungated agents are refused.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses a gating/refusal behavior, which is real behavioral context beyond the schema, but it omits whether the cutover is reversible, what state it mutates, required permissions, and whether it is asynchronous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero redundancy, with the action front-loaded and the refusal condition immediately following. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and an undocumented parameter, the description leaves notable gaps: what cutover entails, its side effects, and how to identify an agent. The gate/refusal rule is the one piece of genuinely necessary context covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single parameter 'agent', and the description does not clarify what value to pass — an agent ID, name, or gate identifier. The description only implies the agent is the thing gated, adding almost no meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (cut over) and resource (an agent), plus the precondition that the agent passed its equivalence gate. It is distinguishable from opaque siblings like convoy_disposition or convoy_screen, though the description never says what a 'cutover' concretely changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit eligibility condition (passed equivalence gate) and an explicit exclusion ('held or ungated agents are refused'). It stops short of naming an alternative tool to use when the agent is held or ungated, so the routing is only partially complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disposition a held agent: pin-and-pay, retire, or accept-and-flag (ack bound to the exact failing set).
| Name | Required | Description | Default |
|---|---|---|---|
| ack | No | ||
| kind | Yes | ||
| agent | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full safety profile. It implies a state-changing disposition and gives one constraint for ack, but it does not say whether retire or pin-and-pay are irreversible, what permissions are required, or what side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler, and the colon and parenthetical organize the options compactly. It is dense and jargon-heavy, but it remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing tool with no annotations and no output schema, the definition is too thin. It gives enough to identify the tool but lacks consequences, selection guidance, and parameter formats needed to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description is the main source of parameter meaning. It supplies the likely kind values and constrains ack to the exact failing set, but leaves the agent parameter format and exact accepted strings undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and target resource: dispositioning a held agent. It also enumerates three disposition modes, which makes the tool distinguishable from generic status or readiness siblings. It does not explicitly contrast itself with those siblings, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'held agent' implies the triggering context, and the three named outcomes signal the available choices. However, it gives no criteria for choosing among pin-and-pay, retire, and accept-and-flag and no explicit when-not or sibling alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Your append-only convoy ledger entries.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full disclosure burden, yet it only implies immutability via 'append-only' and says nothing about whether entries are read or written, how many are returned, pagination, or ordering. For a zero-annotation tool this is a substantial gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is a single short sentence with no filler, so it is concise and front-loaded. However, its brevity comes from under-specification rather than disciplined editing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is the only place an agent could learn what the call returns and how to use it, and it provides neither. The zero-parameter surface keeps this from being worse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters and the schema is empty at 100% coverage, so there is nothing for the description to compensate for. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description reads as a noun phrase ('Your append-only convoy ledger entries') rather than naming an operation, so the agent cannot tell whether it lists, retrieves, or appends entries. 'Append-only' adds a property but no verb+resource pairing that distinguishes it from convoy_status or convoy_readiness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no indication of when to call this versus the six sibling tools, and no prerequisites or exclusions are stated. The agent must infer its role in the convoy workflow from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Port one agent's configuration to the successor model.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, but it only implies a migration/mutation. It does not disclose permissions, reversibility, what happens to the original configuration, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is a single front-loaded sentence with no wasted words. It is appropriately concise, though its brevity contributes to gaps handled in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a migration tool with no annotations, no output schema, and an undocumented required parameter, the description is too sparse. It does not explain effects, return behavior, or parameter expectations sufficiently for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter is named "agent" and the description indirectly indicates it identifies the agent whose configuration is ported. However, schema description coverage is 0%, and the description adds no format, identifier type, or example for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb, "Port", and resource, "one agent's configuration", with the target being the "successor model". It is clear enough to distinguish from ledger/status/readiness siblings, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the operation is for migrating agent configuration to a successor model, but gives no explicit when-to-use guidance, prerequisites, or alternatives among the convoy_* tools. An agent must infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Readiness verdict for one agent (inventory + screen). First verdict free once per operator; paid verdicts settle over x402 on POST /readiness.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, it still discloses pricing (first verdict free once per operator) and payment settlement over x402 via POST /readiness. But it omits whether the call creates or mutates state, idempotency behavior, and what happens on payment failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loading the verdict purpose before payment details. No wasted words, though the payment sentence could be contextualized more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description never describes verdict shape or fields; parameter semantics also lack format details. For a paid verdict endpoint with no annotations, this leaves key call-preparation information missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole `agent` parameter has 0% schema description coverage, and the description only says 'for one agent' without specifying identifier format or source. It adds little beyond the schema's string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States it returns a readiness verdict for a single agent and clarifies it combines inventory and screening. It is a specific resource, though it does not explicitly position itself against siblings like convoy_screen or convoy_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions only free-first-once and x402 payment; it gives no guidance on when to call this versus convoy_screen/status or on prerequisites such as inventory needing to exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the metadata sensitivity screen; returns convoy order, most fragile first. Ordering only - never an equivalence result.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose the return ordering ('most fragile first') and an important constraint ('never an equivalence result'). However, it does not clarify whether the screen is read-only, has side effects, or has any execution constraints beyond the output semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short clauses with no wasted words, and the key return semantics and constraint are front-loaded. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema and no annotations, the description gives the essential return behavior and an explicit exclusivity constraint. It remains slightly terse about what the metadata sensitivity screen actually inspects, but it is complete enough to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so there are no parameter semantics to explain. Baseline 4 is appropriate because no additional parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (run the metadata sensitivity screen) and a specific output behavior (returns convoy order, most fragile first). It also distinguishes the result from an equivalence result, though it does not explicitly differentiate itself from named sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a boundary condition ('Ordering only - never an equivalence result') that implies when not to use it, but it does not name alternatives or explain when this tool should be chosen over its siblings. Usage is therefore only partially implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Your convoy status: per-agent states, sequence, at-risk list, meter.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the full behavioral burden. It lists return components but does not state whether this is read-only, what permissions are needed, or whether it has side effects. Read-only is implied by 'status' but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the resource, and uses a compact list to describe return components. No redundant text, but it is extremely terse and may be under-specified for the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no parameters, the description should fully explain the tool's behavior and return structure. It lists components but does not explain what they mean or when to use the tool, leaving gaps for an agent unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters; schema description coverage is trivially 100%. Description adds no parameter information because there are none, so baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description names the resource ('convoy status') and lists specific return components (per-agent states, sequence, at-risk list, meter). However, it lacks a verb and does not differentiate from siblings like convoy_readiness or convoy_screen, so an agent cannot easily tell which status-related tool to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no alternatives mentioned, and no conditions for calling this tool vs other convoy_* siblings. Implied usage only from the name and return list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
convoy_cutoverconvoy_dispositionconvoy_ledgerconvoy_portconvoy_readinessconvoy_screenconvoy_statusSalvageability triage for agent fleets in a declared mass-failure mode.
Checkpoint-paired twin trials for agent fleet changes with blinded verdicts.
Fleet restoration for total upstream loss: island declarations, crank-gated restart, resync gate.
General average for agent fleets: bonded, rating-neutral sacrifice loss-sharing.
Add one secure layer between your agents and this server.
