Commit — Supply Chain Risk Scoring

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

No annotations are provided, so the description must carry the full burden. It describes the output format (risk table sorted by commitment score), risk flags (CRITICAL, HIGH, WARN), and special handling for Go (maintainers column). It does not discuss rate limits or authentication, but it is transparent about the core 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?

The description is front-loaded with the purpose and includes a risk flag breakdown and Go-specific notes. While somewhat verbose, every section earns its place. It is well-structured and informative without being excessively long.

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 2 parameters, 100% schema coverage, and no output schema, the description fully explains the output (risk table, sorted by commitment score, risk flags) and ecosystem-specific behaviors. It covers all necessary information for correct usage.

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 significant meaning: it clarifies Go module path requirements, the 'auto' ecosystem detection, and the meaning of the maintainers column. Examples in the packages parameter provide concrete usage. This exceeds the schema's 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 clearly states the tool batch-scores packages for supply chain risk, specifying verb (batch-score), resource (multiple packages), and output (risk table sorted by commitment score). It distinguishes from siblings like lookup_* and audit_dependency_tree.

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 usage contexts like auditing package.json, requirements.txt, etc., and gives concrete examples (score all deps, compare packages, identify abandonware). It does not explicitly state when not to use, but the sibling tools imply single-package lookup 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?

No annotations provided, so description carries full burden. It discloses traversal behavior, risk levels (CRITICAL, HIGH, WARN), and depth parameter effects. Lacks mention of rate limits or authentication, but core behavior is well explained.

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?

Well-structured with headings, bullet points, and examples. Front-loaded with purpose. While comprehensive, it is slightly verbose; could be tightened without losing meaning.

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 explains what output contains (risk flags, dependency tree). Covers complexity of traversal depth and risk assessment. Differentiates well from sibling tools listed.

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 description adds significant value: explains risk levels, depth behavior with examples, and usage patterns. Goes well beyond the basic 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 maps the full dependency tree of npm packages and identifies supply chain risks. It uses specific verbs ('map', 'identify') and resource ('dependency tree'). It distinguishes from siblings like audit_dependencies and lookup_npm_package by emphasizing graph traversal.

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 explicit use cases and example queries ('What am I really depending on?'). Does not explicitly state when not to use or compare with alternatives, but context is clear. A minor gap for full marks.

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 explains the process (fetches files, runs scoring) and risk flags, but doesn't mention authentication or side effects. Still strong for a read-only audit 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?

Well-structured: clear opening sentence, bullet points for risk flags, and several examples. No 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?

Comprehensive for the tool's complexity: explains inputs, process, output (risk table with flags). No output schema, but description suffices.

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?

Single parameter 'repo' with 100% schema coverage. Description adds value by providing examples and clarifying acceptable formats beyond the schema 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 it audits supply chain risk by fetching package files and running commitment scoring. It distinguishes from sibling tools like lookup_github_repo and audit_dependencies.

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 tells when to use: 'fastest way to audit a project', gives usage scenarios ('is my project at risk?'), and provides multiple examples.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: it's a read-only search operation (implied by 'Search' and 'get'), discloses the data source and its characteristics ('free, verified, unfakeable'), and outlines the return content ('commitment signals: longevity, financial health, employee count, and overall commitment score'). It doesn't mention rate limits or authentication needs, but covers the core behavior well.

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 efficiently structured in two sentences: the first states the purpose and data source, and the second details the return values and data quality. Every sentence adds value without redundancy, making it front-loaded and appropriately concise for the tool's complexity.

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 annotations and no output schema, the description does a good job of covering the tool's context: it explains the purpose, data source, and return values. However, it doesn't specify the format of the commitment score or other return details, which could be helpful for an agent. It's mostly complete but has minor gaps in output specification.

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 description coverage is 100%, with the single parameter 'query' already documented in the schema as 'Business name to search for'. The description doesn't add any additional parameter semantics beyond what the schema provides, such as search syntax or matching behavior. Baseline 3 is appropriate since the schema handles the parameter documentation adequately.

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 specific action ('Search for a Norwegian business and get its commitment profile'), identifies the resource ('public data from Brønnøysund Register Centre'), and distinguishes it from siblings by focusing on Norwegian businesses rather than packages or repositories. It provides concrete details about what the tool does beyond just the name.

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 context by specifying it's for Norwegian businesses and mentions the data source, which helps differentiate it from sibling tools like lookup_github_repo or lookup_npm_package. However, it doesn't explicitly state when to use this vs. lookup_business_by_org or query_commitment, leaving some ambiguity about 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 provided, the description carries the full burden of behavioral disclosure. It mentions the return data types ('temporal, financial, and operational commitment signals') but lacks details on error handling (e.g., invalid org numbers), rate limits, authentication needs, or response format. For a lookup tool with no annotation coverage, this leaves significant gaps in understanding operational 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?

