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

Annotations already cover read-only/idempotent/non-destructive, and the description adds genuinely new behavior: the tool returns source material rather than a new AI analysis, and missing evidence or ambiguous page matches surface explicitly. The content constraints (no unverified free/guarantee/rating claims, no placeholders like $X) further constrain behavior in ways annotations cannot express.

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 core purpose sentence is placed after usage and several output-style policy sentences, so the description is not front-loaded around what the tool is. Much of the content (never add free/guarantees, don't use $X placeholders) reads as prompt/behavior rules that inflate a tool description rather than earning each sentence as tool-selection help.

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 appropriately describes the return ('source material for you to turn into the requested deliverable, not a new AI analysis') and the error behavior for missing evidence and ambiguous matches. Combined with a fully documented 6-param schema, an agent has enough to call it correctly.

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 100%, including enum semantics for skill and section, so the schema does the heavy lifting and the baseline is 3. The description only adds the page-vs-audit_id resolution hint already present in the schema, so it adds little parameter meaning beyond structured fields.

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 contains a specific verb+resource statement: 'Finds an existing audit by page URL or client name and retrieves the selected skill plus its relevant evidence in one call.' This clearly separates it from generative siblings, but it is buried after usage and content-policy prose, and it never names a sibling (e.g. get_audit) as the 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?

Opens with an explicit when-to-use trigger ('Use when the user wants page fixes, message match, buyer objections, copy rewrites or a client test brief') and adds selection conditions for first-fix vs. full rewrite vs. experiment brief. It also states exclusions ('never starts an audit, spends credits or publishes') and the one-change rule for first-fix requests.

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