SearcherLite

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

With annotations already indicating readOnly and non-destructive, the description adds substantial value: billing details (per-platform credits, no charge on platform failure, charge even on empty AI answer), slow execution, and truncated output. No contradiction with annotations.

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?

Information is front-loaded with the core action, then cost, then return values. Slightly dense with three topics in one block, but each sentence carries distinct, useful information and nothing is redundant.

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?

Covers the essential operational context: platforms, slowness, credit behavior, truncation, and return payload. No output schema exists, so the description adequately fills that gap. Minor omission: the confirm_quote_id two-step flow is left entirely to the schema, and platform-specific availability isn't mentioned.

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 covers all 5 parameters with descriptions (100% coverage), so the baseline applies. The tool description adds general context (cost per platform) but no parameter-specific elaboration beyond what the schema already states.

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 uses a specific verb ('Runs a prompt live') and explicitly names the platforms (Google AI Overview, Google AI Mode, ChatGPT, Gemini) plus the key return value (whether the domain is cited). This makes the tool's purpose unambiguous and distinguishes it from generic search tools.

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?

Provides clear operational context: cost per platform, slow runtime (up to 90 seconds), and truncation behavior. Does not explicitly state when to choose this over sibling tools like ai_overview or ai_compare, but the cost and latency warnings give a strong practical usage signal.

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 and destructiveHint=false, so the description need not repeat safety traits. It adds valuable behavioral context: the credit cost, the free condition for known-empty lookups, the 'one row per domain' return structure, and the country-specific data availability (ChatGPT vs Google AI Overviews). This goes beyond structured fields and helps the agent set expectations.

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 three concise sentences, front-loading the purpose and then providing cost and return information. Every sentence earns its place: purpose, cost, return. No fluff or repetition of schema details.

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 4-parameter tool with no output schema, the description covers the essential aspects: what it does, what it returns, and cost. It does not explain the confirm_quote_id flow (though schema does) or detail the output row structure beyond listing metrics. Given the absence of an output schema, the description is reasonably complete but could specify the row fields more explicitly.

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 has 100% parameter description coverage, so the baseline is 3. The description does not add additional parameter-specific meaning beyond summarizing them ('your domain against up to 4 competitors'). It mentions the output but not parameter nuances, so it does not elevate beyond the already-rich 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+resource: 'AI mentions of your domain against up to 4 competitors'. It enumerates the exact metrics returned (mentions, share, AI search volume, per-platform split), clearly distinguishing it from siblings like ai_check (single-domain) or ai_trend (trends). An agent can infer this is a comparative analysis tool without opening schemas.

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 implies usage for comparing a domain against competitors in one country, and adds cost information (4 credits, free when no domains are cited). However, it does not explicitly contrast with sibling tools or state when not to use it. The comparative framing is clear enough to guide selection, but lacks explicit exclusions or alternative references.

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 tool has annotations readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat the obvious read-only/no-destruction behavior. It does add meaningful behavior beyond annotations: 'Cost: 4 credits. Free when the domain has no AI mentions in that country (repeats of a known-empty lookup are free)', and the geographic scope (plus ChatGPT for the US). This is valuable operational context the annotations cannot provide.

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 few tightly-written sentences with no filler: it starts with the key purpose, adds cost and the free-condition nuance, then says what is returned, and finishes with a helpful sibling pointer. The only slightly redundant part is 'Returns: the summary' after the opening sentence already lists the metrics; still, it's almost entirely useful and front-loaded.

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 reasonably transmits the key return value: it lists total mentions, search volume, split per platform, co-cited domains, and brand entities. It also explains the cost and free condition, and accepts the ai_trend alternative. The main missing piece is the confirm_quote_id qualifying flow, but it is fully explained in the schema; the agent can still invoke the tool correctly with what is provided.

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 each parameter (domain, country, confirm_quote_id) is already well-described in JSON schema with its own nuances. The description does not substantially add parameter-level information, such as clarifying the credit/quote logic beyond what the schema already says, so the 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 tool description is very specific: it describes the action ('How often a domain is cited as a source in AI answers') and the resource ('AI Overviews, plus ChatGPT'). It enumerates exactly what will be returned — total mentions, AI search volume, platform split, co-cited domains, and brand entities — and differentiates itself from ai_trend by pointing to ai_trend for monthly history. An agent can immediately distinguish this from the many sibling AI tools.

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 explicitly names an alternative by giving a clear 'Use ai_trend for the month-by-month history' guidance, which tells an agent when not to use this tool. It also gives pricing context and when it is free. However, it does not address other siblings like ai_check, ai_compare, or ai_sources, so a fully-exhaustive when-to-use guide is 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?

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds valuable details about cost tiers, the quote confirmation process for larger sizes, and the fact that repeated known-empty lookups are free, which are not covered by annotations. It also notes country-specific data limitations (ChatGPT vs Google AI Overviews), enhancing transparency.

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 but packed with essential information: purpose, cost, confirmation steps, and return details. The key purpose is stated first, followed by cost and confirmation logic, making it easy to scan. No redundant 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?