The description is two concise sentences with zero waste: the first sentence states the purpose and input, and the second specifies the output and source. It's front-loaded with key information and efficiently 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 no annotations and no output schema, the description provides basic purpose and output types but lacks details on response structure, error cases, or operational constraints. For a simple lookup tool with one parameter, it's minimally adequate but incomplete for reliable agent use without additional context.

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

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

Schema description coverage is 100%, so the schema already fully documents the single required parameter 'orgNumber' with its format. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't clarify if the number includes hyphens or other variations), meeting the baseline for 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 specific action ('Look up'), resource ('Norwegian business'), and key identifier ('by organization number'), distinguishing it from siblings like 'lookup_business' (which lacks the orgNumber specificity) and 'query_commitment' (which likely queries differently). It specifies the exact data source (Brønnøysund Register Centre) and output type ('commitment profile').

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 when you need commitment data for a Norwegian business via its org number, but it doesn't explicitly state when to use this vs. alternatives like 'lookup_business' (which might use different identifiers) or 'query_commitment' (which might have broader scope). No exclusions or prerequisites are mentioned, leaving some ambiguity.

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 weight. It implies a read-only operation ('Get a profile') and explains the behavioral trait of returning signals. No contradiction or hidden side effects 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?

Concise, front-loaded with purpose, then details, then examples. No unnecessary 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?

No output schema, but description enumerates return signals (crate age, download volume, etc.). Adequate for a lookup tool; could mention error handling or rate limits, but not required for basic usage.

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?

Single parameter 'crate' with 100% schema coverage. Description adds examples and notes case-insensitivity, 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 clearly states it 'get[s] a behavioral commitment profile for any Rust crate on crates.io' and lists specific signals returned. This distinguishes it from sibling tools that cover other ecosystems (npm, PyPI) or perform audits.

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 mentions use cases: 'vetting Rust dependencies before adding to Cargo.toml, identifying abandonware, supply chain risk assessment.' No explicit when-not-to-use, 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly describes the tool's behavior: it returns 'real signals that prove genuine investment' such as project age, commit frequency, contributor size, release cadence, and social proof. It also notes these are 'harder to fake than README claims,' indicating the tool's analytical nature. However, it lacks details on rate limits, error handling, or authentication needs, which are minor gaps.

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 well-structured and front-loaded, starting with the core purpose, followed by details on returns, usage scenarios, and examples. Most sentences add value, though the explanation of 'behavioral commitments' could be slightly condensed. It efficiently conveys necessary information without 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 the tool's moderate complexity (single parameter, no output schema, no annotations), the description is largely complete. It covers purpose, behavior, usage, and examples. However, it doesn't detail the output format or potential limitations (e.g., rate limits, error cases), which would enhance completeness for an agent invoking 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 input schema has 100% description coverage, with the 'repo' parameter well-documented in the schema itself. The description adds minimal value beyond the schema by providing examples in the text (e.g., 'vercel/next.js'), but doesn't explain parameter semantics like format constraints or edge cases. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description explicitly states the tool's purpose: 'Get a behavioral commitment profile for any public GitHub repository.' It specifies the verb ('Get'), resource ('behavioral commitment profile'), and target ('public GitHub repository'), clearly distinguishing it from sibling tools like audit_github_repo or lookup_npm_package by focusing on behavioral analysis rather than auditing or package-specific 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 provides explicit usage guidance with a 'Useful for:' section listing specific scenarios (e.g., vetting dependencies, evaluating AI tools, due diligence). It also includes examples of valid inputs, helping users understand when to apply this tool versus alternatives like audit_dependencies or lookup_npm_package, though it doesn't explicitly name when-not-to-use cases.

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 carries behavioral disclosure. It explains the tool's reliance on GitHub data, notes the absence of download counters, and clarifies that git push access equates to publishing. This provides strong transparency about what the tool reports and why.

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 moderately detailed but well-structured: purpose first, then return signals, ecosystem context, use cases, examples. Every sentence adds useful information; small redundancy could be trimmed but overall effective.

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 what the tool returns (age, version count, etc.) and addresses ecosystem specifics. It covers input, behavior, and use cases comprehensively for a focused 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?

