grounded-aeo

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

With no annotations, the description fully carries the burden. It discloses that it checks a DNS record and verifies the Ed25519 signature against live catalog content, implying a read-only network operation. It does not explicitly state there are no side effects or mention permissions, but the 'check' and 'verifies' wording provides strong behavioral context.

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?

Two sentences, front-loaded with the main action, and no filler. Every phrase adds useful detail: the DNS record type, the standard, the purpose, and the signature verification.

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 tool has a single parameter and no output schema. The description explains what it checks and what the result indicates (existence, trust tier, signature verification), which is sufficient for an AI to understand the tool's purpose. However, it does not specify the exact return format or error conditions, so it is not fully complete.

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?

The schema only defines 'domain' as a string with no description. The description adds meaning by showing how the domain is used ('at _aeo.<domain>') and what it is the target of the lookup. It does not specify format (e.g., no protocol, trailing dot), but the meaning is clear enough for typical usage.

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 ('Check') and a precise resource ('v=AEO1 DNS record at _aeo.<domain>'), clarifying it verifies existence and trust tier. This clearly distinguishes it from siblings like get_fact or check_serp.

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 explicitly notes 'any domain (cataloged or not)', giving clear usage context. However, it does not mention alternatives or when not to use this tool, so it lacks explicit exclusion guidance.

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?

No annotations exist, so the description carries the full burden. It goes beyond a simple action by disclosing the return payload structure (organic results with rank, domain, title; PAA; related searches; non-organic blocks) and explicitly handling the edge case where empty arrays are a valid finding, not an error. It also states 'Public data' which implies no auth requirements.

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?

Two sentences deliver a wealth of information without fluff. The first sentence front-loads the action and enumerates outputs; the second covers access and edge-case behavior. Every clause earns its place.

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 one required parameter and no output schema, the description fully compensates by detailing what the tool returns, including specific components (organic, PAA, related, blocks) and the empty-array behavior. It's sufficient for an agent to set expectations and interpret results correctly.

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?

The schema already provides 100% coverage for the single keyword parameter, including an example. The description doesn't add extra syntax or semantics for the parameter itself, but given the high schema coverage, the baseline of 3 is appropriate. No further detail is necessary.

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 opens with a specific verb and resource: 'Check the live Google search results for any keyword'. It then enumerates the exact outputs (top 10 organic results, People Also Ask, related searches, non-organic blocks) and the purpose (detecting AI Overview or local pack slots). This clearly distinguishes it from siblings like check_aeo_record, which suggests a different record-based operation.

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 provides implied usage context: 'any keyword' indicates broad applicability, and 'Public data, no catalog entry required' signals that this tool is a lightweight, on-demand check without prerequisites. It doesn't explicitly name alternative tools or exclusion criteria, but the context is clear enough for an agent to know when this tool fits.

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?

With no annotations, the description fully discloses behavior: it uses only the site's own text, owner's published facts, or measurements, with 'no language model wrote any of it'. It also states that unbuildable patches are 'skipped and counted rather than guessed', and that it is 'deterministic and read-only' on the provider's side—valuable beyond the schema.

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 dense but organized: it starts with the purpose, then details patch types, then gives action steps and constraints. Every sentence adds information—no wasted words. It's longer than the typical tool description but earns its length, though it could benefit from slight formatting for readability.

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?

Given the absence of an output schema and annotations, the description adequately explains the return value (patches) and usage (apply and re-run audit). It covers constraints and provenance but doesn't detail the exact patch format or error handling. Still, it's sufficiently complete for an agent to invoke and act on the 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?

The schema already documents 'domain' at 100% coverage. The description adds the constraint 'Claimed domains only' and clarifies that the tool works on 'a cataloged domain', providing context beyond the schema definition. This enriches the single parameter's meaning without overcomplicating it.

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 clearly states the tool returns 'paste-ready patches' generated from 'Grounded AEO' measurements, listing specific patch types (title/meta blocks, robots.txt Allow lines, JSON-LD, /llms.txt). This distinguishes it from sibling tools like check_aeo_record or generate_free_record, which focus on checking or free records, not applying fixes.

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 explicitly says 'USE THIS TO ACT: if you have write access to the site's codebase, apply each patch... then re-run run_audit to confirm.' This gives a clear 'when to use' context. It doesn't name alternative tools for when not to use, but the action-oriented guidance implies this is the post-audit tool.

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?

