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

The description discloses the use of SerpAPI, the free tier quota, and the need to set SERPAPI_KEY. It also notes that location affects eligibility. Without annotations, this covers key behavioral aspects, though rate limiting and error handling are not mentioned.

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 consists of three concise sentences that front-load the purpose, followed by dependency and setup info. 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?

For a simple check tool with no output schema and no annotations, the description adequately covers purpose, external service, key parameter effect, and setup. It is complete given the tool's complexity.

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 has complete descriptions for all three parameters (100% coverage). The description adds value by noting that location affects AI Overview eligibility, which is not in 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 clearly states the verb 'check' and the resource 'AI Overview', and specifies the output 'which URLs it cites'. The purpose is distinct from sibling tools like 'am_i_cited' which check citations differently.

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 mentions the SerpAPI dependency and free tier limit, which informs usage constraints. However, it does not provide explicit guidance on when to use this tool versus siblings or when not to use it.

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, so the description carries full burden. It mentions cost implications and auto behavior, but lacks disclosure on rate limits, quotas, or idempotency. A moderate score as it adds some 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 succinct sentences with clear front-loading of purpose. Every sentence adds value, and 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?

Given the complexity (3 params, no output schema), the description covers purpose, usage, and parameter nuances adequately. It mentions output structure (per-query presence, rank, summary) but could elaborate on response format. Minor gap.

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%, but the description adds value by explaining the 'auto' engine behavior and clarifying that 'bing_serp'/'brave_serp' measure web rank, not LLM citations. This goes beyond 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 clearly states the tool checks if a domain is cited by AI engines across queries, returning per-query presence, rank, and citation-rate summary. It distinguishes from sibling 'check_citations' by referencing it in the engine parameter.

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: 'Use to measure visibility for a brand, product, or content site in AI search.' It also advises pinning to a specific engine to reduce cost and directs web rank queries to 'check_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?

With no annotations provided, the description fully discloses the tool's behavior: it calls check_citations, bins positions into early/middle/late thirds, and returns 'unknown' for certain engines. This is complete and transparent.

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, each earning its place: first states the action, second explains the mechanism, third notes an edge case. 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?

The description covers what the tool does, how it works, and when it returns 'unknown'. It lacks explicit output format details (e.g., per-citation position), but the overall picture is sufficient for an agent to decide when to use it.

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?

