House cleaning prices, cleaning sales tax by state and leaf blower rules for US service businesses
Scored across 4 tools
Each tool targets a completely separate task: state sales-tax applicability, residential cleaning price estimation, free-tool discovery, and gas leaf blower regulations. There is no meaningful overlap between any pair, so an agent can select confidently.
All names use snake_case, which is readable and consistent in casing. However the structural convention is mixed: 'estimate_house_cleaning_price' and 'find_free_tool' are verb-led, while 'cleaning_sales_tax_by_state' and 'gas_leaf_blower_rules' are noun-led, so there is no single predictable pattern.
Four tools is on the lean side but each one is a distinct, non-trivial capability rather than filler. It sits just under the well-scoped range, and a 'free tools' hub that mostly points elsewhere (find_free_tool) could reasonably host more.
The surface covers the core reference needs hinted at (tax rules, pricing, regulations, tool discovery) with sourced outputs. Minor gaps exist — pricing covers only residential house cleaning despite commercial cleaning being a stated domain, and contract/invoice generation is only pointed to rather than provided.
Says whether state sales tax (or the state's equivalent) applies to home (residential) and commercial cleaning services in one US state or DC, from EosLog's state by state reference. Each answer is what that state's own official pages say, with the official source links, the state base rate where the source states one, and the date it was checked. It is not tax advice and does not cover local taxes.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter code (TX) or full name (Texas). DC is included. | |
| audience | No | home for residential cleaning, commercial for offices and other businesses, or both. | both |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive/closed-world, so the bar is lower. The description usefully adds what the answer contains (official source links, state base rate when stated, date checked) and two explicit boundaries: not tax advice and no local tax coverage. It stops short of noting coverage limits or how ambiguous state guidance is handled.
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 core verdict, then answer contents, then the disclaimer. Every sentence carries information, though the middle sentence is dense enough that it could be trimmed slightly.
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 enumerating what the response includes (verdict, source links, base rate, check date). Combined with the explicit boundaries and the fully-covered input schema, an agent has everything needed to call and interpret this 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 both parameters are already fully documented in the schema (including the DC allowance and the enum meanings). The description restates the state-level scope and audience categories without adding syntax or format detail beyond the schema, so 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?
States a specific verb+resource+scope: whether state sales tax applies to residential/commercial cleaning in one US state or DC. The scope limit ('one US state or DC') is explicit, and it correctly frames itself as a state-level reference lookup, which no sibling tool overlaps.
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 through scoping (one state per query, home/commercial/both audience) but never states when to reach for this versus alternatives, nor any prerequisites or exclusions beyond 'does not cover local taxes'. Usage is inferable, not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prices one residential house cleaning visit with the math behind EosLog's free cleaning price calculator: time on site from the home's size and square footage, times a frequency factor and the cleaner's hourly rate, plus supplies, drive and add-ons, adjusted for the local market and rounded to $5. Returns the price, a low to high range, hours on site, a per square foot cross-check, the math, and a link that opens the calculator with these inputs so the user can adjust them. Every input is optional and has the calculator's default.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Bedrooms and bathrooms, for example 3br2ba for 3 bedrooms and 2 bathrooms. | 2br1ba |
| sqft | No | Square footage. Defaults to the typical size for the layout (1,600 for 3br2ba). | |
| addons | No | Extras that apply: pets (+$15), kids under 10 (+$20), oven inside (+$35), fridge inside (+$30), trash takeout (+$10), laundry, one load washed and folded (+$20). | |
| market | No | rural (0.80x), standard for most US metros (1.00x), or coastal for a high-cost coastal metro (1.30x). | standard |
| frequency | No | How often the home is cleaned. deep is a first or one-time deep clean; moveout is a one-time move-out clean. | biweekly |
| hourly_rate | No | What the cleaner bills per cleaner-hour, in US dollars. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare this as a safe, read-only, idempotent, closed-world operation. Beyond that, the description explains the calculation model, the $5 rounding, the default behavior for every optional input, and the exact return contents including price range, hours, per-square-foot cross-check, math, and an adjustability link.
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 core purpose, then covers return values and defaults in three dense but purposeful sentences. The first sentence is long and complex, but no sentence feels wasted.
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 properly explains what the tool returns. It also covers default behavior, calculation logic, and optional inputs, making it complete for a read-only estimation tool of this 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 each parameter's enums, defaults, ranges, and add-on prices. The description adds value by describing how parameters interact in the calculation: size and square footage determine time on site, which is multiplied by frequency and hourly rate, then adjusted for market and add-ons.
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 states a specific verb and resource: it prices one residential house cleaning visit using a defined calculation. It is immediately distinguishable from the unrelated sibling tools, which cover sales tax, free tool lookup, and gas leaf blower rules.
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 by saying it prices one residential house cleaning visit, but it does not explicitly state when to use it or when not to use it, such as for commercial cleanings or multi-visit planning. No alternatives exist among the siblings, so the implied context is adequate but not fully expressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds the free EosLog tool for a service business task: a quote or invoice generator (with a page for the trade where one exists), a price calculator for house, move-out, deep, commercial or Airbnb cleaning, pressure washing or landscaping (with the URL params that prefill it), or contract and form templates, filtered by trade when given. Returns titles and https://eoslog.com URLs. Every tool is free and needs no account.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | What the user is trying to do. | |
| trade | No | Optional trade, used to pick trade pages and templates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety and determinism are covered by structured data. The description adds genuinely new behavioral context beyond that: the result set is limited to https://eoslog.com titles/URLs, every tool returned is free, and no account is required — useful for deciding whether a returned tool is actionable.
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 verb and resource lead the first sentence, and the second sentence front-loads the return format and the free/no-account constraint. The single long enumeration sentence is dense but each clause maps to a distinct capability, so little is wasted; it could have been split for readability.
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, so the description carries the burden of describing returns, and it does: titles plus https://eoslog.com URLs. Combined with the task enumeration, optional trade filtering, and the free/no-account guarantee, an agent has everything needed to call this correctly and interpret the result.
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 both parameters enum-constrained and described, so the baseline is 3. The description goes further by expanding the enum values into concrete semantics, e.g. that price calculators cover house, move-out, deep, commercial or Airbnb cleaning, pressure washing or landscaping, and that they come with URL params that prefill them — detail the schema's enum labels alone do not convey.
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 (finds) and resource (free EosLog tool) and enumerates the exact categories of artifacts it can return: quote/invoice generators, cleaning/pressure-washing/landscaping price calculators, and contract/form templates. This distinguishes it clearly from the sibling tools, which are single-purpose calculators like estimate_house_cleaning_price or cleaning_sales_tax_by_state.
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?
Usage is implied rather than stated: an agent can infer this is the entry point for locating a free tool matching a user's task, and the phrase 'filtered by trade when given' tells it the trade parameter is optional. However, there is no explicit when-to-use/when-not-to-use guidance and no named alternative (e.g., whether to call this before or instead of a specific sibling calculator).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists adopted local laws that ban or restrict gas leaf blowers in one US state, or one city or town in it, from EosLog's sourced table: the rule, when it took or takes effect and any later phases, who is cited, the penalty, and the official sources with the date each row was checked. Also reports a state law that blocks local bans (Florida, Georgia, and Texas). Without a city it lists every place in the state briefly; pass city for the full row. A place with no row may still have a rule EosLog has not confirmed.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional city, town, village or county name, for example Los Angeles. | |
| state | Yes | Two-letter code (CA) or full name (California). DC is included. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnly/idempotent/no-destructive annotations already covering safety, the description goes further and discloses the actual payload: the rule, effective date plus later phases, who is cited, the penalty, and official sources with the date each row was checked. It also warns that 'a place with no row may still have a rule EosLog has not confirmed,' which is essential honesty about data completeness. There is no output schema, so this return-content detail is doing real work.
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?
Dense but front-loaded — the core purpose leads, followed by what gets returned and the city/state behavior. Sentences carry real information rather than filler, though the second half is packed enough that the state-preemption and caveat points could be slightly more clearly separated.
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 a two-parameter read-only lookup with no output schema, the description covers purpose, returned fields, state vs city behavior, preemption reporting, and a data-gap caveat. Nothing an agent needs to call this correctly or interpret the result 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 baseline is 3, but the description adds behavioral meaning beyond the schema: state-only calls return a brief listing of all places, while adding city returns the full row. That distinction changes how an agent should call the tool and is not derivable from the parameter definitions alone.
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+resource: 'Lists adopted local laws that ban or restrict gas leaf blowers in one US state, or one city or town in it.' It also identifies the data source (EosLog's sourced table) and the scope boundary, so an agent knows exactly what this returns. The sibling tools are unrelated, so no differentiation is needed.
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?
Clear usage context: without a city the tool lists every place in the state briefly, and passing city yields the full row. It also flags the state-preemption case (Florida, Georgia, Texas) that an agent should expect. No explicit when-not-to-use or named alternative exists, but there is no competing sibling to route to.
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.
cleaning_sales_tax_by_stateestimate_house_cleaning_pricefind_free_toolgas_leaf_blower_rulesQuote, hold and book US house cleaning jobs on a customer's behalf, at each business's own prices.
US data for home-service trades: service-area ZIPs, seasonal demand, review timing, service pages.
Local US home-service pricing, providers ranked by the Vouched Score, rebates, and glossary.
Free US cleaning cost, time, crew, and chemical-use calculators with visual reports.
Add one secure layer between your agents and this server.