Description discloses key behaviors: WRITE action, rate-limited to 10/hour, returns exact TXT record and JSON with publishing instructions, no crawl/verification/account. However, it doesn't mention idempotency or side effects beyond generation.

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?

Description is a single concise paragraph with no wasted words. It front-loads the purpose and efficiently covers key info.

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?

Description covers return values and rate-limiting, which is helpful given no output schema. However, parameter explanations are missing, and sibling tools are not referenced.

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?

Only one parameter (name) has a description in the schema; the other five (hours, domain, address, category, services) have no descriptions. The tool description does not explain these parameters, leaving significant ambiguity.

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?

Description clearly states the tool's purpose: final step to make a site AI-citable by generating DNS record and JSON. It specifies the action (generate and return exact records with instructions) and distinguishes from siblings (no crawl, verification, account).

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?

Description indicates this is the 'FINAL STEP' and mentions rate-limiting and that it's a WRITE action with no crawl/verification/account. While it doesn't explicitly mention when to use alternatives, the context implies it's for self-declaration after other steps.

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?

With no annotations, the description fully discloses crucial behaviors: read-only nature, idempotency (re-running cannot inflate), that engine answers are stored but not served here, and the meaning of an empty list as 'no check run yet' rather than 'never cited'. This goes beyond a basic description and provides valuable operational context.

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 concise yet information-dense, with every sentence contributing value: it lists output fields, states scope and idempotency, clarifies content exclusions, and explains list interpretation. There is no redundancy or filler, making it efficient for an agent to parse.

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 simple one-parameter tool with no output schema, the description thoroughly covers what is returned, what is not returned, and how to interpret results, including edge cases. It is complete enough for an agent to understand the tool's behavior and expected output without additional context.

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?

The schema already fully describes the single parameter 'domain' with example (acme.com) and the description confirms it should be a cataloged domain. Since schema coverage is 100%, the description adds no additional parameter meaning beyond restating the context. 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 clearly states the tool retrieves the latest citation check per (question, engine) for a cataloged domain, listing the specific fields returned (question, engine, citation status, URL, day). It distinguishes from sibling tools by focusing on granular per-question/per-engine citation data rather than aggregate domain lists.

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 gives clear context: it is for claimed domains only, is read-only, and returns one row per cell. It also explains how to interpret an empty list. However, it does not explicitly name alternative tools or state when not to use this tool, though the context strongly implies its narrow scope.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It thoroughly explains what an appearance means (and what it does not mean), counts one appearance per answer regardless of pages cited, uses the latest check per cell, and notes that answers with no captured evidence contribute nothing. This goes far beyond a simple tool description and gives the agent a clear mental model.

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 a single dense paragraph, but every sentence contributes meaningful constraints and disambiguation. The main purpose is front-loaded, and the subsequent clarifications are necessary to prevent misinterpretation. While it could be broken into bullet points for easier scanning, the length is justified by the complexity of the counting and semantics.

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 tool with one parameter and no output schema, the description provides complete contextual information: what is returned (domains, rank, engines), what is excluded ('claimed domains only'), and how counting works including edge cases (answers with no evidence). It adequately prepares the agent to interpret results and use the tool correctly.

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?

The input schema already covers the single parameter 'domain' with a description and example, giving 100% schema description coverage. The tool description does not add additional semantic detail about the parameter itself; it focuses on output semantics. Thus, the baseline of 3 is appropriate since the schema does the heavy lifting.

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 clearly states the tool's purpose: to get the domains cited in stored answers for a cataloged domain's tracked questions, ranked by citation count and with the engines that cited them. It uses a specific verb ('Get'), identifies the resource ('cited domains'), and distinguishes itself from siblings like get_citations by focusing on domains rather than individual citations.

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 provides clear context for when to use the tool: it is for seeing which domains were cited, not for endorsements or quality rankings. It implies an alternative use case ('instead') but does not explicitly name sibling tools or state when not to use it. The counting rules and 'claimed domains only' constraint add practical guidance, but explicit exclusions are missing.

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?