The description covers all necessary operational aspects: cost, confirmation, free repeats, return structure, and country-specific data behavior. With no output schema, it explains what the tool returns (top limit pages and total_count), which is sufficient for an agent to call it 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?

Schema coverage is 100%, with each parameter well-described. The description adds context on how size affects cost and confirmation, and clarifies limit vs size semantics. It also explains the confirm_quote_id lifecycle, which is critical for correct invocation and not evident from the schema alone.

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 what the tool does: it identifies which of a domain's pages are cited by AI answers, along with mentions, AI search volume, and co-cited domains. It uses specific terms that distinguish it from siblings like ai_sources or ai_overview, and the title reinforces the purpose.

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 on when to use this tool (to see AI citations for a domain) and includes cost and confirmation requirements for larger sizes. It doesn't explicitly mention alternatives or when not to use it, but the clarity of purpose and cost details give solid 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 annotations already establish read-only and non-destructive behavior, and the description adds meaningful behavioral context: credit costs per platform, quote-first handling for expensive calls, free repeats for known-empty lookups, default platform fetching in the US, and the fact that answers are truncated and structured-content-only. This goes well beyond the annotation surface.

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 carries information: core output, cost model, quote requirement, and return behavior. It is front-loaded with the primary purpose and uses no filler or repetition beyond what is operationally necessary.

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 no output schema, the description tells the agent what is returned (top limit prompts by AI search volume, structured-only and truncated) and covers the non-obvious workflow (quote confirmation). Together with 100% parameter schema coverage, this is sufficient for correct invocation.

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 100% schema description coverage, the baseline is 3, but the description materially adds meaning: it explains per-platform credit costs, US default fetching of both Google and ChatGPT, ChatGPT availability limited to 'us', and the quote/confirm workflow for confirm_quote_id. This helps the agent choose size, country, and platforms correctly.

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 defines what the tool returns: AI prompts whose answers cite a domain, along with platform, search volume, cited URL, and source rank. It also specifies 'one list per platform,' which distinguishes it from sibling tools like ai_sources or ai_overview without requiring the agent to open schemas.

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 operational guidance (costs, quote flow, defaults) but never states when to use this tool versus alternatives such as ai_sources, ai_overview, or ai_check. There are no explicit exclusions or sibling comparisons, so an agent must infer the right context from the tool name and title.

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, destructiveHint=false and openWorldHint=true, covering the safety profile. The description adds genuinely non-obvious behavior beyond annotations: the tiered credit cost (6/12/22), the free-on-known-empty-repeat caching, and the two-phase quote-then-confirm flow for sizes 200/500 (confirm_quote_id). This aligns with idempotentHint=false and adds real 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?

Roughly five purposeful sentences with the core purpose front-loaded before cost and return details. Every sentence earns its place, though the credit/quote information is dense and slightly packed together. Still, there is no filler 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?

For a 5-parameter tool with an enum, a cost model, a two-phase quote confirmation flow, and no output schema, the description covers the essentials: purpose, credit costs, the mention-data country limitation, the confirm flow, and the return shape (top limit domains, total_count, total answers). The trickiest operational aspect, the quote-first call for 200/500, is explicitly explained, so an agent can invoke it 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?

Schema coverage is 100%, so the baseline is 3. The description adds cross-parameter value beyond the schema: it maps size to cost and clarifies that sizes 200/500 require the confirm_quote_id round-trip, and it surfaces the country nuance (ChatGPT mention data exists for 'us' only; other countries are Google AI Overviews only) — a detail the schema's country description omits.

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-resource-scope statement: 'Which domains AI answers cite most for prompts containing a topic, with mentions, share and AI search volume.' This clearly differentiates ai_sources from its AI-family siblings (ai_check, ai_overview, ai_prompts, ai_trend) by focusing on cited/owned domains. The phrase 'see who "owns" a topic in AI search' adds a sharp, memorable purpose.

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 a clear use context ('Useful to see who owns a topic in AI search') and explains operational behavior (cost, quote flow), but it never names an alternative tool or states when NOT to use it. Unlike a high-scoring definition that explicitly routes to a sibling, this one leaves tool-selection among the six AI siblings to inference.

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?

