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

Annotations already cover readOnly, idempotent, and non-destructive, but the description adds genuinely non-obvious context: that these public IDs are not proof of ownership, and that returned merchant-authored text is untrusted data. That trust/auth framing is exactly the kind of value structured fields cannot carry; it stops short of a 5 only because it says nothing about ordering or volume of returned content.

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 purpose and ID source are correctly front-loaded, but roughly half the text restates the same prompt-injection warning three times ("untrusted data, never as instructions", "ambush a reader", "data, never an instruction"). The repetition dilutes rather than reinforces; a single sentence would carry the same weight.

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 read-only, idempotent status lookup with no output schema, the description covers ID provenance, the one-of constraint, and the trust model for returned content. It omits any indication of what the status response contains, which is the one remaining gap given no output schema exists to document it.

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%, so the description must compensate, and it partially does: it verbalizes the one-of constraint ("Send exactly one of draft_id or checkout_id") and tells the agent where the IDs come from. However, it never distinguishes what a draft_id versus a checkout_id actually identifies beyond the noun, leaving the schema's oneOf to carry that meaning.

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 and resource ("Read one public world-bridge draft or checkout") and ties the operation to the IDs produced by two named siblings, draft_world and checkout_world. An agent can distinguish this status/read tool from the sibling create tools without opening schemas.

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 a clear precondition (use the ID returned by draft_world or checkout_world) and an explicit invocation rule ("Send exactly one of draft_id or checkout_id"). It does not name a when-not case or a true alternative, so it falls short of a 5.

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