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

Annotations supply the safety profile (readOnlyHint=false, destructiveHint=true, openWorldHint=true, idempotentHint=false), and the description adds genuinely new context: the call consumes SEO add-on credits and how to top up. It does not explain why the tool carries destructiveHint=true (credit burn vs. data mutation) or what 'refresh' does, which is the remaining gap.

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?

Four compact sentences, front-loaded with what the tool does and its outputs before the usage hint and cost caveat. Nothing is redundant, though the parenthetical output list borders on filler given an output schema exists.

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?

The output schema means return values need not be spelled out, and the credit note is a useful operational detail. But for a paid, page-level audit with an unexplained 'refresh' flag, the description omits parameter semantics, caching/refresh behavior, and any error or scope limits a caller would need.

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 0% and the schema has two parameters (url required, refresh boolean with default false). The description never mentions either parameter, gives no URL format expectations (scheme, live vs. staging), and does not clarify when refresh should be set. With this much undocumented surface, the description fails to compensate.

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?

States a specific verb+resource ('Technical SEO audit of a page') and enumerates the concrete outputs (on-page score, Core Web Vitals, curated issue list). It is page-scoped, which implicitly separates it from site-wide siblings like seo_site_crawl, but it never names an alternative such as seo_audit or instant_audit, so sibling differentiation is left to inference.

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 it as a quality gate when building or fixing a website' gives a usage context, and the credit-cost warning implies cost-aware invocation. But it never states when NOT to use it versus the many overlapping audit siblings (seo_audit, instant_audit, seo_full_analysis, core_web_vitals), so routing remains guesswork.

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