Find owner-operated plumbers, HVAC techs, electricians and roofers in OK, KS, NE, IA and MO.
Scored across 3 tools
Each tool has a clearly distinct purpose: find_local_pros searches businesses, list_coverage reports geographic/listing coverage, and request_quote performs the lead-generation action. There is no overlap, and descriptions even cross-reference each other (e.g., list_coverage as a fallback when find_local_pros returns nothing).
All three tools follow a consistent snake_case verb_noun pattern: find_local_pros, list_coverage, request_quote. The verbs are precise and predictable, making the set easy to scan.
Three tools is lean but well-matched to a narrow directory-plus-lead-gen purpose: search, coverage lookup, and quote submission. It is slightly thin, but each tool clearly earns its place with no redundancy.
The surface covers the core lifecycle: discover coverage, search listings, and act by requesting a quote, with find_local_pros returning rich business details. Minor gaps exist (no way to retrieve a single business's full profile or track a submitted quote), but agents can work around these.
Use this when someone needs a local, owner-operated home-service business (plumber, HVAC, electrician, roofer, lawn care, tree service or fence) in Oklahoma, Kansas, Nebraska, Iowa or Missouri. Returns up to 5 businesses with name, phone, trade, service area, services and hours so the user can call or request a quote. Coverage is limited to the listed metros and nearby towns.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City and state, e.g. 'Tulsa, OK' or 'Omaha'. | |
| trade | No | Kind of work needed. Default any. | |
| problem | No | Optional: what's wrong, e.g. 'water heater leaking'. Used to rank by services. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds real value beyond them: it discloses the result shape ('up to 5 businesses with name, phone, trade, service area, services and hours') and the geographic coverage ceiling. It stops short of describing ranking behavior or what happens when no match is found.
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, front-loaded with the trigger condition, then the return shape, then the coverage caveat. Every sentence carries non-redundant information and there is no 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?
There is no output schema, and the description compensates by listing the returned fields and the cap of 5 results, plus the geographic limits. For a three-parameter lookup tool with full annotation coverage, an agent has everything needed to call 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%, so the baseline is 3. The prose enumerates trades in natural language ('plumber, HVAC, electrician, roofer, lawn care, tree service or fence'), which loosely maps caller vocabulary onto the enum values, but the 'problem' parameter is never addressed in the description and no added syntax is given for 'city'.
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 names a specific verb and resource ('find a local, owner-operated home-service business') and enumerates the trades and states it covers, so the agent knows exactly what is being looked up. It does not explicitly contrast itself with the sibling request_quote, so it falls just short of the top band.
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?
It gives a clear trigger condition ('Use this when someone needs a local, owner-operated home-service business ... in Oklahoma, Kansas, Nebraska, Iowa or Missouri') and warns that coverage is limited to listed metros and nearby towns. There is no explicit statement of when NOT to use it or a pointer to request_quote as the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this to check where Local Pros has listings before searching, or when find_local_pros finds nothing: returns every covered city with how many businesses are listed per trade. Coverage is limited to Oklahoma, Kansas, Nebraska, Iowa and Missouri.
| Name | Required | Description | Default |
|---|---|---|---|
| trade | No | Only count this trade. Default any. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, closed world), so the description's job is to add context beyond them — which it does by disclosing the geographic scope limit (OK, KS, NE, IA, MO). That constraint is behaviorally important and not present in any structured field. It stops short of noting result size or whether counts are live.
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 tight sentences: the first front-loads the when-to-use and the return shape, the second carries the scope caveat. Nothing is redundant or padded.
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 exists, so the description carries the return-value burden and does so adequately by naming cities and per-trade counts. With annotations covering safety and the schema covering the single parameter, nothing an agent needs 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% and the enum is self-documenting, so the baseline is 3. The description adds value by explaining that the trade filter scopes the business counts returned ('how many businesses are listed per trade'), clarifying the semantics of an optional filter rather than merely restating it.
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?
States a specific verb and resource ('check where Local Pros has listings') and precisely describes the return payload: every covered city with business counts per trade. An agent can distinguish it from find_local_pros and request_quote without opening any schema.
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 names two triggering conditions — before searching, or when find_local_pros returns nothing — and routes the agent by naming the sibling tool it complements. No inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a quote request to one of the businesses returned by find_local_pros. The business gets an email with the customer's name, contact and problem and replies directly. Ask the user for permission before calling this: it shares their name and contact with the business.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The business slug from find_local_pros. | |
| contact | Yes | The customer's phone number or email for the business to reply to. | |
| problem | Yes | What needs doing, where (city/neighborhood) and when. | |
| customer_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, openWorldHint=true, so the external side-effect profile is known. The description goes further by explaining the mechanism (email to business) and the privacy consequence (shares the user's name and contact), justifying the destructive flag and the consent requirement. It stops short of describing what the caller gets back, keeping it at 4.
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 tight sentences: purpose/mechanism first, deliverable second, consent requirement last. 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?
With no output schema, the description clarifies the response path (the business replies directly by email), which is the key thing an agent needs. The only minor gap is not stating what the tool itself returns synchronously.
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 75%, with customer_name undocumented in the schema; the description compensates by naming 'the customer's name, contact and problem' as the payload. It doesn't add format or syntax detail beyond the schema for slug/contact/problem, so it is above baseline but not rich.
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?
States a specific verb (send) and resource (quote request), and explicitly scopes it to 'one of the businesses returned by find_local_pros', tying it to the only sibling tool. An agent immediately knows what this does and where the required slug comes from.
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?
Gives an explicit sequencing rule ('businesses returned by find_local_pros') and a hard precondition ('Ask the user for permission before calling this'). These are actionable when-to-use constraints, not implied guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
list_coveragefind_local_pros1 field changedInput schema / properties / trade / enumPrevious value: -[
- "plumbing",
- "hvac",
- "electrical",
- "roofing",
- "any"
-]New value: +[
+ "plumbing",
+ "hvac",
+ "electrical",
+ "roofing",
+ "lawn",
+ "tree",
+ "fence",
+ "any"
+]find_local_prosrequest_quoteLocal tradespeople: 823,000+ US businesses in 38 trades. Verified first; no paid placement.
Search 7,000+ local service businesses across America by category, location, or keyword.
Find one verified local pro for anyone: plumbers, roofers, cleaners, 110+ services. Free.
Get quotes from local shops for a home repair or project anywhere in the US. Free for homeowners.
Add one secure layer between your agents and this server.
