SEO Records

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

Annotations already declare read-only, idempotent and open-world behavior, yet the description adds real value: 'Nothing is stored', the paid access pass requirement with pricing, and an honest confidence split between 'certain' robots.txt results and 'probable' user-agent fetch results because real crawlers come from other IPs. It does not describe response shape or any rate limits, which keeps it from a 5.

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 core capability is front-loaded in the first clause, and each following clause (certain vs probable, page-level blockers, no storage, cost, docs link) adds distinct decision-relevant information. No filler 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?

With no output schema, the description does a good job explaining what is examined (robots.txt rules, per-crawler fetches, noindex/nosnippet/JS-only blockers) and the caveat on result reliability. The main remaining gap is that it does not hint at the structure of the returned findings, though the concept-level coverage is strong.

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 both url and access_key are already documented, including where the key comes from. The description restates the access-pass requirement but adds no syntax, format, or edge-case detail beyond the schema, so baseline 3 applies.

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 a precisely scoped resource (whether named AI crawlers can read a website), then enumerates the concrete checks it performs. This is clearly a distinct domain from the sibling check_website_seo, so an agent can discriminate without opening either 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 use case is implied clearly by the purpose statement, and the paid access prerequisite is disclosed up front. However, it never states when to choose this over check_website_seo or the other siblings, and gives no exclusions or conditions for use.

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 openWorld, so the safety profile is covered. The description adds valuable context beyond that: ~10–20 second runtime, nothing is stored, and a paid access-key requirement. It does not mention error or rate-limit behavior, keeping it short of a 5.

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 what it reads and what it returns, then runtime/privacy and the access requirement. The parenthetical list of SEO problems is long but each item is informative; no sentence is pure 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 carries the burden of describing returns and does so — problem list, today's Google snippet plus truncation point, and the fixes the corrector would apply. Only the response shape/structure (counts, fields) remains unspecified.

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 both parameters (url, access_key) are documented in the schema with examples and the 'pass_…' key format. The description adds no format or constraint detail beyond what the schema already supplies, so baseline 3 applies.

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 and resource — reads the public home page and a few sitemap pages the way a search engine does — and enumerates the returned findings (duplicate titles, missing h1, robots.txt, mixed content, etc.). That crawl scope cleanly separates it from the sibling check_ai_crawler_access, which only inspects crawler access.

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 (audit a site's SEO health) and a prerequisite is given (connector access pass, €9.90/24h or €29/month). However, there is no explicit when-to-use vs. when-not, and the adjacent tools read_audit_report and get_full_audit_checkout are never contrasted.

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.