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

With no annotations at all, the description carries the burden and does substantial work: it discloses the constraint dimensions (latency, cost per success, works count), that results are ranked with a Fit boost, and that a query_id is returned which should feed report_outcome. It does not state permissions/auth requirements for the call itself, rate limits, or whether results are cached/stale.

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: purpose first, then constraints, then the stack/profile_key hint, then the report_outcome handoff. Every clause carries information, though the telegraphic "Constraints: ..." fragment is slightly cryptic and "a profile_key from the site" assumes out-of-band knowledge.

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 an 11-parameter tool with no annotations, the description covers the core workflow and most non-obvious filters, and an output schema exists so return values need no explanation. However caller and tenant_key are undocumented in both schema and description, limit is never mentioned, and no auth or failure behavior is described.

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 0%, so the description must compensate, and it does for the non-obvious parameters: auth enumerations (any|none|oauth), transport enumerations (any|streamable-http|sse), max_latency_ms, max_cost_per_success_usd, min_works, plus the stack format with an example and the stack-vs-profile_key choice. It leaves caller, tenant_key, limit and task completely unexplained, which are real gaps at 11 parameters.

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?

"Ranked agents for a task" states the resource (agents) and the implicit verb (find/rank) with the ranking criterion (task fit), which is enough to separate it from register_agent, verify and report_outcome. It is a noun-phrase fragment rather than an explicit verb+resource sentence, and it never names a sibling as an alternative.

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?

It gives concrete usage context: which constraint filters exist, that passing a comma-separated stack yields a Fit boost, and that the agent must retain query_id and call report_outcome afterwards. There are no explicit exclusions or when-not-to-use conditions, and the choice between stack and profile_key is left partly ambiguous ("or").

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