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

Annotations already indicate read-only, idempotent, non-destructive. The description adds crucial behavioral details beyond that: the 165 pure-CPU tools execute free with rate-limiting and proof-of-work; wallet-only tools return a paid-access setup guide; the connector holds no wallet; and unknown slugs produce an error. These are operationally important and not inferable from the schema or 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 front-loaded with the primary action, then delivers discovery guidance, free vs wallet-only behavior, and error handling – all in compact, dense sentences. No filler; each sentence contributes essential information. Long enough to be complete, short enough to read quickly.

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 role as a generic executor, the description covers the key aspects: how to identify slugs, parameter matching, fee structure (free vs wallet-only), rate limits, wallet absence, and error behavior. The output schema exists to explain return values, so that omission is acceptable. The description is complete for its complexity.

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 coverage is 100% (both slug and params have descriptions). The description adds value by explaining how to obtain valid slugs (via catalog.find/search) and reinforcing that params must match the target tool's inputSchema. This context goes beyond the schema's simple field labels, though the baseline is already high due to full coverage.

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 verb and resource: 'Run an Agent402 tool by slug' – it performs execution based on a slug. It differentiates from sibling discovery tools by saying 'discover slugs with catalog.find or catalog.search', making it obvious this tool runs tools rather than finds them. The purpose is unambiguous and distinguishes itself from the catalog search/find family.

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?

Explicit guidance is given: discover slugs with catalog.find or catalog.search, then run with this tool. It also explains when NOT to use it – for wallet-only tools it returns a setup guide instead of executing, and unknown slugs point back to catalog.search. This is clear when-to-use vs alternatives, with exclusions and error handling.

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