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

Discloses rich behavior beyond the annotations: shared 24-hour cache, that a miss/expiry or fresh:true triggers a billed external Instant Pages request, that fresh:false is not cache-only and retry can repeat work, that no Scan allowance is consumed, and that nullable metrics mean unavailable rather than zero. This explains why the operation is non-idempotent while still a read-style tool, aligning with rather than contradicting the annotations.

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?

Dense but front-loaded, leading with the resource and its contents before qualifications. Every sentence carries operational value (scope, nullability, cache, billing), though the enumeration and caveats make it longer than strictly necessary.

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?

An output schema exists, so return values needn't be detailed; the description still summarizes them. It also covers the caveats an agent needs (single-page scope, nullable semantics, caching and billing) so nothing material is missing for correct invocation.

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 documents both params, setting the baseline at 3. The description adds meaning beyond that by clarifying fresh behavior in operational terms (cache miss/expiry, billed request, retry can repeat work) and by noting no siteId is required.

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?

Names a specific verb+resource (technical/SEO audit of a single page) and enumerates exactly what the audit contains: on-page score, HTTP status, meta, links, images, Core Web Vitals, and detected issues. It carves out a distinct scope ("Audits ONE page (not a whole site)") that clearly separates it from siblings like get_seo_backlinks, get_seo_keyword_metrics, and get_seo_search_results.

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?

States the purpose explicitly ("Use it to check whether a specific page is well-optimised") and sets a boundary against whole-site audits and raw provider checks. However, it never names a specific sibling tool as the alternative when a full-site or keyword-level view is needed, so an agent must map that intent itself.

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