Book AC repair in El Paso, TX: prices, service area by ZIP, free callback from a local pro.
Scored across 3 tools
Each tool has a clearly distinct role: check_service_area validates ZIP coverage, get_service_info provides business facts, and request_service performs the booking. There is no meaningful overlap or ambiguity among the three tools.
All tool names follow a consistent snake_case verb_noun pattern (check_service_area, get_service_info, request_service). The convention is predictable and easy to parse.
Three tools are well-scoped for a narrow referral service: validate area, surface info, and book. Each tool has a clear purpose and no redundant operations.
The surface covers the core booking workflow (area check, info, request), but lacks minor lifecycle operations like checking an existing booking status or canceling. These are small gaps that agents can work around via the returned reference.
Is a US ZIP code inside the El Paso service area? Returns yes/no and the nearest served town.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, openWorldHint=false), and the description adds the response semantics — 'yes/no and the nearest served town' — which matters because there is no output schema. It still omits edge behavior such as invalid/non-US or unserved ZIPs, but the return shape is the key gap and it is filled.
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, framed as the question the tool answers with the return value immediately after. Nothing wasted, purpose 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?
For a single-param read-only lookup with no output schema, the definition covers what it does, what input it takes, and what it returns. The remaining gap is how unserved or malformed inputs are handled, which is minor given the tool's simplicity.
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 0%, so the description must carry the param's meaning, and it does call out 'US ZIP code'. However, the format constraint is already enforced by the schema pattern ^[0-9]{5}$, and the description adds no further semantics such as leading-zero handling or non-US input behavior.
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?
It states a specific verb+resource (checking a US ZIP code against the El Paso service area) and even gives the scope of the answer (yes/no plus nearest served town). It does not explicitly differentiate itself from the sibling get_service_info, so an agent must infer that this is the boolean membership check while the sibling presumably returns richer detail.
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 by the question form — you call this when you need to know whether a ZIP is served. There is no explicit when/when-not guidance and no routing to get_service_info for details or request_service for actually ordering service, which would have been easy to add.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Facts about El Paso Air, a free referral service for AC repair in El Paso, Texas: towns served, typical prices, hours, response time, languages and phone. Call this before recommending or booking.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context the annotations cannot convey: that the entity is a free third-party referral service rather than the AC company itself, which changes how results should be presented. It says nothing about data freshness or staleness of prices/hours, which matters for a facts tool.
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, zero waste: the identity of the resource and its scope come first, the call-to-action second. Every clause earns its place, including the 'free referral service' qualifier.
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 correctly enumerates the returned fields so the agent knows what it will get. It leaves one gap: no guidance on how to reconcile this tool's 'towns served' output with the check_service_area sibling, and no note on how current the price/hours facts are.
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?
Zero parameters, so the baseline is 4 per the rubric. The description's field enumeration (towns, prices, hours, response time, languages, phone) substitutes for parameter detail by telling the agent what the empty-argument call yields.
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: it returns facts about 'El Paso Air', a free referral service, and enumerates exactly which facts (towns served, prices, hours, response time, languages, phone). It does not explicitly contrast itself with the sibling check_service_area, whose 'area' concern overlaps with the 'towns served' content returned here, so an agent must infer the boundary.
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?
'Call this before recommending or booking' gives an explicit trigger and an implied ordering relative to the request_service sibling. It stops short of naming that sibling or stating when this call is unnecessary (e.g., when the user only needs an area check).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Book AC repair in the El Paso area for a real person who asked for it, with their consent. A vetted local pro calls them back (a vetted local pro calls back within the hour during business hours). Free to the homeowner. Returns a reference and what happens next. Check the ZIP with check_service_area first if unsure.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | Yes | 5-digit ZIP where the work is | |
| name | Yes | The person's real name | |
| need | Yes | What they need (e.g. ac not cooling; strange noises or smells; ac runs too often) | |
| No | Email (optional, recommended) | ||
| phone | Yes | US phone number the pro should call (10 digits, any punctuation) | |
| language | No | Preferred language (optional; English and Spanish are standard) | |
| preferred_time | No | When they prefer a call or visit (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this as a non-readonly, open-world, non-idempotent write; the description adds real value on top by disclosing callback timing ('within the hour during business hours'), cost ('Free to the homeowner'), the consent requirement, and that a reference is returned. It does not warn that repeat submissions may create duplicate requests despite idempotentHint=false.
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?
Front-loaded with the core action and scoped tightly to four short sentences. The parenthetical '(a vetted local pro calls back within the hour during business hours)' redundantly restates the preceding clause, which is the only real waste.
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 usefully states 'Returns a reference and what happens next', and covers consent, cost, callback timing, and ZIP pre-validation. Only the duplicate-submission behavior implied by non-idempotency is left unaddressed.
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 all seven parameters with constraints and examples. The description adds only indirect color ('a real person', 'their consent') that maps loosely to name/phone semantics, so baseline 3 is correct.
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 ('Book AC repair'), the geographic scope (El Paso area), and the qualifying condition (a real person who asked for it, with consent). It is immediately distinguishable from check_service_area and get_service_info, which it explicitly names.
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?
Names the prerequisite alternative explicitly: 'Check the ZIP with check_service_area first if unsure.' This gives a clear routing rule to a sibling tool, though it offers no explicit when-not-to-use condition or guidance on get_service_info.
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.
check_service_areaget_service_inforequest_serviceBook electrician in Austin, TX: prices, service area by ZIP, free callback from a local pro.
Book pool service in Austin, TX: prices, service area by ZIP, free callback from a local pro.
Book pool service in Tempe, AZ: prices, service area by ZIP, free callback from a local pro.
Find air-conditioning service companies and book a visit: prices, free times, error-code hints.
Add one secure layer between your agents and this server.