With no annotations provided, the description carries the transparency burden. It discloses that only published (approved) facts are returned and includes verification state and confidence, which is useful behavioral context. However, it does not mention potential errors, permissions, or rate limits, though the operation is a simple read.

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 two sentences, front-loaded with the core operation, and every sentence adds value. It avoids fluff and clearly communicates both the action and the returned data without unnecessary detail.

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 single-parameter read tool with no output schema, the description adequately explains the returned content (published facts, verification state, confidence) and the intended grounding use case. It does not cover error handling or pagination, but these are likely low-risk for this simple operation.

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?

The schema already covers the sole parameter 'domain' with a clear description and example, achieving 100% schema coverage. The description adds only that lookup is by domain, which is redundant with the schema, so no additional semantic value is provided.

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 uses a specific verb ('Get') and resource ('verified fact record for a company by domain') with a clear source ('Grounded AEO catalog'). It distinguishes the tool from siblings like get_fact by emphasizing the company-level fact record scope and verified/approved nature.

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 provides clear context for when to use the tool: when an AI agent needs grounded, verified facts about a business. It does not explicitly name alternatives or exclusion criteria, but the stated use case implicitly differentiates it from search or citation tools.

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?

With no annotations provided, the description carries the full burden. It explicitly discloses read-only behavior, the found:false edge case for unclaimed domains, that counts are ranking footprint (not traffic), that volumes are modelled estimates, and that null means no estimate (not zero). This is exemplary behavioral disclosure.

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?

Each sentence earns its place: the first defines the main purpose, and the rest add distinct clarifying details (read-only, eligibility, data semantics, null meaning). It is well-structured and front-loaded, with no redundant content.

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?

Despite having only one parameter, no output schema, and no annotations, the description fully covers what the tool returns, under what conditions it returns found:false, and how to interpret the data. For this complexity level, it is complete and self-sufficient.

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?

The schema describes 'domain' simply as a company domain with an example. The description adds the essential semantics that the domain must be cataloged and claimed, which is critical for interpreting returned data. This goes beyond the schema's basic definition.

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 opens with 'Get the latest competitive intelligence for a cataloged domain' and then enumerates the exact components returned: the owner's ranking-footprint snapshot, the AI-prompt vs Google demand table, and tracked competitors' snapshots. This is a specific verb+resource that clearly distinguishes it from sibling tools like get_company_facts or get_engine_visibility.

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 provides clear eligibility conditions ('Only domains whose owner has claimed them are exposed; anything else returns found:false') and notes the read-only nature, which helps an agent decide when to call it. However, it does not explicitly mention alternatives or compare to sibling tools, so it stops short of full guidance.

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?

With no annotations provided, the description carries the full transparency burden. It discloses important null-handling semantics (null means 'not measured'/'untested', never assumed allow or zero) and the constraint that only claimed domains are supported. It could add error cases or permissions, but it provides substantial behavioral detail beyond a generic API description.

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 relatively long but every sentence adds useful information: purpose, domain requirement, null semantics, and scope limitation. It is well-structured and front-loads the core purpose before explaining edge cases. Slightly more verbose than necessary but not wasteful.

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 compensates by explaining key return semantics (can_read, cited/tracked null behavior) and explicitly stating what the tool does not measure (traffic). For a single-parameter tool, this provides sufficient context for an agent to invoke it correctly and interpret results, though a formal response structure would improve completeness.

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?

The input schema already describes 'domain' with 100% coverage. The description adds meaningful context by introducing 'cataloged domain' and 'Claimed domains only', clarifying that the domain parameter must be an already-claimed/cataloged domain, not just any company domain. This goes beyond the schema's basic example.

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 clearly states the tool retrieves per-engine access and citation data for a cataloged domain. It uses a specific verb ('get') with a precise resource ('per-engine picture') and differentiates from siblings by emphasizing it covers both robots.txt access and citation counts for each engine, not just citations or domains.

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 communicates when to use the tool ('Claimed domains only') and clarifies what it does and does not cover ('Access and citations only; nothing about traffic'). However, it does not explicitly name alternative tools for citation-only or traffic-related queries, though the context implicitly separates it from siblings like get_citations.

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?

