US national planning cost range for a pest control service (editorial range, not a quote or measured average), with the factors that move the price. Always advise getting a written local quote.
| Name | Required | Description | Default |
|---|---|---|---|
| pest | Yes | Pest or service, e.g. termite control, bed bugs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the readOnlyHint: it explicitly calls out that the result is an editorial range rather than a quote or measured average, mentions that factors affecting price are included, and directs the agent to recommend a local written quote. This meaningfully clarifies what the tool does and does not guarantee.
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 tightly written sentences front-load the core purpose, clarify what the output is not, and include an actionable user-facing instruction. 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 one-parameter, read-only tool with no output schema, the description explains what is returned (a national planning range), what it is not (a quote or measured average), what response includes (price factors), and what advice the agent should always give. This is sufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the only parameter, pest, with an example provided in the schema. The description itself doesn't add much parameter-level meaning beyond referencing factors that move price, so the baseline schema coverage adequately handles parameter semantics.
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 a US national planning cost range for a pest control service, with the specific resource being cost and the action being retrieval. It doesn't explicitly compare itself to siblings, but the subject matter (cost range vs. finding/verifying pros) makes it easy to differentiate.
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 planning range, not a quote or measured average, and instructs the agent to always advise getting a written local quote. It does not explicitly state when to prefer this over siblings, but the use case is clear enough from the editorial versus local-quote distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: discovering companies by city/pest, getting a cost range, and verifying a specific company's license. Even though find_licensed_pros and verify_license both involve license records, their inputs and outputs are sufficiently different to avoid confusion.
All tool names follow a consistent snake_case verb_noun pattern: find_licensed_pros, get_pest_cost, verify_license. The verbs vary by action, but the structure and style are uniform and predictable.
Three tools is a well-scoped set for the server's narrow consumer-focused purpose: find providers, estimate cost, and verify licenses. Each tool earns its place with no redundant or filler tools.
For the stated domain of helping homeowners research pest control services, the surface covers the core workflow: finding licensed companies, understanding typical costs, and verifying a specific license. There are no obvious dead ends or missing critical operations for this scope.