Beyond the read-only/open-world annotations, the description discloses pricing, billing on empty series, the monthly row shape, and the history_id linkage. These are behavioral facts an agent needs to predict side effects and costs, and nothing contradicts the annotations.

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?

Three short sentences cover function, data availability, cost, return shape, and the integration workflow. There is no filler, and the most important behavior is front-loaded.

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 no-output-schema tool, the description does state the output shape ('one row per month') and the two metrics from the first sentence. A slightly fuller return-field listing would make it fully self-sufficient, but combined with the 100%-coverage schema it is nearly 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?

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds no new parameter-level meaning beyond restating that history_id comes from ai_overview, which is already in the schema, so 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 identifies a specific resource ('AI mentions and AI search volume for a domain') and a clear temporal aggregation ('month-by-month'), so an agent knows what this tool produces. It references ai_overview as the source of history_id, but it never explicitly contrasts itself with sibling tools such as ai_check or ai_overview, so it falls just short of full sibling differentiation.

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 operational context: data begins August 2025, the call costs 4 credits even on an empty result, and the history_id workflow attaches the trend to an ai_overview. It does not explicitly say when to prefer this tool over alternatives, however, so it stops short of a 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?

The description goes well beyond the annotations by adding concrete behavioral facts: cost per size, free repeat calls for known-empty queries, the quote-first workflow for size 100, and the return fields (backlinks, referring domains, pages, first seen). These are exactly the side-effect and workflow details an agent needs and that are not available from annotations or parameter names.

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 succinct sentences cover metrics, cost tiers, empty-query behavior, and the confirmation workflow. No filler or redundancy; the most important operational caveats are front-loaded.

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 read-only look-up tool, the description supplies essential response semantics (top `limit` anchors, aggregate fields), cost behavior, and the non-obvious quote confirmation step. Combined with the rich schema, an agent has enough to call and interpret the result without external docs. No output schema exists, so these textual details are especially valuable.

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 documents all four parameters, so the baseline is 3. The description adds value by explaining cost implications of size, the quote/confirm_quote_id flow for size 1000, and free retries on empty results. This goes beyond the schema without duplicating 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 definition identifies exactly what the tool returns: anchor texts for a target, with per-anchor metrics (backlinks, referring domains, pages). Though phrased as a noun, the intent is unambiguous and matches the name backlinks_anchors, and it differentiates well from sibling tools like backlinks_pages or backlinks_competitors.

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 tells what the tool does but gives no guidance about when to choose it over alternatives such as backlinks_pages or domain compare tools. There is no explicit 'use this when...' or 'instead of...' direction. The cost/quote rules are workflow details, not selection 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?

Beyond the read-only and open-world annotations, the description prominently discloses credit costs by size, free behavior for repeated empty lookups, the quote-before-confirmation flow for size 1000, and the returned total_count. This gives the agent the behavioral details needed to avoid surprise costs.

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 compact and well-structured: it front-loads the core result, then the pricing/quote behavior, then the return shape. Every sentence adds useful information with no redundancy or 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?

Given no output schema, the description provides everything an agent needs to invoke the tool correctly: required domain inputs, cost behavior, confirmation gate, limit default, and returned fields. It is a complete and self-contained definition.

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 schema already documents size cost tiers, limit default, and confirm_quote_id semantics. The description repeats and reinforces these details but does not add meaning 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 is specific and actionable: it defines the tool as a link gap analysis that returns referring domains linking to a competitor but not to the user, ranked strongest first, with rank and link count. This clearly distinguishes it from sibling backlinks tools like backlinks_list or backlinks_referring_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?

