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

The annotations already cover read-only and open-world behavior. Beyond that, the description discloses two things the schema cannot: results are ranked by Mixcloud and can change between calls (non-determinism), and each call costs 1 credit (cost profile). This is exactly the extra context that matters for a metered search.

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?

Four short sentences with no padding; the cost and volatility notes are front-loaded and easy to scan. The only waste is the redundant one-word 'Search.' opener.

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?

For a 5-parameter search with no output schema, the description omits result shape hints, pagination flow via cursor, and what limit and cache_max_age control. It is adequate to call the tool, but not complete for an agent that must manage pagination and caching.

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 60%, with type and query documented, and the description echoes the three resource kinds but adds no mapping beyond the enum values. Two parameters, limit and cache_max_age, get no explanation in the schema or the description, so the coverage gap is not compensated.

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 second sentence names the resource set precisely: search Mixcloud uploads, users, or tags. This distinguishes it from single-type siblings such as mixcloud_tag, mixcloud_upload, and mixcloud_userUploads. The leading standalone 'Search.' adds nothing, which keeps it out of the 5 tier.

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 never says when to use this tool vs. alternatives. It gives no guidance on choosing mixcloud_search over mixcloud_tag or mixcloud_userUploads for a specific lookup. The choice is left entirely to inference from the type parameter.

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