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

Beyond the readOnly/idempotent annotations it discloses concrete behavior: it never starts an audit, spends credits or publishes, and it reports missing evidence and ambiguous page matches explicitly rather than silently guessing. It also states output-contract rules (no free/guarantee/rating claims unless confirmed, audit suggestions are not verified facts, no placeholders like $X, don't infer a free quote from a form alone). That is substantial disclosure the structured fields do not carry.

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 content mostly earns its place, but the ordering is poor: usage and output-discipline rules are front-loaded while the actual 'what this does' sentence sits mid-paragraph. Several hyper-specific rules ('a quote form alone does not mean a free quote') read like skill content rather than tool documentation, bloating the definition's surface.

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 6 params at full schema coverage and no output schema, the description appropriately explains the return contract ('source material for you to turn into the requested deliverable') instead of enumerating fields. It covers safety, scoping and failure modes; the only gap is that parameter usage is left almost entirely to 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 description coverage is 100%, so the schema already explains page, skill, latest, context, section and audit_id thoroughly, including the dashboard-link extraction rule. The description adds essentially no new parameter-level syntax or semantics beyond the 'one change for a first-fix request' hint, so the baseline of 3 applies.

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 concrete operation: 'Finds an existing audit by page URL or client name and retrieves the selected skill plus its relevant evidence in one call.' It also delimits itself from adjacent tools by clarifying it 'returns source material... not a new AI analysis' and 'never starts an audit' — a real distinction from audit_page/ask_audit/list_cro_skills. However, the actual purpose statement is buried mid-description after a block of output rules, and no sibling is named by name.

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 opens with an explicit trigger list: 'Use when the user wants page fixes, message match, buyer objections, copy rewrites or a client test brief,' which maps cleanly onto the five skill enum values. It also gives per-skill selection guidance via the schema and a scoping rule ('Use one change for a first-fix request'). No explicit 'when not to use' or named-alternative routing is given, so it stops short of a 5.

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