Despite 100% schema coverage, the description adds context: it explains how each parameter is used (e.g., engine's effect on output, max_results limits citations), enhancing understanding 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 provides a specific verb ('Locate') and resource ('where each cited URL appears'), clearly distinguishing the tool's purpose from siblings like check_citations by explaining how it bins positions into thirds.

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 implicitly guides usage by noting that engines without raw_answer (Bing, Brave) return 'unknown', advising against use in those cases. However, it does not explicitly compare to alternatives like directly using check_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?

With no annotations provided, the description carries full burden. It discloses fetching sitemap, running predict_citation, sorting, and that no engine keys are needed. It hints at rate-limit risk via the concurrency parameter description but does not detail error handling or performance guarantees.

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, no wasted words. The first sentence captures the core action, the second adds sort order and value proposition. Front-loaded and 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?

The description does not specify the output format (e.g., array of objects with URL and citation score) despite no output schema. It mentions sorting but lacks details on structure. For a tool that wraps predict_citation, the return is likely consistent, but this is not explicit.

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?

All three parameters have descriptions in the schema (100% coverage). The description adds valuable context: for sitemap_url it clarifies nested sitemaps are followed, for limit it explains slicing, and for concurrency it mentions parallel calls and rate-limit risk. This goes well 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 clearly states the tool fetches a sitemap and runs predict_citation on each URL, returning results sorted worst-first. It distinguishes from sibling tools by emphasizing whole-site systemic issue detection, unlike single-URL tools like predict_citation.

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 whole-site audits and notes 'Zero engine keys needed' as a prerequisite. It does not explicitly state when not to use it or name alternatives, but the context of batch processing is 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?

With no annotations, description carries full burden. It explains the aggregation by registered domain, per-engine breakdown, and top URLs. Missing details like error handling or rate limits, but core behavior is well disclosed.

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 sentences with clear front-loading: action first, then outcome, then usage. No redundant or vague language.

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 and no annotations, description adequately covers input, process, and output. Mentions output includes top domains, per-engine breakdown, and top URLs. Could specify ranking metric or confidence indicators, but sufficient for selection and use.

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%, baseline 3. Description does not add parameter-specific details beyond schema; e.g., 'aggregate citations by registered domain' clarifies output behavior rather than parameters. Schema descriptions are already thorough.

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 fans a query across engines, aggregates citations by registered domain, and returns top competitor domains with cross-engine consensus. It distinguishes from siblings like 'compare_domains' by focusing on registered domain aggregation and consensus ranking.

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?

Explicitly says 'Use to identify the canonical competitor set for a query - the domains every engine treats as authoritative.' Provides clear context but does not explicitly state when not to use or list alternatives among sibling 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?

Without annotations, description carries full burden. It discloses auto-pick engine behavior and differences between engine types (consumer_scrape, api_proxy, web_rank) via the engine parameter description. However, it lacks mention of rate limits or failure modes.

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 concise sentences that front-load the purpose and usage context. No extraneous 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?

No output schema, but description hints at returning a list of URLs. For a tool with engine selection logic and 4 params, it provides sufficient context, though explicit output structure would help.

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 baseline is 3. The tool description adds value by explaining the API key requirement and when to use, but parameter details are fully covered in 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 clearly states the tool returns URLs cited by AI engines for a query, using a specific verb and resource. It distinguishes from sibling tools like 'citation_evidence' or 'citation_provenance' by focusing on AI search engine sources.

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?

Explicitly says when to use ('when agent or user wants to see sources an AI search engine grounds answers on') and mentions the API key prerequisite. Does not explicitly list alternative tools but context is 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?

No annotations, but description fully discloses behavior: calls check_citations, finds first mention in raw_answer, returns context window plus nearest quoted span or sentence, and returns 'not found' for engines without raw_answer. No contradictory or hidden behavior.

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 sentences, front-loaded with purpose, each sentence adds unique value: action, process, usage guidance, edge case. No redundancy or fluff.

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, description adequately explains input behavior and return types (context window, quoted span, 'not found'). Could be more explicit about output structure, but sufficient for an extraction tool with clear process.

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% (all 4 params described in schema). Description adds workflow context (how params are used) and clarifies engine-specific behavior (web_rank engines lack raw_answer), but overall value added is moderate 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?

Description states specific verb 'Extract' and resource 'cited snippet' and distinguishes from sibling check_citations by explaining 'use to see why an engine cited a URL, not just that it did.'

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?

Explicitly says 'Use to see why an engine cited a URL, not just that it did' and warns about engines without raw_answer (Bing, Brave). Could be more explicit about when not to use, but provides clear context relative to 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?

No annotations provided, but description discloses it calls check_citations, collects dateModified, computes a recency score with halflife=365d, and returns per-URL buckets. This is adequate behavioral context for a read-only analysis tool.

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 concise sentences: first defines core action, second adds technical detail, third gives use case. Front-loaded with purpose; 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?

For a tool with 3 params and no output schema, the description sufficiently explains input, process (calling another tool, collecting data), and output (score 0-100, buckets). Missing explicit bucket thresholds but still functional for agent selection.

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 100% of 3 parameters with descriptions. The description adds process context but does not supplement parameter meaning (e.g., engine enum, max_results cap) beyond what schema already provides.

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 specific verb 'score' and resource 'recently of pages cited for a query', clearly distinguishing from siblings like check_citations (which likely just retrieves citations) and other citation analysis 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?

States the value proposition ('surfaces queries where AI cites old content') and implies the tool is for freshness analysis, but does not explicitly list when not to use or contrast with alternatives.

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 bears the burden: it explains multiple engine queries, output structure per URL, consensus_urls as URLs cited by all engines, and how to interpret engine_count (high=strong, 1=engine-specific). No behavioral surprises.

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 purpose, no filler. Every word contributes meaning, making it efficient and easy 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?

No output schema, but description fully explains return structure (list of URLs with engines, consensus_urls) and interpretation. Covers all necessary context for an agent to invoke and understand 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?

Schema coverage is 100%, baseline 3. The description adds value: explains default engines (all LLM with keys) and when to include bing/brave serp, plus default and role of max_results. This goes beyond schema definitions.

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 fans out a query across multiple AI engines and reports per-URL cross-engine consensus, directly distinguishing it from sibling tools like check_citations (single citation check) or citation_evidence (evidence gathering).

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 (need cross-engine consensus) and explains output interpretation. However, it doesn't explicitly list alternatives or when not to use, though sibling context and description hint at differentiation.

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 bears full responsibility for behavioral disclosure. It only describes the output (series and deltas) but does not state whether the tool is read-only, requires specific permissions, or has any side effects. The mutation or safety profile is not addressed.

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 action and output summary. No redundant information. Every word contributes to understanding.

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 is adequate for a simple tool with no output schema, but it lacks details on error handling, default behavior (e.g., if no snapshots exist), and the exact structure of the returned data (e.g., format of the series and deltas). Given zero behavioral annotations and no output schema, more completeness would be beneficial.

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 parameter descriptions. The description adds meaningful context beyond the schema by clarifying that the tool uses 'stored snapshots' and returns a temporal series with deltas, which helps the agent understand the parameter 'since' as a filter on snapshots.

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 'Report' and the resource 'citation rate over time for a panel from stored snapshots.' It specifies the output includes a series of citation_rate per snapshot and per-query deltas. While it does not explicitly differentiate from sibling citation tools, the purpose is specific and unambiguous.

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 like check_citations or citation_evidence. It does not mention prerequisites, context scenarios, or exclusions. The agent must infer usage from the purpose 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?

No annotations, so description carries full burden. It discloses cache-based operation and no API cost. However, does not explain behavior when cache is empty or domain missing. Could be more explicit about error cases, but main behavioral trait is 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?

Two sentences: first states purpose and source, second gives usage context. Front-loaded, no wasted words. Efficient communication.

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 4 parameters, no output schema, and no annotations, the description is mostly complete. It explains tool's niche and when to use. Missing return format or behavior on empty cache, but acceptable for simple list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds no extra parameter-level information beyond what schema provides. No additional context for domain, since, engine, or limit.

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 lists queries cited for a domain from the local cache. The verb 'list' and resource 'queries cited for domain' are specific. It distinguishes from siblings check_citations and am_i_cited by noting cache usage.

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?

Explicitly instructs to build corpus via check_citations/am_i_cited first, then use cited_for to query cache without spending API budget. Provides clear when-to-use vs alternatives.

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. It states 'Cache-only, no API spend,' which is valuable behavioral info. It also explains the meaning of gained/lost queries, adding transparency 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?

Two sentences with no wasted words. The first sentence immediately states the core function; the second adds context and usage. Ideal brevity for an agent.

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 4 parameters and no output schema, the description covers purpose, parameters, behavioral note, and usage. It does not explain the return structure, but that is not required given the lack of output schema. Still comprehensive.

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 baseline is 3. The description adds value by clarifying how 'baseline_until' and 'current_since' define the two time windows and explaining the 'engine' filter. It slightly exceeds the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs ('diff', 'track citation drift') and clearly defines the resource ('cited_for between two time windows'). It distinguishes from the sibling 'cited_for' by focusing on comparison across time periods.

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 states when to use the tool: 'Use to track citation drift over time after publishing or migrating content.' It does not mention when not to use it or provide alternatives, but the context is 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?

No annotations are provided, so the description carries full burden. It describes the operation and output but does not disclose any behavioral traits such as side effects, authentication needs, or rate limits. This is insufficient for a tool with no 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 two sentences, front-loads the core functionality, and has no wasted words. It is concise and well-structured.

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 has one parameter and no output schema, the description covers input, operation (runs predict_citation), output format, and use case. It is complete enough for an agent to understand when and how to use it, though it assumes knowledge of predict_citation.

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 description already explains the 'urls' parameter well. The description adds a small nuance ('One is typically yours'), but does not significantly extend the schema's meaning. 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 runs predict_citation on 2-10 URLs and returns a side-by-side signal table plus divergence list. It distinguishes from sibling tools like predict_citation (single URL) and compete_for_query (different focus).

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 says 'Use to compare your URL to top-cited competitors for the same query,' providing a clear use case. It does not mention when not to use or list alternatives, but the context is adequate.

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 covers behavioral traits by explaining the orchestration steps and return values ('your score, the average competitor score, and the gap'), though it omits potential side effects (likely none).

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 succinct sentences front-load the purpose and orchestration, 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?

The description adequately explains the tool's function and return values despite no output schema, and accounts for the orchestration of sub-tools, though it could mention that sub-tool behaviors apply.

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 good descriptions; the tool description adds context to parameters by relating them to the workflow (e.g., max_competitors references compare_domains limit) but does not provide significant new meaning beyond what schema offers.

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 it is an 'End-to-end competitive snapshot for a single query' and outlines the orchestration of check_citations and compare_domains, distinguishing it as a higher-level tool from 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?

The description explains the workflow but does not explicitly state when to use this tool versus alternatives like check_citations or compare_domains individually, nor does it provide when-not conditions.

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, so description carries full burden. It discloses that the tool parses robots.txt and performs live GET requests with each bot's User-Agent, surfacing both robots.txt blocks and UA-based gating. However, it does not mention potential impacts such as rate limits or server log implications.

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 main purpose, and each sentence provides essential information 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?

The description explains what the tool does but lacks details about the output format or return values. Given the complexity (multiple bots, live fetch) and no output schema, the description should mention what the user can expect as a result (e.g., a list of blocks vs. successful fetches).

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 baseline is 3. The description adds context about the default bot list and the behavioral effect of 'fetch_with_ua' but does not add significant meaning beyond the schema 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 it verifies AI crawler access, lists specific bots, and explains it parses robots.txt and does live GET requests. This differentiates it from siblings like 'check_citations' or 'citation_evidence' which focus on citations, not crawler access.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly tells users to use this tool to verify AI crawler access for a URL. It doesn't explicitly state when not to use or name alternatives, but the context of sibling tools makes it clear this is the appropriate choice for crawler access auditing.

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 mentions credential requirements but does not disclose behavioral traits (e.g., idempotency, side effects, rate limits). The word 'join' suggests a read-only operation, but more explicit transparency would improve interpretation.

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 purpose and quickly covering prerequisites. Every word adds value with no 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?

Given no output schema, the description should explain return values. It hints at output (queries with gaps) but lacks structure details. For a tool combining two data sources, more output context is needed for complete understanding.

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 description adds valuable context beyond the schema: domain is used for both GSC and citation check, queries are limited to 1-20, and defaults for site_url and engine are noted. This significantly helps an agent understand parameter 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 clearly states the tool 'joins Google Search Console performance with am_i_cited per query' and 'surfaces queries where the domain ranks well in Google but is not cited in AI', distinguishing it from siblings like am_i_cited or check_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 specifies a prerequisite ('requires GCP service account creds') and implies the use case (finding citation gaps). It does not explicitly exclude scenarios, but the purpose is clear enough for an agent to decide when to invoke.

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 burden for behavioral disclosure. It explains key behaviors: parsing sitemap.xml and nested indexes, grouping URLs by top-level path, truncating after limit, and the slower title-fetching mode. It does not mention authentication or rate limits, but such details are less critical for a generation tool.

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 main purpose and process. Every sentence contributes necessary information: the first covers the core functionality, the second explains the key optional parameter's trade-off. 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 the tool has no output schema, the description adequately describes the output format (Markdown with H1, description, sectioned link lists). It covers all parameter interactions, the grouping logic, and the title-fetching behavior. For a tool with 5 parameters, this is complete and leaves no major gaps in understanding.

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 baseline is 3. The description adds value beyond the schema by explaining the overall process and how parameters like fetch_titles affect behavior. It also clarifies that site_description is optional but recommended, and that limit applies before title fetch.

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 generates an llms.txt file from a sitemap, specifying the process (parsing, grouping, emitting) and the output format (Markdown with H1, description, sectioned link lists). It distinguishes from sibling tools like audit_sitemap or sitemap_citation_map by its unique function.

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 use: when you have a sitemap URL and want to generate an llms.txt file. It explains the optional fetch_titles flag and its trade-off (slower but richer). However, it does not explicitly mention when not to use this tool or suggest alternatives, though the sibling list implies differentiation.

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?

Explicitly states no LLM is used ('all heuristic'), lists the specific signals checked, and describes the output format (score, grade, breakdown, fixes). No annotations exist, so description carries full burden; it is mostly adequate.

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: first states purpose and signals, second clarifies method and output. No redundant text, front-loaded with key information.

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 no output schema, the description fully explains the output (0-100 score, grade, signal breakdown, ranked fixes) and the heuristic approach. All relevant aspects are covered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'url' is well-documented in the schema (100% coverage). The description adds a list of signals but does not elaborate on the parameter itself beyond what the schema provides.

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?

Clearly states it scores citation likelihood for a URL using public signals. Distinguishes from siblings like 'am_i_cited' (which checks if cited) and 'check_citations' (which verifies existing citations) by focusing on prediction via heuristics.

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?

Implied usage: use when you want to predict citation potential from web signals. No explicit when-not-to-use or alternatives mentioned, leaving the agent to infer from context.

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 tool runs through am_i_cited, appends a snapshot, stores it at a path, and feeds citation_trend. However, it lacks details on error handling, prerequisites (e.g., panel existence), rate limits, or side effects. With no annotations, more behavioral context would be beneficial.

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 with no extraneous information. It is front-loaded with the core action and provides additional details on storage and downstream use efficiently.

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 explains the output is a snapshot file stored in a specific path, but with no output schema, it does not describe the snapshot's contents or format. For a tool that integrates with citation analysis, more detail on the snapshot's 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 schema covers all three parameters with descriptions. The description adds that the 'name' parameter must be a panel saved via track_queries, which is helpful. But for 'domain' and 'engine', it adds no extra meaning beyond the schema. Baseline score of 3 is appropriate given high schema coverage.

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 runs a saved panel through am_i_cited, appends a timestamped snapshot, and specifies the snapshot storage path. It distinguishes from siblings by naming specific tools it integrates with (am_i_cited, citation_trend).

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 running a previously saved panel via track_queries, but does not explicitly state when to use this tool versus alternatives like check_citations or citation_evidence. No when-not-to-use guidance is provided.

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, so description carries full burden. It describes parsing, validation logic per @type, flagging missing fields/malformed JSON, and returns issues list and verdict. Does not mention read-only nature or safety, but validation implies non-destructive behavior.

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 concise sentences that front-load the main purpose, then detail specific checks, and end with usage recommendation. 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?

Describes input (URL), process (parsing and validation), output (issues list and verdict), and provides examples of checks. Since no output schema exists, this explains return values adequately.

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 'url' with a schema description that matches the description. Schema coverage is 100%, so the description adds minimal extra meaning 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 it performs deep schema.org validation for a URL, parsing all JSON-LD and microdata, and returns issues/verdict. It distinguishes from sibling tools by mentioning it fixes bugs that predict_citation can't explain.

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?

Explicitly says to use when predict_citation flags bugs but can't explain them, providing clear use case context. Does not explicitly state when not to use, but sibling differentiation implies alternatives.

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. It discloses that the tool follows nested sitemaps, reports citation presence with counts, and requires cache priming. It does not mention idempotency or error conditions, but the core behavior is well covered.

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 sentences, no fluff. The first sentence states purpose, the second differentiates from a sibling, the third gives a crucial prerequisite. Every sentence adds value and the structure 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?

Given no output schema, the description partially explains output (reports whether cited and counts). It also mentions dependency on cache priming. The tool is relatively simple; this level of detail is sufficient for an agent to understand when and how to invoke it.

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% (all parameters have descriptions), so the schema already explains each parameter. The description does not add additional semantic context beyond what the schema provides, meeting the baseline expectation.

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?

Clearly states the tool cross-references a sitemap with the citation cache, reporting which URLs have been cited. Distinguishes from audit_sitemap by describing it as the inverse operation. The verb 'cross-reference' and nouns 'sitemap' and 'citation cache' precisely define the resource and action.

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?

Explicitly describes when to use (to check if each sitemap URL has been cited), contrasts with audit_sitemap, and provides a prerequisite: cache must be primed via check_citations or run_panel first. This helps the agent select the right tool and prepare needed state.

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: fetches page, detects schema, returns ready-to-paste templates, pre-fills from metadata, and flags manual fields. It does not mention any side effects or limitations, but covers key behavioral aspects.

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 (5 sentences) with no wasted words. The main purpose is stated first, followed by process details, examples, and output format. Efficient 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?

Given a simple input and no output schema, the description covers everything: input, process, output (templates), and example triggers. It is fully sufficient for an agent to understand and use 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 single parameter 'url' is described with more detail than the schema alone: 'The page is fetched and its content signals are used to suggest schema types.' This adds value beyond the schema's basic description.

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 action ('Suggest missing JSON-LD additions') and the resource ('for a URL'). It distinguishes from sibling tools like schema_audit by focusing on adding missing types rather than auditing existing ones.

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 context on when to use (when missing JSON-LD is suspected) and lists example scenarios (BlogPosting, FAQPage, etc.). However, it does not explicitly state when not to use or directly compare to alternatives, though the sibling list is provided.

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 full burden. It discloses that panels are persisted under a specific file path, implying stateful behavior. However, it does not explain if save overwrites, if there are any destructive side effects, or any auth/rate limit info.

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 with no wasted words. The first sentence states the core purpose, the second gives usage guidance, and the third adds storage context. It is front-loaded and 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?

The tool has 4 parameters, 3 actions, no output schema. The description covers all actions, gives example, explains persistence. It doesn't describe return values for load/list, but the actions imply it returns queries. Could mention that load returns a panel object, but it's sufficient for an AI 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?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the relationship between action and queries parameters, and gives a concrete example ('editorial-watchlist') and the storage location, which goes beyond schema 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 the tool saves, loads, or lists named query panels, using specific verbs and resources. It distinguishes from siblings by focusing on panel management, which is unique among the listed 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 explains when to use each action (save, load, list) and provides context for why you'd use panels (monitor queries over time). It does not explicitly say when not to use, but the actions are self-explanatory.

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 disclose behavioral traits. It only adds 'Zero keys required' beyond the schema. It does not mention rate limits, pagination behavior, error handling, or what happens if the domain has no mentions. This is insufficient for a tool with no 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 two sentences, front-loading the core purpose in the first sentence. The second sentence adds context about the signal's importance and access. No redundant or unnecessary information.

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 agent does not know what fields are returned (e.g., article titles, URLs). The description only says 'list Wikipedia articles', leaving ambiguity. Parameter details are well-covered by the schema, but the output format 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 tool description adds no additional meaning beyond what the schema already provides for each parameter (domain, limit, lang).

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 'list', the resource 'Wikipedia articles', and the scope 'that reference the given domain'. The additional context about being a 'highest-lift signal' provides useful rationale, and the tool is distinct from siblings like 'check_citations' or 'citation_evidence'.

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 assessing citation importance via the 'highest-lift signal' line, but it does not explicitly state when to use this tool over alternatives, nor does it mention when not to use it. No exclusions or alternatives are provided.

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