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

With no annotations, the description carries the full burden and does disclose key traits: unavailability yields HTTP 503 rather than fabricated zeros, there is a $0.001 per-call cost via MPP, and legacy fields are reinterpreted (services_listed counts records; tasks_routed means assigned tasks). Auth requirements and rate limits remain unstated.

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?

Two tight sentences, purpose front-loaded followed by failure/cost caveats and field clarifications. Some phrases ("cohort attribution," "independent economic evidence") are jargon that isn't unpacked, but nothing is redundant.

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?

With no output schema and no parameters, the description is the sole source of return-value context; it names only two of the presumably many stat fields and leaves phrases like "cohort attribution" and "freshness" undefined. Enough to decide to call it, but not enough to interpret the response confidently.

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 takes zero parameters, which sets the baseline at 4. The description instead clarifies the semantics of returned fields, which is useful but belongs to return-value explanation rather than parameter 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?

Starts with a specific verb+resource ("Get recorded marketplace statistics") and adds qualifying scope (cohort attribution, listing/service inventory, economic evidence, freshness). It never names a sibling tool, so differentiation from get_leaderboard or get_capabilities is left to inference, but the object itself is identifiable.

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 only routing guidance is "Free over REST: GET /api/stats," which tells the agent there is a cheaper alternative path, but not when to prefer this tool over siblings like get_leaderboard. No explicit when-to-use or when-not-to-use statement.

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