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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description layers on material behavior the schema cannot express: no billing will ever occur, visibility is restricted to the caller's plan/org key, the tool currently degrades to an argument check plus bearer_required, and a null decision must be treated as unknown rather than a pass under the caller's fail_mode. That is exactly the kind of non-obvious, decision-affecting disclosure this dimension rewards.

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?

Three tight sentences with no filler, and the most decisive facts (free, private, bearer required, null handling) are front-loaded. The opening 'FREE, never charged' leads with billing rather than capability, which slightly delays the core purpose.

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, the description carries the burden of return semantics and does explain the decisive output value (decision, including the null case). Combined with the auth caveat, an agent can call this and interpret the result correctly. Other response fields beyond decision remain unspecified, but the failure-critical one is covered.

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 75%, so the baseline is 3, and the description adds nothing about how host, quote, resource_url, or the nested mcp object interact — notably that resource_url supplies host when host is absent, which is only visible in the schema. No compensating explanation of the nested quote fields appears in prose.

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 description names a specific operation: applying the caller's own pass/warn/block rules to BotsRated measurements, scoped privately to a plan or org key. That is a clear verb+resource statement. It does not, however, distinguish itself from the similarly named siblings 'check' and 'preflight', leaving the agent to infer the boundary.

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 operational context: the tool is free, is scoped to your plan/org key, and while MCP auth is unavailable it will only validate arguments and return bearer_required, with the actual call going to POST /v1/policy/check using a Bearer token. That is unusually explicit guidance on prerequisites. It never names an alternative sibling or states when not to use it, which keeps it out of the top band.

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