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 carries the transparency burden. It discloses the output (risk table sorted by commitment score) and lists specific risk flags with explanations. It does not mention any destructive side effects, which is appropriate 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?

The description is well-structured with a clear opening, bullet-pointed risk flags, and practical examples. It is slightly long but each section adds value, making it appropriately sized 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 lack of an output schema and the tool's multi-ecosystem nature, the description is remarkably complete. It explains the risk categories, ecosystem-specific details (especially Go), and provides concrete use cases, covering all essential information an agent would need.

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

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

The input schema already describes both parameters fully (100% coverage). The description adds value by explaining the risk flags, providing examples for each ecosystem, and clarifying Go module path requirements.

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

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

The description clearly states that the tool batch-scores packages for supply chain risk across four ecosystems (npm, PyPI, Cargo, Go). It distinguishes from siblings like audit_dependency_tree and audit_github_repo by focusing on a list of package names and returning a risk table.

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

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

The description provides explicit usage context: it's ideal for auditing full dependency files like package.json or requirements.txt and includes examples. However, it does not explicitly say when not to use it or directly compare to 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?

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, the description carries the full burden. It discloses the key's benefits (rate limit lift, package monitoring), how to configure it, and limitations (one per email, 3 per IP per day). It does not explain behavior if called with the same email again, but overall is 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 structured with a clear lead sentence, then usage details, an example, and limitations. Every sentence adds value, though it could be slightly more compact without losing clarity.

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

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

Given the tool's simplicity, the description covers purpose, usage motivation, example call, post-creation configuration, and limitations. No output schema is provided, but the return value is described. Edge cases like duplicate emails are not addressed, but overall it's fairly complete.

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

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

Schema coverage is 100% with a detailed description. The tool description adds context on why the email is needed (alert delivery, key recovery) and the one-key-per-email rule, which enhances 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 the tool creates a free Commit API key. It specifies the verb 'create' and resource 'API key', and distinguishes from sibling tools (audit/lookup) which don't involve key creation.

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 when to use the tool: when hitting the daily free query limit or wanting faster access. It also sets expectations like one key per email and 3 keys per IP per day. It does not explicitly mention when not to use, 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?

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?

With no annotations provided, the description fully discloses behavioral traits: it returns a behavioral commitment profile, explains signals like publisherLifecycle and the Mastra incident, and the rationale behind behavioral signals. No contradictions or omissions.

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 a front-loaded purpose, list of returned signals, contextual explanation, use cases, and examples. It includes a slightly verbose anecdote about the Mastra incident but remains focused and adds credibility.

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 adequately explains return values (package age, download trends, publisher lifecycle, etc.). It covers the tool's functionality for its intended use cases, though it could note any limitations like rate limits or error handling.

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 one parameter with 100% coverage in description. The description adds value by emphasizing the '@' prefix for scoped packages and providing examples, though the schema already includes examples. It adds non-trivial nuance 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's purpose: 'Get a behavioral commitment profile for any npm package.' It lists specific signals returned, distinguishing it from sibling tools like audit_dependencies or lookup_github_repo by focusing on npm-specific behavioral metrics.

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

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

The description provides explicit use cases: vetting dependencies, due diligence, identifying abandonware, checking maintenance. It explains why behavioral signals matter, but does not explicitly mention when not to use or compare to alternatives among 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?

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.