No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'verified fact' but does not explain verification, data freshness, authentication, or any side effects. The description is truthful but lacks depth.

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 a single, focused sentence with no redundant words. It efficiently conveys the tool's purpose and key parameters.

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?

Given no output schema, the description does not explain return values or error conditions. Sibling tools exist but are not compared. For a simple tool with two parameters, basic purpose is clear, but users lack complete operational context.

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 50% (key has description, domain does not). The description adds value by providing an example for key and implying domain is required. However, it does not elaborate on domain format or validation, so it only partially compensates.

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 clearly states the verb 'Get' and resource 'single verified fact', along with parameters 'domain' and 'fact key' with examples. It distinctively separates this from the sibling tool 'get_company_facts' which returns multiple facts.

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 implies usage for retrieving a specific fact, but does not provide explicit guidance on when to use this tool versus siblings like 'get_company_facts' or 'check_aeo_record'. No when-not-to-use or alternative suggestions are given.

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?

With no annotations provided, the description carries the full burden and excels. It discloses that 'Nothing is fetched and nothing is spent,' that stored lists are a 'SAMPLE' with implications for absence interpretation, and that positions reflect 'ranking footprint, never traffic.' It also mandates repeating a disclaimer sentence wherever results are shown—an important behavioral requirement.

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 fairly long but each sentence contributes critical caveats or definitions. The structure front-loads the core definition, then layers constraints and disclaimers. It could be slightly tightened (e.g., 'nothing fetched/spent' could be one clause), but overall it is dense and purposeful.

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?

Given the tool's simplicity (one parameter, no output schema), the description is exceptionally complete. It explains the computation logic, data source, limitations, and required response handling, covering all areas an agent needs to use the tool correctly and interpret its results.

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?

The sole parameter 'domain' is fully described in the schema with an example. The description adds context that the domain must be 'cataloged' and 'claimed,' but does not elaborate on format or validation beyond that. Since schema coverage is 100%, the description's addition is marginal but non-zero, meriting the baseline 3.

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 opens with a specific verb and resource ('Get the keyword gap for a cataloged domain') and defines the gap precisely with two concrete cases ('absent' and 'behind' by 20 places). This distinguishes it clearly from sibling tools like get_competitive_snapshot or get_engine_visibility, which address different analytical angles.

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 gives explicit applicability conditions: 'Claimed domains only' and 'computed from captures already on disk.' It also clarifies that no fetching or spending occurs, which signals a low-cost read operation. However, it does not explicitly mention alternatives or contrast against sibling tools, so it stops short of full guidance.

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?

The description discloses that the llms.txt is 'auto-generated' and 'curated, AI-readable', which gives some behavioral context. However, it doesn't explicitly state side effects (though 'get' implies read-only), access requirements, or error behavior. No annotations exist, so the description carries the full burden and only partially fulfills it.

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 a single, front-loaded sentence with no fluff. It efficiently conveys the tool's core function and the nature of the output.

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?

Given the tool's simplicity (one parameter, no output schema), the description covers the core purpose but lacks usage guidelines and explicit parameter format. It also doesn't mention potential errors or prerequisites like catalog membership. It is adequate but has clear gaps in guidance.

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?

With 0% schema description coverage, the description must explain the domain parameter. It only says 'for a cataloged company', which hints at domain's role but doesn't specify format (e.g., 'example.com'), validation rules, or what happens if the domain isn't cataloged. The agent gets insufficient parameter semantics.

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 uses the specific verb 'Get' with the resource 'llms.txt' and adds context 'for a cataloged company', clearly distinguishing this from sibling tools that retrieve other data types. It is specific and unambiguous, naming a unique deliverable.

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?