The context is implicitly clear: an agent can infer this tool is for competitor gap analysis. However, the description does not explicitly say when not to use it or name any alternative sibling tool, so the agent must infer usage boundaries from the definition alone.

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 and destructiveHint=false, so the safety profile is covered. The description adds meaningful operational behavior: a 2-credit cost, free execution when no results are found, free repeats of known-empty lookups, exclusion of large generic sites, and a ranking/top-100 behavior. This goes beyond the annotations without contradicting them.

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 three focused sentences: what the tool returns, its cost and free conditions, and its return format. It is efficiently structured with no filler, and the most important functional constraints are front-loaded.

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 description covers the core purpose, cost, free-behavior edge cases, exclusion criteria, ranking output, and default/max limits. It lacks only a note on pagination or the semantic meaning of 'rank', but nothing an agent needs to decide to call the tool is missing.

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 all three parameters are already documented with types and descriptions. The description reinforces the default limit and target scope but does not add material semantics beyond the schema. The confirm_quote_id parameter is not mentioned, but it is not relevant to a 2-credit tool, so the schema's explanation suffices.

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 identifies the tool's output: domains sharing the most referring domains with a target, along with rank and shared-domain counts. It also notes the large-generic-site exclusion illustrative of domain-specific behavior. However, it does not explicitly contrast with the sibling `backlinks_compare` tool, so differentiation is implied rather than stated.

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 explains what the tool returns but provides no explicit guidance on when to choose it over alternatives such as backlinks_compare, backlinks_list, or backlinks_referring_domains. There is no 'use this when...' statement or exclusion of alternative scenarios. Usage is only implied by the tool's name and output description.

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 several important behaviors beyond the annotation hints: cost tiers by size, free known-empty lookups, the quote-and-confirm flow for size 1000, and the subtle caching exception for dofollow-only empty results. This is exactly the kind of operational context an agent needs.

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?

Three compact sentences front-load the output fields, then cover cost and confirmation behavior, then state the return shape. Every sentence earns its place and there is no repetition of schema 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?

For a read-only listing tool with no output schema, the description is complete: it explains what results contain, how cost works, when confirmation is required, and what the response returns (`limit` and `total_count`). No critical operational detail is missing.

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 the baseline is 3. The description adds meaningful context beyond the schema by clarifying strongest-first ordering, the default and purpose of `limit`, and the dofollow-only empty-result caching exception. It does not need to repeat schema-parameter details.

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 'Individual backlinks pointing at a target, strongest first' and enumerates the returned fields (source URL/domain, anchor text, dofollow, link type, rank, spam score, seen dates, flags). This makes the tool's precise role clear and differentiates it from sibling backlinks_* tools that focus on anchors, domains, or overview metrics.

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 implies when to use the tool, especially for link-level detail, but it never names an alternative or states when not to use it. Sibling tools like backlinks_anchors and backlinks_referring_domains exist, yet no routing guidance is provided beyond the phrase 'Individual backlinks.'

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 read-only and non-destructive behavior, so the description's additional billing behavior is valuable context. It adds cost details, a free-when-empty condition, and repeat-free behavior, and the return shape, none of which are visible in the annotations.

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 compact and information-dense, with the metric list front-loaded, followed by cost and return details. The long list of metrics is slightly unwieldy, but every sentence earns its place 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 adequately summarizes the return content as the profile summary plus monthly history. It covers the main metrics, pricing, and free-call behavior; the quote-confirmation parameter is already documented in the schema, so nothing needed for invoking the tool is missing.

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 the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides for target and confirm_quote_id.

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 identifies the resource as 'a target's backlink profile' and enumerates the specific aggregate metrics returned (total backlinks, referring domains/pages/IPs, domain rank, spam score, etc.). This distinguishes it from sibling tools like backlinks_list, backlinks_anchors, and backlinks_referring_domains by its aggregate, overview-oriented scope.

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 overview nature of the output implies when to use it, but the description never explicitly states when to prefer this over backlinks_list, backlinks_pages, or backlinks_referring_domains. There is no 'use this for X, use that for Y' guidance; usage is only implied by the metric summary.

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 and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context: credit costs, free repeats of known-empty lookups, the quote-then-confirm flow for size=1000, and the default limit. This goes beyond the annotations without contradicting them.

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 terse sentences: purpose, cost, quote note, and return shape. Everything earns its place, and the most important information is front-loaded. No filler or unnecessary 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?

For a moderate-complexity tool with no output schema, the description covers the returned fields, default limit, total_count, pricing tiers, empty-result behavior, and the confirm_quote_id workflow. An agent has enough information to invoke the tool and interpret its result 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?

