audit_page

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

With no annotations supplied, the description carries the full burden and does well: it discloses SSRF guarding, robots.txt compliance, bounded fetching, and a fail-closed policy where an unreadable page yields no score. The return contract is also described (evidence per element, copy-paste fix per miss). What remains unstated is rate limiting, timing, and whether a robots-disallowed page counts as 'unreadable' under the fail-closed rule.

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 sentences, each earning its place: capability, return shape, failure mode. The parenthetical guard clauses are compressed efficiently and the fail-closed rule is placed last where it reads as a caveat. No filler or repetition of the tool name.

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 steps in to describe what comes back: per-element evidence plus a fix for every miss. The fail-closed behavior closes the main edge case. Slightly incomplete on robots-disallowed handling and on the fact that there is no sibling cross-reference, but the essential picture is there for a one-parameter tool.

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% and there is a single required url parameter whose schema description already gives the accepted form ('Domain or URL, e.g. example.com'). The prose adds nothing further about the parameter, so the schema does the work; baseline 3 applies. It does not clarify whether a bare domain gets a protocol prepended or which page is audited in that case.

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 uses a specific verb pair (fetch and score) against a specific resource (one public web page) and names the exact framework applied: 20 on-page elements that AI search tools read. That is unambiguous. It does not reference the sibling tool explain_check, so the agent gets no explicit differentiation between auditing a page and explaining a single check.

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 rather than stated: 'one public web page' signals the single-page scope and the 'public' qualifier implicitly excludes internal or authenticated pages. There is no explicit guidance on when to choose audit_page over explain_check, and no statement of prerequisites or limits beyond the word 'bounded'. An agent can infer the use case but must guess at the boundaries.

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