Only one parameter ('module') with 100% schema coverage. The description adds value beyond the schema by providing multiple examples, case-sensitivity note, and requirement for the host, making usage more concrete.

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

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

The description clearly states the tool retrieves a 'behavioral commitment profile' for Go modules, specifying input as full module path and listing return signals. It distinctly separates from sibling tools like audit_dependencies and lookup_npm_package by focusing on Go's ecosystem.

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?

Explicit use cases are given ('vetting Go dependencies... supply chain risk assessment'), explaining the GitHub-primary nature. However, it does not explicitly state when not to use or mention alternative tools, though context implies its specialized role.

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

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

No annotations exist, so the description carries full burden. It transparently explains what the tool returns (real signals, age, download trend, etc.) and why these signals matter, including limitations of simpler metrics like download counts and stars. It also implies a read-only operation with no side effects.

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 well-structured with clear sections (purpose, behavioral signals rationale, use cases, examples). It is slightly verbose but every sentence adds value, making it appropriate for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (single parameter, no output schema), the description covers all necessary information: what it does, what it returns, why it matters, and how to use it. The listed return signals compensate for the lack of an output schema.

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

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

The input schema has 100% description coverage, but the description adds significant value by clarifying parameter usage: npm package name, examples, and note about scoped packages needing '@' prefix. This goes beyond the schema's 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 tool's purpose: 'Get a behavioral commitment profile for any npm package.' It lists specific results (package age, download trend, etc.) and provides examples, making it distinct from sibling tools like lookup_github_repo or lookup_pypi_package.

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 use cases: 'vetting dependencies, due diligence, identifying abandonware, checking maintenance.' It does not directly mention when not to use it or alternatives, but the context of sibling tools and npm-specific focus provides implicit guidance.

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

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

With no annotations, the description carries full burden. It discloses the return signals and mentions behavioral signals reveal what star counts hide, indicating no destructive side effects. However, it does not mention rate limits or authentication 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?

The description is front-loaded with the main purpose. The LiteLLM anecdote adds context but slightly lengthens it. Every sentence is meaningful, though could be condensed without loss.

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 one simple parameter, no output schema, and no nested objects, the description sufficiently explains what the tool returns and its use cases. It is complete for 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?

Schema coverage is 100% for the single parameter 'package'. The description adds value by stating case-insensitivity, providing multiple examples, and explaining the parameter is a PyPI package name.

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 gets a behavioral commitment profile for PyPI packages, names specific signals (age, downloads, releases), and differentiates from siblings like lookup_npm_package by specifying the Python ecosystem.

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 lists use cases (vetting dependencies, abandonware, supply chain risk) and provides examples. It does not state when not to use this tool versus siblings, 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 the full burden of behavioral disclosure. It describes what the tool returns but does not cover critical behavioral aspects such as whether it's a read-only operation, potential rate limits, authentication requirements, error handling, or data freshness. The mention of 'verified' and 'harder to fake' hints at data reliability but lacks operational details.

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 and front-loaded, stating the core functionality in the first sentence and adding context in the second. Both sentences earn their place by explaining the tool's purpose and value proposition without redundancy. It could be slightly improved by integrating usage guidance, but it's efficiently 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's moderate complexity (single parameter, no output schema, no annotations), the description is partially complete. It explains what the tool does and its output signals but lacks details on behavioral traits, usage context, and output format. Without annotations or an output schema, more information on return values or operational constraints would enhance completeness.

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

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

The input schema has 100% description coverage for its single parameter ('domain'), so the schema already documents it fully. The description does not add any parameter-specific information beyond what's in the schema, such as examples or constraints, but it does not need to compensate for gaps. Baseline 3 is appropriate as the schema handles the parameter semantics adequately.

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 with a specific verb ('query'), resource ('verified behavioral commitment data for a domain'), and output details ('aggregated signals: unique verified visitors, repeat visit rate, and average time spent'). It distinguishes itself from sibling tools like audit_* or lookup_* tools by focusing on behavioral commitment data rather than audits or business/package 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 provides no guidance on when to use this tool versus alternatives. It mentions that the data 'proves real human engagement — harder to fake than reviews or content,' which implies a use case for verifying engagement, but does not specify scenarios, prerequisites, or exclusions compared to sibling tools like lookup_business or audit_dependencies.

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