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

No annotations are provided, so the description carries the full burden. It does usefully disclose HTTP verbs, letting the agent distinguish safe reads (read, watch_read, fork_draft, renewal_draft, download) from mutations (recheck, fork, watch_update, renew), and it flags written actions that require idempotency_key or agent_key. It says nothing about permissions, rate limits, reversibility, or side effects of renew/fork/recheck.

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 action list is front-loaded and each endpoint entry is a compact, information-dense fragment with no filler. It is long, but the length tracks nine distinct actions, and no sentence restates another. Formatting as a flat run-on list rather than per-action lines slightly hurts scannability.

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 nine-action multiplexer with no output schema and no annotations, the description documents routes and bodies but says nothing about return payloads, error modes, or what a 'passport' or 'fresh check' actually yields. An agent can construct a call but cannot anticipate results or failure conditions.

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 only 9%, so the description must compensate, and it partly does: body fields are spelled out for fork (title, description, category, amount_usd), watch_update (enabled), and renew (idempotency_key, optional amount_usd), and it notes idempotency_key may travel in the body or the Idempotency-Key header. However, six parameters (id, handle, wanted_id, transfer_id, delete_credential, payment_signature) and agent_key remain undocumented in both the schema and the description.

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 names a concrete resource (saved output passport) and enumerates nine specific actions with their HTTP routes, so an agent knows exactly what the tool operates on. It does not need sibling differentiation since no sibling tool touches passports. It stops short of 5 only because the action vocabulary (recheck, fork_draft, renewal_draft) is not explained in plain terms.

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 explicit when/when-not guidance, but the pairing of *_draft GET routes against their POST counterparts (fork_draft vs fork, renewal_draft vs renew) implies a draft-then-commit workflow. The agent can infer the sequence but is not told which to prefer or under what conditions a real renewal is warranted versus a draft.

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