US data for home-service trades: service-area ZIPs, seasonal demand, review timing, service pages.
Scored across 5 tools
Each tool targets a distinct resource or operation: listing trades, planning review requests, analyzing seasonal demand, calculating service areas, and generating website page sets. There is no overlap in purpose, and the descriptions clearly differentiate them.
Four tools follow a consistent noun-based pattern (list_trades, seasonal_demand, service_area, trade_service_pages), but review_request_timing uses a verb-noun structure, which is a minor deviation. Overall, the naming is predictable and readable.
With 5 tools, the set is well-scoped for a local trades kit, covering key informational and planning needs without redundancy. Each tool earns its place, and the count falls within the ideal 3-15 range.
The tools cover reference data, review timing, seasonal demand, service area mapping, and service pages, but there are notable gaps: no tools for pricing, lead generation, scheduling, or customer management, which are common in a trades toolkit. The surface is useful but incomplete for a full business lifecycle.
List every trade the kit covers with its id, common names it matches, its 2022 NAICS industry code and its job type ids. Static reference.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds the meaningful extra disclosure that the dataset is static and enumerates what comes back, which is valuable given there is no output schema.
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 short sentences, zero filler, with the action and resource front-loaded followed by the field inventory. Every clause earns its place.
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 zero-parameter, read-only static lookup with no output schema, the description supplies the return-field inventory and the static nature of the data, which is everything an agent needs to call and interpret it.
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 tool takes zero parameters, so the baseline is 4 and there is nothing the description needs to disambiguate. The field enumeration in the description describes the return payload rather than inputs, which is appropriate here.
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 (List) and resource (trades) and enumerates the returned fields (id, common names, 2022 NAICS code, job type ids). The 'Static reference' framing implicitly separates it from the analysis-oriented siblings (seasonal_demand, service_area), though no sibling is named explicitly.
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?
'Static reference' implies this is a lookup used to resolve trade ids/codes rather than an analytical tool, which gives usable context. However, it never says when to call this versus the other trade-related tools, nor any prerequisites, leaving usage to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plan when and how a home-service business asks customers for reviews, by trade and job type: what to say at completion, the window for the one written request (with dates when a completion date is given), the moment the customer can first judge the work, and the rules that apply, from Google Maps policy, Yelp, the FTC consumer review rule (16 CFR 465) and the TCPA for texts, each cited with an as-of date. Includes the field-experiment and survey findings the timing rests on. Informational, not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| trade | Yes | The trade: an id from list_trades (plumbing, hvac, electrical, roofing, landscaping, lawn_care, tree_service, pest_control and more) or a common name such as "plumber" or "AC repair". | |
| job_type | No | One job type id from list_trades, such as water_heater, replacement or mowing, or a job class (repair, install, project, recurring, emergency, inspection). Leave out to get every job type for the trade. | |
| completed_on | No | The date the job was finished, YYYY-MM-DD, to get the request window as dates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the rules are cited with an as-of date, the answer includes the underlying experiment/survey findings, and it carries an explicit 'informational, not legal advice' disclaimer.
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?
One dense but well-organized sentence with the purpose front-loaded and the substantive contents enumerated afterward. It is longer than average, but each clause (window, judgment moment, cited legal sources, evidence base) carries distinct information; only the stacked citations make it slightly run-on.
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 read-only informational tool with no output schema, the description covers the content contract well — what categories of answer to expect, the citation convention, and the scope limitation. It could still say more about answer shape or size, and it omits usage routing, keeping it just short of 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 description coverage is 100%, so the baseline is 3, but the description adds real semantics: job_type may be omitted (obtainable to get every job type for the trade) and completed_on changes the output shape from a relative window to concrete dates — details that go beyond the schema's field-level wording.
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 (plan review-request timing) scoped by trade and job type, and enumerates exactly what the answer contains: what to say at completion, the written-request window, the moment of first judgment, and applicable rules. It is clearly distinct from the sibling tools (list_trades, seasonal_demand, service_area, trade_service_pages).
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?
Its implicit usage is inferable from the framing, and it explains a conditional behavior (dates returned when completed_on is given), but it never says when to reach for this tool versus list_trades or the other siblings, nor does it state any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the busy and slow months for a home-service trade in a US state, a NOAA climate region (Northeast, Upper Midwest, Ohio Valley, Southeast, Northern Rockies and Plains, South, Southwest, Northwest, West) or the whole country. The month-by-month index is measured from BLS QCEW private-sector employment for the trade's NAICS industry, 2022 to 2024. Beside it: NOAA 1991-2020 monthly temperature, degree day and precipitation normals for the same area, and seasonal drivers for the trade (tune-up seasons, freeze months, hurricane season, lawn fertilization windows, termite swarms and others) where a public source supports them. Every claim carries its source.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | A US state: two-letter code (MT) or full name (Montana). | |
| trade | Yes | The trade: an id from list_trades (plumbing, hvac, electrical, roofing, landscaping, lawn_care, tree_service, pest_control and more) or a common name such as "plumber" or "AC repair". | |
| region | No | Instead of a state, a NOAA climate region: Northeast, Upper Midwest, Ohio Valley, Southeast, Northern Rockies and Plains, South, Southwest, Northwest, West. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description goes further and earns credit by disclosing provenance and content: the index derives from BLS QCEW private-sector employment 2022-2024, normals are NOAA 1991-2020, and it flags partial coverage of seasonal drivers ('where a public source supports them') plus per-claim sourcing.
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 dense sentences that front-load the capability and then the data provenance; the awkward 'Beside it:' transition costs a little but nothing is wasted or repetitive.
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 must convey return content, and it does: a month-by-month employment index, NOAA temperature/degree-day/precipitation normals, and seasonal drivers, each with sources. Only the response shape/ordering remains unspecified, which is a minor gap for this 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 description coverage is 100%, so the schema already documents state format, the list_trades id source for trade, and the region names. The description restates the region list and broadens the trade examples, which adds little beyond the schema; baseline 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 gives a specific verb+resource ('Show the busy and slow months') and pins down the exact scope: a home-service trade within a US state, a named NOAA climate region, or the whole country. That scope is distinct from the sibling tools (list_trades, service_area, review_request_timing), so an agent can route correctly without opening the 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?
It implicitly tells the agent the tool serves geography-scoped seasonality questions by enumerating the three geography options, but it never states when to prefer this over siblings, nor that list_trades should be called first to resolve a trade id (that hint lives only in the schema). Usage is implied rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Work out what a local service business covers. Give a base (a 5-digit ZIP or "City, ST") and a radius in miles, or a list of ZIPs. Returns every ZIP Code Tabulation Area inside it with distance, population, housing units and owner-occupied homes; the cities, towns and Census places inside it; the counties it touches with the population inside the area; totals; and up to 20 candidate areas for a Google Business Profile service area with Google's written rules. Uses Census Gazetteer, relationship-file and ACS 2020-2024 data stored on the server. Distances are straight-line miles, not driving distance.
| Name | Required | Description | Default |
|---|---|---|---|
| base | No | Where the business is based: a 5-digit ZIP such as 59901, or a city with its state such as "Kalispell, MT". Use with radius_miles. | |
| zips | No | Instead of a base and radius: the ZIPs the business serves. | |
| max_zips | No | How many ZIPs to list (default and maximum 250). Totals always count every ZIP. | |
| radius_miles | No | Straight-line radius in miles, 1 to 100. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-derivable context: the underlying Census Gazetteer/relationship-file/ACS 2020-2024 data, straight-line rather than driving distance, and the cap of 20 candidate areas. Only the 250-default listing behavior is left to the schema.
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 purpose, then inputs, then outputs and caveats. Dense but every clause carries information (data sources, distance semantics, candidate-area cap); no filler or repetition of the title.
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, yet the description fully specifies the return contents — ZCTA-level fields, places, counties with in-area population, totals, and GBP candidates — plus the straight-line distance caveat. For a 4-param read-only analytic tool, an agent has everything needed to call and interpret it.
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 every parameter (base, zips, max_zips, radius_miles) is already documented with formats, ranges and defaults. The description restates the ZIP/'City, ST' format and the base-vs-zips choice but adds no syntax or edge-case detail beyond the schema, which is the correct baseline for full 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 opens with a specific verb+resource ('Work out what a local service business covers') and then enumerates exactly what is computed: ZCTAs with distance/population/housing, places, counties, totals, and up to 20 GBP candidate areas. An agent can tell precisely what this tool produces, and the sibling tools (trades, demand, review timing) share no overlap.
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 clearly states the two accepted input modes ('Give a base ... and a radius in miles, or a list of ZIPs'), which tells the agent how to invoke it, and the schema reinforces that base pairs with radius_miles. It does not state when to prefer one mode or when not to use this tool, but the sibling set offers no competing alternative, so the gap is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the standard website page set for a home-service trade: home, services hub, one page per core service with what it must cover, projects, service area, reviews, about, questions and contact, plus location pages for up to 20 cities. Comes with Google's written rules on doorway pages, people-first content, LocalBusiness structured data and business names, each cited. The service taxonomy is curated per trade and mapped to the trade's 2022 NAICS industry.
| Name | Required | Description | Default |
|---|---|---|---|
| trade | Yes | The trade: an id from list_trades (plumbing, hvac, electrical, roofing, landscaping, lawn_care, tree_service, pest_control and more) or a common name such as "plumber" or "AC repair". | |
| cities | No | Towns the business really serves, for location pages, such as ["Whitefish, MT", "Columbia Falls, MT"]. | |
| emergency_service | No | Whether the business takes emergency or after-hours calls. Defaults to what is typical for the trade. | |
| maintenance_plans | No | Whether the business sells recurring service or maintenance plans. Defaults to what is typical for the trade. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real value by disclosing what the payload contains: a full page set, Google's cited rules on doorway pages/people-first content/structured data, and a taxonomy mapped to the trade's 2022 NAICS industry.
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 sentences, front-loaded with the core deliverable before the supporting detail. The first sentence is dense with an enumeration but every item is informative, and there is no filler or repetition.
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 carries the burden of describing the return value and does so thoroughly, listing page types and the accompanying cited rules. It is only mildly incomplete in omitting any note about determinism/variation across trades, but nothing essential to calling the tool 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%, so the schema already documents all four parameters, making 3 the baseline. The description adds only marginal meaning, echoing the 'up to 20 cities' cap that corresponds to the cities array's maxItems limit and noting the taxonomy is curated per trade, without adding syntax or format detail 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 opens with a concrete verb+resource ('List the standard website page set for a home-service trade') and then enumerates the exact page types returned, so an agent knows precisely what it produces. It never names or contrasts a sibling tool, so it falls short of the 5 criteria despite the high specificity.
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?
There is no statement of when to call this versus list_trades, service_area, or seasonal_demand, and no prerequisites are given in the description (the need for a trade id from list_trades appears only in the schema). The agent can infer the scenario from the content, but no explicit guidance or exclusions are offered.
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_tradesreview_request_timingseasonal_demandservice_areatrade_service_pagesVerified US local service providers across 10 home-services trades. Owned data, no API key.
Local US home-service pricing, providers ranked by the Vouched Score, rebates, and glossary.
Count and buy mailing lists of homes that fit a home-service trade, by measured property signals.
US local businesses, services and source-cited prices, city by city. Free, no API key.
Add one secure layer between your agents and this server.
