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

Annotations only declare readOnly=false, openWorld=true, idempotent=false, destructive=false; the description goes far beyond by disclosing runtime (15–30 seconds), a quota ('10 free checks per day per account'), what the submitted page is tested against, and how the AI-Q&A test behaves (answers must quote the page, guesses are flagged). Nothing contradicts the annotations — the non-read-only hint is consistent with a quota-consuming check.

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?

Front-loaded with the purpose and outcome, with use-case and quota details trailing in short sentences. It is dense — the long parenthetical checklist of checks packs a lot into one sentence — but essentially every phrase maps to a capability an agent needs, so little is wasted.

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?

Because no output schema exists, the description correctly compensates by listing the returns (0–100 score, top 3 issues with fixes, unanswered questions, a video idea). It omits that the result is persisted and retrievable via get_product_check/get_analysis, a small but real gap given the sibling set.

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?

There is a single parameter with 100% schema description coverage ('Public link to a product page on the brand's store... or a marketplace listing'), so the schema carries the full burden. The description adds no constraint on the URL itself — no note about accessibility, auth-protected pages, or non-product URLs — so it contributes nothing beyond the schema, though the 100%-coverage baseline lifts this above the minimum.

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 concrete verb and resource ('Free check of how AI assistants and AI search see a product page') and enumerates the exact checks performed (robots.txt/CDN bot walls, no-JS rendering, Product structured data, media, 10 shopper questions). This clearly separates it from siblings like check_ai_bot_access (bot access only) and get_product_check (retrieval).

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?

Gives explicit triggering conditions: 'Use when the user shares a product page link and asks how it looks to AI, how to rank in ChatGPT shopping or AI search, or how to improve the listing.' It does not state when NOT to use it or name the sibling to use instead for adjacent needs (e.g. check_ai_bot_access or get_product_check for an existing result).

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