SEO Records

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld). The description goes further by disclosing the confidence semantics of its own results — robots.txt findings are 'certain' while home-page fetch results are only 'probable' because real crawlers come from other IPs — which tells the agent how much to trust each output. It also adds privacy behavior ('nothing is stored') not present in annotations, though it says nothing about rate limits or latency.

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-loads the core purpose and packs the detail into one dense but well-ordered sentence, followed by two short clauses and a docs URL. No filler, though the parenthetical about IPs makes the single sentence longer than ideal for quick scanning.

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 does the job of explaining what the caller learns: per-crawler robots.txt rules, crawler-vs-browser fetches, and page-level blockers like noindex/nosnippet/JS-only. For a single-param read-only tool this is nearly complete; it stops short of describing result structure or how ambiguous cases are reported.

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% and the single url parameter is already documented with an example format, so the description needs to add nothing further. Baseline 3 applies; the example in the description body ('example.com', maxLength 500) only restates the schema.

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 (checks) and resource (whether ChatGPT, Claude, Perplexity, Copilot, Gemini and Le Chat can read a website), then enumerates the three concrete signals it inspects. An agent can distinguish this from check_website_seo and get_full_audit_checkout without opening any schema.

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?

The description makes the scope clear (AI-crawler readability, robots.txt, page-level blockers) which implies when it applies, and adds 'Free, nothing is stored' plus a docs link. However, it never explicitly says when to choose this over the sibling check_website_seo, which is a plausible point of confusion. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety and determinism are covered. The description adds valuable behavioral context beyond annotations: it is free, takes about 10–20 seconds, stores nothing, and explains what is actually fetched. It doesn't describe rate limits or auth needs, but for a read-only check this is solidly above baseline.

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 description is packed but front-loaded: it begins with what is read and what is returned. It is one long sentence with a close-packed parenthetical, which is dense but not wasted; a small split into two sentences could improve scanability.

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?

There is no output schema, so the description must explain returns, and it does list the kind of results (SEO problems, Google snippet, fixes). It could more explicitly mention output format or response structure, but it covers the essentials for a read-only diagnostic 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 the url parameter already has a description with an example. The tool description adds little parameter-specific information beyond implying a single URL target, so this is the expected baseline.

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 precisely states the verb+resource: it reads a home page plus sitemap pages and returns SEO problems with specific examples. An agent immediately understands what check_website_seo does, and the distinction from check_ai_crawler_access and get_full_audit_checkout is clear from the wording.

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 says it is free, fast (~10–20 seconds), and for a single website, but offers no explicit when-to-use or when-not-to-use guidance versus the sibling tools. The implied context is that it's a lightweight SEO check, but it doesn't say when to prefer check_ai_crawler_access or when a full audit/checkout is needed.

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

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

Annotations already mark this as non-read-only, non-idempotent, open-world. The description adds valuable context beyond them: nothing is charged until the user pays on the Stripe page, and it is a one-time payment with defined tiers. It does not address whether repeated calls create duplicate sessions, which the idempotentHint=false annotation implies.

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 core action, then supporting detail. The price-tier list is dense but each entry carries decision-relevant information (cost vs. audit size). Slightly heavy but no wasted sentences.

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?

For a 3-parameter tool with no output schema, the description covers the action, the deliverable being purchased, pricing, and the charging model. The one remaining gap is not explicitly stating that the return value is the payment link/URL the user should be directed to.

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%, so the baseline is 3. The description adds genuine meaning by mapping the `pages` values to prices (€9.90/1,000 → €49.90/10,000), information the schema does not carry. It says less about `language` or the `url` parameter beyond the schema.

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 specific verb and resource: 'Creates a secure Stripe payment page for the full Audit SEO Records of a website', and enumerates exactly what the purchase includes. It clearly differentiates from its siblings (check_ai_crawler_access, check_website_seo), which are read-only diagnostics rather than a payment flow.

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?

'Intended for users who ask to buy the full audit' gives a clear trigger condition for invoking the tool. It doesn't explicitly name sibling alternatives or state when not to use it, but the purchase context is unambiguous.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context that the payment links are hosted on Stripe and that the user pays there (external checkout), but says nothing about return shape or pagination beyond that.

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 lead sentence is front-loaded with what the tool returns, followed by a dense product list. It is long but every clause carries information (product identity, platform, price), and there is no filler.

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 correctly carries the burden of describing what is returned (product function, platforms, prices, payment links). It also supplies a docs URL. Adequate for a two-parameter read-only catalog lookup, though it doesn't describe the response structure in detail.

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%, so the baseline is 3, but the description goes beyond the bare enum by explaining what each product id actually is and its price point (e.g. seo-records-corrector 'fixes SEO at serve time... from €199/year'), which meaningfully disambiguates the enum values. It also clarifies that 'all' returns every product.

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 specific verb and resource: it returns what a product does, its platforms, prices and Stripe payment links. This is clearly distinct from the diagnostic siblings (check_website_seo, check_ai_crawler_access) and the checkout sibling. It doesn't explicitly name or contrast those siblings, so it stops short of a 5.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no sibling is named. Usage is only implied by the scope of the returned content (offer/pricing info), which an agent can infer but must not be told directly.

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

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

Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description goes further by disclosing the lifecycle (returns status and progress during the crawl, full signal payload once finished), the shape of that payload (family, severity, page count, example URLs), the previous-audit diff, and the Effect-only yearly curve. It does not mention link expiry, invalid-link behavior, or rate limits.

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 purpose is front-loaded in the first clause, followed by progressively finer detail about running state and finished payload. It is a dense, semicolon-chained sentence rather than a padded one, though the trailing Corrector-connector note is the one clause that is more promotional than operational.

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 and only one parameter, the description carries the burden of explaining what comes back, and it does so well: status/progress, all signals with family and severity, page counts, example URLs, previous-audit delta, and the yearly curve. It is nearly complete for the happy path; edge cases such as an expired or unauthorized link, or very large signal sets, are not covered.

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% for the single 'report' parameter, so the schema already documents the accepted link/identifier and its length bounds. The description restates the link format and adds the 'buyer's private link' framing, but adds no syntactic or semantic detail beyond the schema. Baseline 3 is appropriate.

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 gives a specific verb (Reads) and a precisely scoped resource: an Audit SEO Records report or Effect monthly crawl, retrieved from the private link the buyer received. The link format example (https://seorecords.com/audit?id=…) and the mention of the yearly curve cleanly separate it from the free-checker sibling check_website_seo and from get_full_audit_checkout.

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 establishes clear context for use: the caller must hold the private link the buyer received, and the tool covers both the in-progress state and the finished state. It even points to the natural follow-up action (fixing cited pages via the SEO Records Corrector connector). It stops short of naming when NOT to use it or contrasting explicitly with check_website_seo.

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