Schema coverage is 100%, so the baseline is 3. The description adds value by linking size to credit costs, clarifying the confirm_quote_id handshake for size=1000, and confirming the limit default in the return description. This is useful semantic context 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 opens with 'A target's pages ranked by number of backlinks' and lists the specific fields returned (backlinks, referring domains, broken links, page rank, first seen), making the operation clear. It does not explicitly name sibling tools to differentiate, but the focus on 'pages' is enough to separate it from related backlinks tools.

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 intended use case is implied by 'A target's pages ranked by number of backlinks' but no explicit when-to-use or alternative tools are mentioned. Operational guidance covers pricing and quote confirmation, yet there is no selection guidance among the backlinks_* siblings.

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 establish readOnly and non-destructive behavior, and the description adds substantial behavioral context: pricing per size, free repeated empty lookups, the quote-id confirmation requirement for size 1000, and the return of top `limit` domains plus total_count. This lets the agent predict side effects and cost before calling.

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 compact and front-loaded: the core purpose appears in the first sentence, followed by cost behavior and return summary. Every sentence adds distinct information; there is no filler or redundant restatement of the tool name.

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 no output schema, the description discloses the output fields, the default and maximum return count, the total_count field, pricing, and the confirmation edge case for size 1000. An agent has enough information to invoke the tool correctly and interpret its result.

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 adds meaning beyond the schema: it clarifies that `limit` applies to the strongest-first ordering and explains the quote/confirm workflow around `confirm_quote_id`. The cost-to-size mapping is also reinforced in prose rather than left to the schema alone.

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 identifies the resource: 'Domains linking to a target' and enumerates the returned metrics, so an agent can infer what the tool does. However, it never contrasts itself with sibling tools like backlinks_pages or backlinks_list, so it misses the opportunity to differentiate at a glance.

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 operational guidance for cost tiers, free empty lookups, and the size-1000 quote confirmation flow, which is useful when invoking the tool. It does not explicitly state when to prefer this tool over sibling backlinks_* tools or what conditions would make an alternative more appropriate.

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?

Even with readOnlyHint=true already covering the safety profile, the description adds substantial behavioral details: cost tiers, credit charging even for empty results, the quote-and-confirm flow for expensive calls, and the return format sorted by volume. This goes well beyond the annotations and is consistent with idempotentHint=false.

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?

Three compact sentences cover scope, cost, quote behavior, and return shape with no filler. The most important differentiator ('many keywords in one call') is front-loaded.

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 still explains return behavior ('one row per keyword found, sorted by volume, up to limit rows'). All four params are documented, costs are explicit, and the quote confirmation flow is clarified. An agent has everything needed to call and interpret the result.

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 meaningful semantics by explaining how keyword count maps to cost and that the limit affects returned rows but not cost. It also indirectly explains confirm_quote_id through the quote-confirmation behavior.

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 names the specific resource ('many keywords') and the exact metrics returned ('Volume, CPC, KD, competition and intent'), with an explicit batch size range. It is clearly differentiated from the sibling keyword_overview by the 'many keywords in one call' phrasing.

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 it clear this is the batch variant by saying 'for many keywords in one call (1-700 keywords)', which signals when to reach for it. It does not explicitly name keyword_overview or other alternatives, but the context is clear enough and the cost/quote flow gives additional situational 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 important behavioral traits beyond annotations: the cost structure (2/6/10 credits, free when nothing matches), the confirmation flow for size 1000 with quote-first behavior, and the return format (top `limit` keywords by volume, total_count). It also explains what each mode returns. The annotations are sparse (idempotent false), so the description carries the burden and does so thoroughly.

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 compact and organized: mode definitions upfront, cost/quote note, then return format. It is not overly long and each sentence adds distinct information. Slight room for improvement by separating cost details from core behavior, but overall efficient.

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?

Covers modes, cost/credit details, the quote requirement for size 1000, and return structure (top limit keywords with positions and total_count). With an output schema absent arranged by input schema covering all parameters, this is fairly complete. It does not explicitly state that it compares against another domain (actually it does via them). Minor gap: no mention of authentication or rate limits, but annotations show no safety concerns. Overall 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?

