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

With no annotations, the description carries the full disclosure burden, and it does add two genuinely useful facts: a bearer API key is required on the MCP HTTP request, and an empty result means 'no match' rather than 'verified clean' — a distinction that could easily cause a wrong conclusion. It says nothing about rate limits, result shape, or how pagination interacts with a large match set.

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 short sentences, front-loaded with the scope statement, and the auth requirement is placed before the result caveat. No filler, though the empty-result sentence is slightly long-winded relative to the point it makes.

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?

Seven parameters, no annotations, and no output schema, so the description must shoulder a lot — and it does not describe what a Truth Packet result contains or how offset/limit relate to a total count. The auth and empty-result notes cover the two highest-risk misunderstandings, leaving the definition adequate but incomplete for a discovery tool with no output schema.

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 86%, so the schema already documents q, lat, lng, radius, limit, and offset well enough for correct invocation. The description adds no parameter-level meaning (no note on how tier values like ENCRYPTED affect licensing, or that geo filters require all three of lat/lng/radius). Baseline 3 applies when the schema does the heavy lifting.

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 (search) plus a tightly qualified resource: 'HQ-approved, opted-in Truth Packets available for commercial licensing.' That is far more precise than the bare name 'search_catalog' and implicitly separates it from siblings like generate_license_quote or verify_media_hash. It stops short of naming any sibling explicitly, so it is clear but not fully differentiated.

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?

Usage is implied by the licensing framing rather than stated: an agent can infer this is the discovery step before quoting or dispatching a bounty, but no when/when-not or alternative routing is given. The only explicit guidance concerns interpreting an empty result set, which is result semantics rather than selection guidance.

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