No guidance is provided about when to use this tool instead of siblings like get_company_facts or get_citations. There are no use-case examples or alternative tool mentions, leaving the agent without decision support.

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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It transparently states that the tool is deterministic, read-only, fetches no new data, generates nothing, and never returns a brief without supporting evidence. It also restricts claims to verified facts verbatim, giving strong insight into side effects and constraints.

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 dense but every sentence serves a purpose: purpose, data source, output contents, constraints, and behavioral guarantees. It is front-loaded with the main verb and resource, and the structured elaboration flows logically. No filler or repetition.

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?

Given the tool's complexity (multiple data sources, formats, claim restrictions, limits), the description covers all key aspects: what it produces, what evidence is used, what claims are allowed, the maximum number of briefs, and the meaning of an empty result. Even though there is no output schema, the description sufficiently explains return behavior.

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?

The schema already provides a clear description for 'domain' (Company domain, e.g. acme.com). The tool description adds critical constraints that 'domain' must be cataloged and claimed, which enriches parameter semantics beyond the schema baseline. This additional context is valuable and not redundant.

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 uses a specific verb ('Propose') and resource ('content briefs for a cataloged domain'), clearly distinguishing it from sibling tools like 'get_keyword_gap' or 'run_audit' by emphasizing it generates briefs from already-collected data rather than performing new analysis. The scope and output are precisely defined.

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 clearly states when to use the tool: for a cataloged domain with collected data, and for claimed domains only. It also provides guidance on interpreting results (empty list = insufficient data). It does not explicitly name alternative tools for other scenarios, but the context is strong enough.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it delivers exceptionally well. It clearly states the WRITE action, that facts are queued and unverified until human approval, that it is rate-limited to 5/hour, and that it is free and requires no account. It also describes the crawler behavior and the iterative verification nature. This goes well beyond basic expectations and gives the agent critical safety and side-effect information.

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?

Although the description is dense, every sentence adds unique value. It opens with the core purpose, then explains the process, outputs, usage loop, and important caveats (write action, rate limit, free). The use of backticks for field names and clear sections (what, how, constraints) makes it well-structured and skimmable. No fluff or redundancy.

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 takes on the responsibility of explaining return values. It explicitly names `seoReport.headSnippet`, `setup_prompt`, and the ranked list of gaps, as well as the 0-10 score. It also covers behavioral constraints (rate limit, approval requirement). For a single-parameter tool, this is a complete and actionable description that leaves little ambiguity for an agent.

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?

The tool has a single parameter (domain) with schema description coverage of 100%: 'Domain to audit, e.g. acme.com'. The tool description does not add any additional parameter syntax, constraints, or formatting details beyond what the schema already provides. Per the rubric, a 3 is appropriate because the schema does the heavy lifting and the description adds no extra parameter semantics.

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 opens with a clear, specific verb+resource combination: 'Audit AND FIX a site for AI citation + SEO.' It enumerates the exact steps (crawls the domain, scores AI-readability 0-10, checks for v=AEO1 record) and outputs (headSnippet, setup_prompt, ranked list of gaps). This distinguishes it from sibling read-only tools like check_aeo_record or check_serp by emphasizing the fix-oriented, comprehensive audit workflow.

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 provides explicit usage context: 'Use it to build the fixes, apply them to the site, then CALL THIS AGAIN to verify the score improved.' This tells the agent when to invoke the tool in an iterative audit/fix loop. It also mentions rate limiting and the write action, which helps the agent decide if this is the right tool given constraints. It does not explicitly call out alternatives or when NOT to use it, so it falls short of a perfect 5.

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?

No annotations provided, but the description discloses the return limit (10 matches) and fields (tier, verification state). Lacks details on authorization 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?

Single efficient sentence front-loads purpose and result, with no wasted words.

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?

Complete for a simple search tool with one param: covers purpose, method, and return value details (limit, fields) despite no output schema.

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 already describes the query parameter ('Name or domain fragment'). Description reinforces this but adds minimal new meaning.

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 clearly states the tool searches the Grounded AEO catalog by company name or domain, and distinguishes from siblings like check_aeo_record which likely checks a specific record.

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 specifies when to use (to search by name/domain) and implies context via siblings, but does not explicitly state when not to use or provide alternatives.

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