Schema description coverage is 100%, so the baseline is 3. The description adds behavioral context for `limit` and `confirm_quote` by specifying default return size and the quote-flow, but the schema already documents each parameter's meaning. No additional param semantics beyond what the schema provides, except clarifying that size doesn't affect cost? Wait it says size affects cost. Cost is mentioned in description and schema partially. 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 states a clear verb ('comparison') and resource ('keyword comparison of two domains'), and names the three modes (shared, their_gap, your_gap) that define what the tool computes. This distinguishes it from sibling tools like domain_keywords or domain_overview, which perform different analyses.

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 explains what the tool does but doesn't explicitly say when to use it over alternatives like domain_competitors or serp_analysis. It implies its usage through the mode definitions but provides no direct guidance on selecting this tool versus siblings. The credit/cost info is useful operational context but doesn't substitute for explicit selection criteria.

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 present, the description carries the behavioral disclosure burden. It clearly states pricing (2 credits), free repeats of known-empty lookups, output contents, and the default limit. It does not explicitly mention that this is a read-only lookup, but the phrasing and 'returns' wording make that sufficiently clear.

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 tight and well-ordered: what the tool returns, cost behavior, and output shape in three short statements. No filler, and the most important distinction (keyword-overlap competitors) is front-loaded.

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 description covers input/output expectations, the default and maximum limit behavior, and the unusual free-on-empty cost ruleasia; without an output schema, the listed return fields are helpful. It lacks explicit notes on when the call is inappropriate or how country impacts results, but those are minor gaps.

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 fully documents `domain`, `limit`, and `country`, including defaults and constraints, so the description adds little new parameter semantics. The only added value is confirming that `limit` defaults to 50 and does not affect cost, which repeats the schema's own explanation.

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 concrete action: it lists domains competing for the same Google keywords as a target, and specifies top-100 keyword-overlap ranking plus the exact metrics returned (overlap share, average position, total keywords, traffic, ads). This clearly separates it from related tools such as backlink-focused competitor lookups.

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 when to use it ('Domains competing for the same Google keywords') and gives operational details like credit cost and free repeated lookups. However, it does not explicitly contrast it with sibling tools or state when not to use it, so the guidance is contextual rather than exclusionary.

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?

Adds meaningful behavior beyond annotations: credit costs for each size, the quote-confirmation flow for size 1000, free repeats for known-empty domains, and the limit/total_count return shape. No contradiction with the read-only annotation. It does not discuss data freshness or detailed row schema, but it is genuinely informative.

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 tightly packed: purpose first, then cost and quote behavior, then return behavior. No filler; the only minor issue is mild duplication of credit costs already present in the size parameter descriptions.

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 no output schema, it does well by naming the returned fields and total_count, and it explains the non-obvious quote-confirmation requirement. It could be more complete with explicit sibling routing, but as an invocation description it covers the important behaviors.

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%, including defaults, enums, domain normalization, country fallback, and the confirm_quote_id flow. The description adds little beyond what the schema already documents, so the baseline of 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 concrete resource: a domain's Google-ranked keywords, with specific fields (position, previous position, volume, estimated traffic, ranking URL). The 'domain ranks for' framing distinguishes it from keyword-centric siblings, but it never names an alternative explicitly.

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 by the purpose: choose this when you want keywords a domain ranks for. However, it does not provide explicit when-not guidance or compare against sibling tools like keyword_suggestions, related_keywords, or domain_competitors.

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 convey readOnly=true, openWorldHint=true, and non-destructive. The description adds valuable behavior beyond annotations: the one-credit cost, the free-when-no-rankings clause, and what the returned summaries cover. No contradiction with annotations.

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?

