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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so the safety profile is covered. The description adds behavior the annotations cannot: that the call mutates conversation context rather than remote state, and that each reference consumes significant tokens. It does not clarify whether some references require ad_account_id or what the returned payload looks like, which keeps it below a 5.

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?

Front-loaded with the action and purpose, then a scannable enumeration of references, then the token-cost warning. The opening sentence ('A Meta ads audit framework and its benchmarks, for a thorough account review') slightly restates the title and the next sentence before the substantive content begins.

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 two-parameter, no-output-schema knowledge loader, everything an agent needs is present: what each document contains, when to load it, and the context-budget cost. The only unresolved point, the role of ad_account_id, is minor given the parameter is optional and already documented in the 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 coverage is 100%, so baseline would be 3, but the description meaningfully expands every enum value — something the one-line schema description ('The reference document to load') does not do. The one gap is ad_account_id, which is never mentioned in the description, leaving an agent to wonder whether benchmarks or scoring require it.

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 ('Load a deep-knowledge reference document into conversation context') and immediately enumerates the five concrete documents available with their contents (7-step audit framework, 50-point checklist, benchmarks, scoring system, summary). This is clearly distinguishable from every sibling tool, which fetch live ad-account data rather than static knowledge documents.

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?

'Use when you need detailed frameworks, checklists, or benchmarks for a thorough analysis' gives a clear trigger condition, and 'Only load what you need — each reference adds significant tokens to context' adds a real cost-based caution. It stops short of naming when NOT to load (e.g. use get_campaigns instead when the user wants raw metrics), but the read-vs-reference split is strongly implied by the reference list.

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