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

Beyond the readOnlyHint and destructiveHint annotations, the description explicitly states that this server never places, modifies, or cancels orders and never touches payments, and that the merchant remains merchant of record. This adds valuable behavioral disclosure that is not present in the structured annotations.

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, dense paragraph that packs in a lot of information without being overly long. It is front-loaded with the core purpose ('One plain state of THIS server') and each clause contributes meaningful detail. Slightly less concise than a two-sentence example but appropriate for the complexity.

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?

Given the tool has no parameters, rich annotations, and an output schema, the description is complete. It covers the tool's scope (what it reports), its safety guarantees, and its role as a preflight check. It does not need to enumerate return values because the output schema exists, and the description fully compensates for any missing details.

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, so the baseline is 4. The description adds meaning by explaining what the tool reports (provider, protocols, needs, affiliate state, ready status), even though no parameter details are needed. It helps the agent understand the output's conceptual structure.

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 clearly states the tool's purpose: to report the server's commerce readiness state, including provider configuration, protocols, and affiliate state. It uses specific terminology (UCP, ACP) and distinguishes itself from sibling tools (e.g., build_affiliate_buy_link, compare_product_offers) by focusing on server-level status rather than product/offer actions.

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 description implies usage context: use before live evidence is available ('preflight evidence only') and as a read-only check. It does not explicitly name alternatives or when not to use, but the scope is clear enough to infer that it's for assessing the server's readiness rather than performing merchant actions.

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