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.