Three crisp sentences: scope, cost condition, and output summary. No filler or repetition of the schema. The most decision-relevant information (what it returns, cost) is front-loaded.

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 read-only overview query with no output schema, the description adequately states what the tool returns (organic and paid summaries) and the cost condition. It could mention output granularity or pagination, but those are minor given the annotations and the narrow scope.

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 each parameter already has a descriptive comment (e.g., 'us', 'gb', paths stripped, list_countries call). The description does not need to repeat parameter details. The mention of cost and free tier relates to billing, not parameters, so 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 names a specific resource (a domain's organic and paid search footprint) and enumerates the exact metrics returned: ranking keywords, estimated traffic, traffic value, position distribution, and movement. This distinguishes it from tools like backlinks_overview or ai_check without needing to open the 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?

No guidance is given about when to choose this tool over its siblings (e.g., ai_overview, backlinks_overview). The cost note and free-when-no-rankings condition are billing facts, not usage direction. An agent seeing sibling names gets no 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?

Annotations declare readOnlyHint=true and destructiveHint=false, and the description adds valuable behavioral context: cost structure (2/6/10 credits), the quote-confirmation flow for size 1000, free repeats for known-empty lookups, and the return shape (top limit pages plus total_count). This goes beyond what annotations alone provide.

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 compact and front-loaded with the core purpose, followed by cost and return details. Every sentence adds useful information. Slight redundancy with the schema (cost is mentioned in both description and size parameter description) but not enough to hurt clarity.

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 read-only lookup tool with 6 parameters and no output schema, the description covers the essential behavioral aspects: cost, confirmation flow, defaults, and return shape. It doesn't describe pagination beyond limit, but the limit parameter and total_count return value make that reasonably clear. The country default chain is well explained.

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 the schema already documents all 6 parameters. The description adds value by explaining the cost implications of size, the confirmation requirement for size 1000, and the default behavior for limit and country. It doesn't deeply explain order_by semantics, but the enum values are self-explanatory.

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: 'A domain's best-performing pages' with specific metrics (estimated traffic, traffic value, ranking keywords, average position, position split). It distinguishes itself from sibling tools like domain_overview and domain_keywords by focusing on pages rather than overall domain metrics or keyword-level data.

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 on when to use this tool (for top pages of a domain) and includes important usage details like cost tiers, confirmation flow for size 1000, and free repeats for known-empty lookups. It doesn't explicitly name alternative tools for when NOT to use it, but the sibling list and the page-specific focus make the use case clear.

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 destructiveHint=false, so the safety profile is covered. The description adds value by specifying the exact data fields returned and noting it's free (0 credits), plus the ordering hint to call it first. This exceeds the annotation 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?

Two sentences with zero waste. The key return fields are front-loaded, and the usage recommendation follows naturally. Every word 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?

For a parameterless read-only tool, the description fully explains what the agent gets back and when to use it. No output schema is needed because the description enumerates the fields. Nothing an agent needs is missing.

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 zero parameters, so schema coverage is trivially 100% and there is nothing to document. The baseline for 0 params is 4; the description appropriately focuses on output semantics instead of parameters.

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 credit balance, credits used today, daily cap, and default country. It names the resource (SearcherLite account) and explicitly says to call it when the user asks about balance or cost, distinguishing it from the search-focused siblings.

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?

Provides a specific trigger condition ('Call this first when the user asks about balance or cost'). It doesn't mention exclusions or alternatives, but given the unique purpose among siblings, the guidance is clear 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?

Annotations already provide readOnlyHint=true and destructiveHint=false, so the tool is safe. The description goes beyond by disclosing the cost in credits and the special free condition when no data exists – critical operational information not encoded in annotations. This transparency about costs is valuable for an AI agent managing budgets.

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 extremely concise: a single sentence listing the returned metrics, followed by two short lines on cost and free condition. No wasted words; every sentence is necessary. It's also front-loaded with the key purpose.

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 that the schema is complete (all parameters documented) and annotations cover safety, the description provides enough for an agent to call this tool correctly. It lacks some details like the exact format of the returned trend (e.g., historical dates), but the output is not critical for invocation. The tool is relatively simple (1 required param, no nested objects), so the description is adequate.

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 all parameters with descriptions (100% coverage), so the description needs to add minimal value. However, the description does mention the return metrics and the trend, which complements the schema. It doesn't add specifics on the country parameter's format beyond what the schema provides, but the schema is already detailed.

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: it retrieves search volume, CPC, keyword difficulty, competition, search intent, and 12-month trend for a single keyword via Google DataForSEO Labs. This distinguishes it from sibling tools like 'bulk_keyword_overview' (which handles multiple keywords) and related tools like 'keyword_suggestions' that serve different functions.

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 states the cost (1 credit) and free condition (when no data exists), which helps agents decide when to use this tool. However, it does not explicitly state when NOT to use it or mention alternatives like bulk_keyword_overview for multiple keywords. The sibling names suggest the distinction, but the description could be more explicit.

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 adds valuable behavior beyond the annotations: it performs one SERP call plus up to four follow-up expansions, costs 2 credits (free when no questions are found), returns only the first `limit` questions, and notes that answers are in structured content only. This materially informs the agent about side effects and output handling.

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 compact and well-structured: purpose first, then cost, then return shape. Every sentence carries useful information with 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?

For a tool with no output schema, the description covers the key behavioral details an agent needs: the data source, request expansion behavior, cost, row limiting, and structured-only answers. It could go slightly further by clarifying how the source domain field appears or how to handle the structured content, but the existing detail 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 the schema already documents all four parameters. The description adds only marginal parameter-related context by referencing `limit` in the return behavior, which is helpful but does not meaningfully extend what the schema already states.

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 resource ('Questions people ask around a keyword'), a concrete source (Google People Also Ask), and what the return value includes (questions with source domain). This clearly distinguishes it from sibling tools like keyword_suggestions or related_keywords without needing to open the 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 context is clear: use this when you need People Also Ask questions for a keyword, backed by SERP call and follow-up expansion details. However, it does not explicitly say when not to use it or name alternatives, so the agent must infer the boundary against siblings like serp_analysis or keyword_suggestions.

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?

Beyond the annotations (readOnlyHint: true, destructiveHint: false), the description discloses the 2-credit cost and that it is charged even when no results are found, plus the default sorting by volume. This adds practical behavioral detail that annotations do not cover, without contradicting them.

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?

Three short sentences front-load the core purpose, then cover cost and return format. Every sentence adds value, with no filler 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?

The description covers cost, return sorting, and included metrics, but does not explain when to prefer this tool over siblings, nor the structure of the returned items beyond mentioning fields. Given no output schema and moderate complexity, it is adequate but has clear gaps.

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 all parameters are documented. The description adds extra meaning for 'limit' by explaining it returns the top rows by volume, and clarifies the default of 50, but does not elaborate on country or confirm_quote_id 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 clearly states that the tool returns long-tail keyword suggestions containing the seed keyword, along with metrics like volume, KD, CPC, and intent. It is specific about the output and distinguishes itself from related tools like keyword_overview by focusing on suggestions rather than overviews, though it doesn't name a sibling explicitly.

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 no guidance on when to use this tool versus alternatives such as related_keywords or keyword_questions. It mentions cost and returns, but lacks any 'use this when' or 'instead of' statements, leaving the selection to inference.

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 destructiveHint=false, so the safety profile is covered. The description adds value by stating the free credit cost (0 credits) and explicitly naming the argument it relates to, which is useful behavioral context beyond the annotations.

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, efficiently worded sentence that front-loads the core information (what codes are returned) and includes examples and cost. No wasted words 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?

For a simple zero-parameter tool, the description is sufficient: it explains the output content and gives examples. It does not specify the exact return format (e.g., array of strings), but given the simplicity and absence of an output schema, this is a minor gap. The mention of the argument name and credit cost adds enough context for an agent to use it 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 tool has zero parameters, so the baseline is 4 per the rules. The description does not need to add parameter details since there are none; it correctly focuses on the output.

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 clear purpose: it returns all country/language codes accepted by the `country` argument, with concrete examples. This is distinct from any sibling tool, which all deal with SEO/analytics operations rather than enumerating valid parameter values.

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 when to use this tool: when you need to know which codes are valid for the `country` argument. It also notes the tool is free (0 credits), which is a relevant usage consideration. However, it does not explicitly mention when not to use it or name alternatives, though no direct sibling exists for this functionality.

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?

Beyond the readOnly and destructive annotations, it discloses a non-obvious cost of 2 credits charged even when nothing is found, the depth-3 Google source, and deterministic ordering by volume. This gives the agent genuinely useful 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?

The description is compact and front-loaded: it states the output scope, data source, cost, and ordering in three short sentences with no redundant 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?

For a read-only tool with no output schema, it explains the returned content, ordering, limit, and cost, while the schema covers country and limit defaults. It could be slightly more complete by listing exact output field names, but it is largely 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 input schema already covers all 4 parameters at 100% coverage, so the baseline is 3. The description adds meaning by explaining that the limit selects the top rows by volume, which is not fully stated in the schema's parameter descriptions.

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 what the tool returns: up to 100 related keywords for a seed keyword, with volume, KD, CPC, and intent, sourced from Google's 'searches related to'. It does not explicitly distinguish itself from similar sibling tools like keyword_suggestions, 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?

The description gives operational details such as cost and result ordering, but no guidance on when to use this tool versus keyword_suggestions or other keyword-oriented siblings. There is no explicit when-to-use, when-not-to-use, or alternative recommendation.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely extra behavioral context: the 1-credit cost, the fact that it is charged even for empty pages, and the summarized return shape. No contradictions exist.

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?

Three short, dense sentences with no filler. The first sentence front-loads the core result contents, the second covers cost, and the third summarizes the return. Every phrase adds value.

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 required parameter and a fully described schema, the description is nearly complete. It states the return format, credit cost, and empty-page behavior. Minor missing context, such as potential country fallback logic, is already handled in the schema, so the definition is 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-level semantics beyond the schema, but that is acceptable because the schema already documents keyword, country, and confirm_quote_id in detail.

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 specifies the resource ('Google results page') and the specific output elements: top 10 organic results, SERP features, featured snippet, AI Overview, People Also Ask, and related searches. This makes the tool's purpose concrete and distinguishes it from siblings like keyword_overview or ai_overview without being tautological.

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 no explicit guidance on when to use this tool over the many siblings, nor any when-not-to-use conditions. The implied use case (analyze a live SERP) can be inferred, but the agent is given no decision rule or alternative tool recommendations.

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