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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it discloses auth requirements (OPEDD_BUYER_TOKEN or OPEDD_BUYER_JWT), row shape, when inclusion_proof appears, the default inclusion behavior, and the 30-day window cap. It also explains that no separate flag is needed, preventing a likely misinvocation.

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?

The main purpose, filters, window cap, row contents, and auth are front-loaded and dense with useful info. Minor noise exists in internal references like 'Phase 9.x' and 'M6.4 consolidation per founder ratification' — these add historical context but do not help an agent select or invoke the tool correctly.

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 tool with no output schema and no annotations, the description explains the endpoint, auth, filtering, window limitation, row contents, attestation semantics, and default inclusion behavior. An agent has enough contextual information to call this tool correctly and interpret its response; nothing critical is missing.

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?

The input schema already describes all five parameters at 100% coverage, so the baseline is 3. The description adds meaningful beyond-schema semantics by specifying the 30-day window cap that constrains from/to, and by enumerating the event_type options. This is useful context that the schema alone does not provide.

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 states a specific verb and resource ('Browse per-event audit rows for the authenticated buyer via GET /buyer-audit'), names the row contents, and distinguishes itself from get_compliance_dossier by the 30-day vs 90-day window cap. An agent can immediately tell what this tool does and how it differs from its closest sibling.

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 gives clear context: optional event_type filtering, the 30-day window cap, and a direct comparison to the 90-day cap on get_compliance_dossier. It implies when to choose this tool over the sibling, though it stops short of an explicit 'use this when X, otherwise use Y' rule or a list of exclusions.

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