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

Beyond annotations (readOnly=false, destructive=false, idempotent=false, openWorld=true), the description discloses a paid operation with a two-step flow, a specific payment amount (0.50 USDC on Base), and explicit limitations: 'payment does not guarantee placement, a ready grade, traffic, ranking, purchases, or safety.' It also warns that 'Ontario is not Coinbase,' adding important context beyond what annotations provide.

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 with many clauses and disclaimers, making it hard to scan. It front-loads the usage condition but then becomes verbose with long lists and payment instructions. It could be structured with bullets or sections for clarity, but it is not concise.

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's complexity (15 parameters, paid, two-step flow), the description covers the critical contextual aspects: prerequisites, payment flow, and disclaimers. However, it does not explain many parameters or the output structure (though an output schema exists). It is complete enough for an agent to understand the operation but leaves gaps in parameter understanding.

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 13%, so the description must compensate, but it only explains _x402_payment and implicitly price_usdc. It details the two-step payment flow but omits meaning for the other 13 parameters like name, tags, endpoint, buyer_query, etc. With such a low coverage, the description fails to convey the purpose of most fields.

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 is for obtaining a public Bazaar launch passport with a comprehensive set of services, and the title says 'Publish'. It distinguishes the tool from Coinbase, but does not explicitly contrast it with sibling tools. The verb 'publish' and resource 'passport' are clear, though the scope overlaps with other Ontario tools.

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 gives explicit conditions: 'Use only when the caller owns an x402 endpoint and wants a public Bazaar launch passport...' It also instructs to 'Validate and run the free audit first' and 'run free can-pay and readiness checks first' before paying, which implicitly references sibling tools like agent_can_pay and x402_readiness_verify. It sets clear exclusions: 'payment does not guarantee placement...' providing strong guidance on when to use.

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