PestPin

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

With no annotations, the description carries the full burden and does an excellent job disclosing behavior: it returns up to 8 companies with license numbers and published phone numbers, includes a link to a full list, and clarifies that the free request feature goes to a single company at a time and is never resold. It also warns that listings are matched public records, not recommendations, and most businesses have not confirmed services. This provides significant transparency about data provenance and limitations.

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 sentences, each adding value: first states the core function, second describes the output and the free request link, third clarifies data quality. No fluff or redundancy, and key information is front-loaded.

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

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

The description explains the return structure (up to 8 companies with license numbers and phone numbers) and the link to the full list, which is critical given no output schema exists. It also clarifies the nature of the data. However, it does not detail the exact response format (e.g., JSON object shape) or potential error behavior, leaving some gaps.

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

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

The schema already provides 100% coverage of all parameters, including descriptions for city, pest, and state. The tool description mentions 'city and pest type' but adds no additional semantic meaning beyond what the schema provides. Per the baseline for high schema coverage, a 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 verb 'List' and the resource 'license-record pest control companies for a US city and pest type', which precisely identifies the tool's function. It distinguishes itself from sibling tools (get_pest_cost for cost estimates, verify_license for license verification) by focusing on listing licensed companies.

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

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

The description provides clear context on when to use the tool (to find licensed pest control companies for a city and pest type) but does not explicitly state exclusions or alternatives. Since the sibling tool names suggest different purposes, the usage context is clear, but explicit when-not/alternatives guidance is missing.

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

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: the result is an editorial range, not a quote or measured average, and it includes factors that move the price. It also instructs the agent to advise getting a local quote, which is important behavior for setting expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, each earning its place. The first front-loads the core purpose and key caveat; the second provides a clear actionable instruction. No fluff or redundancy.

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

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

For a simple single-parameter tool with no output schema, the description is complete. It states what the tool returns (cost range, price factors), clarifies the nature of the data (editorial, not a quote), and gives an important action for the agent (advise local quote). Nothing essential is missing.

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

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

Schema coverage is 100% because the sole 'pest' parameter has a description with examples ('e.g. termite control, bed bugs'). The main description adds no parameter-specific details beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description clearly states it provides a 'US national planning cost range for a pest control service', which is a specific verb+resource combination. It distinguishes itself from siblings (find_licensed_pros, verify_license) by focusing on cost rather than professional lookup or license verification.

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

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

The description gives clear context that this is an editorial range, not a real quote, and instructs the agent to always advise getting a written local quote. While it doesn't explicitly contrast with sibling tools, the purpose is distinct enough that usage intent 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?

Without annotations, the description discloses the data source's coverage (30 states), recurrence and timing variance, the fact that results reflect PestPin's last check, and the caveat that a miss does not prove unlicensed status. It also mentions exclusions for lawn/ag/government records and spelling variations, which sets accurate expectations about matching 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 four sentences, front-loaded with the primary action, followed by return details and limitations. Each sentence provides necessary context 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?

Despite lacking an output schema and annotations, the description explains exactly what will be returned (license number, state, status, official source link), the data's provenance and freshness, and limitations. This is sufficient for an agent to select the tool and interpret results.

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

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

The input schema describes both parameters thoroughly (state as optional narrowing code, company as name or license number), so the description adds little about parameter syntax. It does note that name spellings vary, which is a useful matching hint, but this is minor incremental value.

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 ('Look up') and resource ('a US pest control company in PestPin's state license-record directory'), and specifies the output includes license number, state, status, and official source link. This distinguishes it from siblings like find_licensed_pros (which presumably discovers pros) and get_pest_cost (cost lookup).

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 this tool is for verifying a specific company's license but does not explicitly discuss when to use it instead of sibling tools. It does provide important interpretive guidance about coverage limitations, but no direct alternatives or exclusions.

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