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

Annotations already declare the safe-read profile, yet the description adds real operational context: stub endpoints return HTTP 501, payments_enabled currently reflects whether the platform charges (false today), and the status taxonomy. This is behavior an agent cannot get from the annotations or an empty parameter schema.

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?

Front-loads the purpose and the status vocabulary before the usage guidance, and every sentence carries information. The mid-sentence enumeration of covered areas (badges, x402 relay, billing) is slightly list-heavy but earns its place as feature coverage.

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?

An output schema exists, so return values need no explanation, and the description supplies the remaining context an agent needs: it's parameterless, read-only, non-listing, and how to interpret stub states and payments_enabled.

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?

Zero parameters, so the 4 baseline applies. The description reinforces this with 'Read-only, no parameters,' which is a useful confirmation despite adding no new semantics beyond the empty schema.

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 (list) and resource (Agentropolis platform features) with the enumerated status vocabulary (live, partial, stub, planned), and explicitly bounds the scope: 'it describes Agentropolis itself, not listings.' This distinguishes it cleanly from siblings like get_market_snapshot, list_categories, or search_kits.

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 an explicit trigger ('check whether a platform capability exists before relying on it') and an explicit exclusion ('describes Agentropolis itself, not listings'), which is exactly the disambiguation an agent needs against the listing/market siblings. No inference required.

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