Fleet spend circuit-breaker

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden and discloses the key trait: this MCP tool refuses paid/metered work and routes elsewhere. It does not explain authorization requirements or the POST endpoint details, but the critical refusal behavior is clear.

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 wasted text, and the important refusal/redirect information appears immediately.

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 an empty-schema MCP tool that is meant to be refused over MCP, the description gives enough context to prevent misuse and redirect the agent. It leaves POST /authorize details unspecified, but those are outside this tool's scope.

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 an empty schema, so there are no parameter semantics to explain. The baseline for zero-parameter tools is appropriate here.

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 communicates that this tool relates to paid/metered work and is refused over MCP, but it does not clearly state what "authorize" itself would do or how it relates to sibling tools such as pricing or issue_envelope. The purpose is inferable but not fully specified.

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 explicitly says the tool is refused over MCP and directs the agent to use POST /authorize instead. That is a clear when-not-to-use rule plus a concrete alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does add one valuable fact: an operator Bearer token must be supplied in arguments.token. It does not say whether the call is read-only, whether it mutates or expires anything, or what happens when the envelope is exhausted.

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?

A single compact sentence with the primary payload (remaining envelope + per-leg status) front-loaded and the auth constraint trailing. Nothing is wasted.

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 tool with no annotations and no output schema, the description leaves too much open: what 'remaining' is measured in (count, currency, amount), what a 'leg' is, and the shape of the response. It is a terse hint rather than a usable definition.

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 coverage is 0%, so the description must compensate, and it only half does: 'token' is clarified as the operator's Bearer token, but 'envelope_id' receives no format, provenance, or sourcing guidance. An agent still does not know what an envelope_id looks like or where to obtain one.

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 resource (the remaining envelope balance) plus per-leg status, which an agent can distinguish from siblings like issue_envelope or verify_receipt. The verb is implied by the name rather than stated, so it falls short of a full verb+resource formulation.

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 statement of when to call this versus siblings such as verify_receipt or reconstruction, and no preconditions beyond the token requirement. The agent must infer that this is a post-issuance status check.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden, and it does disclose the two critical traits: calls are refused on this transport, and payment collection happens elsewhere. It stops short of saying what an agent actually observes if it calls anyway (error type, message, or cost), which would complete the picture.

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?

A single short line with the refusal front-loaded ahead of the redirect — nothing wasted. It is compressed to the edge of readability, though: the 'Paid work —' fragment and the bare 'x402' reference assume prior knowledge.

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 deliberately non-invocable stub with no annotations and no params, the description supplies what an agent needs: don't call it here, go to POST /envelopes. Only the exact failure behavior on a mistaken call is left unspecified.

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 schema has zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies the real inputs are supplied on the HTTP surface instead, but does not gesture at what those inputs are.

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 fragment 'Paid work' plus the name implies a payment/envelope-issuance operation, but the description never states what issuing an envelope actually does or returns. It does communicate the single most decision-relevant fact — that the operation is refused over MCP — which keeps it above tautology, but the functional purpose of the tool stays opaque.

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?

Explicitly tells the agent not to use this tool over MCP and names the correct alternative surface ('POST /envelopes' on the HTTP x402 surface). This is a clear when-not-to-use plus a redirect, though it points to a non-MCP endpoint rather than a sibling tool, so the agent is not given a routing equivalent inside the toolset.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full disclosure burden and delivers none: no indication of read-only behavior, authentication requirements, caching or rate limits, or what a caller receives. "Plan fences" implies feature-gating semantics that are never explained.

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?

Five words with zero padding, but the brevity comes from under-specification rather than efficiency. It is front-loaded yet too fragmentary to orient the caller.

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, no annotations, and no parameters means the description is the only source of truth, and it fails to explain what a "plan fence" is or what the response contains. An agent cannot confidently predict the return shape or whether the tool is safe to call.

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 zero parameters, and the schema is a fully described empty object, so there is nothing for the description to clarify. Baseline 4 applies for a no-parameter tool.

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?

"Product prices and plan fences" names a data domain but supplies no verb, so it is unclear whether the tool returns prices, evaluates plan gating, or both. It does not distinguish itself from siblings such as authorize or get_remaining, which could plausibly also surface plan-related information.

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 statement of when to call this versus alternatives like authorize or get_remaining, nor any prerequisite or exclusion. An agent must guess the routing based solely on the word "pricing," and "plan fences" is unexplained jargon.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does disclose the two critical traits: the operation is paid (x402) and MCP invocation is refused. It stops short of describing what the refusal looks like (error shape, payment headers/flow), which would be the final piece of behavioral context.

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?

A single sentence that front-loads the most decision-relevant fact ('paywalled, refused over MCP') before the redirect. Zero filler.

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, no-output-schema stub, the description gives an agent everything needed to make the right call: do not invoke, go to the HTTP endpoint and pay. Only the mechanics of the x402 payment step are left unspecified, which is a minor gap given the redirect nature of the tool.

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 zero parameters and the schema is an empty object at 100% coverage, so there is nothing for the description to disambiguate. Baseline 4 applies; the only implicit parameter, the envelope id, is surfaced via the endpoint example.

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 signals that this tool is a payment-gated 'reconstruction' operation and that it will not run over MCP, and the referenced endpoint '/envelopes/<id>/reconstruction' implies the resource. However, it never states what reconstruction actually produces or why an agent would want it, so the purpose is only inferable from the URL fragment.

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 explicitly says not to use this tool over MCP and names the exact alternative path: GET /envelopes/<id>/reconstruction with x402 payment. The when-not-to-use condition and the substitute are both stated outright, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden, yet it does not say whether verification returns a boolean, raises on an invalid signature, requires a trusted key, or checks freshness/expiry. It only implies the operation is read-only by virtue of 'verify'.

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 short phrase with no wasted words, but it is under-specified rather than effectively concise. There is no front-loaded detail beyond the basic 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?

For a tool with a nested object parameter, no output schema, and no annotations, the description is far too thin. It omits response semantics (valid vs. invalid outcome) and receipt structure, both of which an agent needs to invoke it 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?

Schema description coverage is 0% and the single required parameter 'receipt' is a nested object, so the schema provides no field-level meaning. The description never explains the expected receipt structure (signature, entry, key material, encoding), leaving an agent unable to construct a valid call.

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 and resource: 'Verify a signed log-entry receipt'. An agent can tell it is a verification operation on a receipt, though it never distinguishes this from sibling tools such as issue_envelope or reconstruction.

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 guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. 'Verify a signed log-entry receipt' implies its purpose but says nothing about selecting it over, e.g., issue_envelope.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.