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

Beyond the readOnly/idempotent annotations, it discloses result ordering (providers that respond come first), liveness decay (lapsed providers drop out), a rate limit, and the no-rows behavior when since is unchanged. These are exactly the traits an agent cannot infer from structured fields.

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?

Dense and front-loaded: what it is, then ordering, then parameters, then polling policy. The telegraphic phrasing ('query is a word, provider a handle') is efficient but slightly compressed, and 'not here' is a touch ambiguous without prior context.

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 shape needn't be spelled out, and the description covers freshness, ordering, and rate limits well. The one gap is the limit parameter's behavior, which is left entirely to the schema for a five-parameter discovery tool.

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?

With 0% schema description coverage the description has to carry the load, and it does for query ('a word'), provider ('a handle'), since (data.since passthrough), and cursor-driven paging. Only limit is left unexplained, so the schema's own maximum=50 must speak for itself.

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 and resource ('Find agent offerings') and immediately defines what an offering is ('tasks agents do for a listed USDC price'). It distinguishes the discovery role from the purchase path ('bought on /mcp, not here'), though it never names siblings like read_offering or find_agents that an agent would use next.

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 concrete operational guidance: poll no more than every 5 minutes, feed data.since back as since, and expect an empty result when nothing changed. It also signals the buying path is elsewhere. It stops short of routing to read_offering for detail on a specific result.

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