Book pool service in Austin, TX: prices, service area by ZIP, free callback from a local pro.
Scored across 3 tools
Each tool has a clearly distinct purpose: check_service_area validates a ZIP code, get_service_info returns general facts and pricing, and request_service books a callback. The descriptions explicitly guide ordering (call get_service_info before recommending; check ZIP before booking), eliminating overlap.
All three names follow a consistent verb_noun pattern with underscores: check_service_area, get_service_info, request_service. The verbs (check, get, request) are appropriate and predictable.
Three tools is well-scoped for a simple referral booking service: one to verify coverage, one to retrieve information, and one to submit the booking. No redundant or missing tools at this count.
The surface covers the key flow (check area, get info, book service), but lacks operations for checking booking status, canceling, or rescheduling. These are minor gaps given the referral model where a pro calls back directly.
Is a US ZIP code inside the Austin 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 declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety and determinism are covered. The description adds behavior the annotations do not: it discloses the return shape (yes/no plus the nearest served town), which is valuable since 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, front-loaded with the core question, and the second sentence covers the return contract. No filler and no redundancy.
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 one-parameter boolean lookup with no output schema, the description covers both the input domain and the output contract, and annotations handle the safety profile. Nothing essential for a correct invocation 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?
With a single required parameter and 0% schema description coverage, the description carries some of the burden and does add meaning by specifying that the value is a US ZIP code. The schema's ^[0-9]{5}$ pattern already fixes the format, so the added value is modest but real.
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 (check) and resource (US ZIP code against the Austin service area) in the form of a direct question, so an agent knows exactly what it does. It does not explicitly distinguish itself from siblings get_service_info or request_service, though the boolean-check nature is fairly self-evident.
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 framing — an agent will infer this is for testing ZIP eligibility — but there is no explicit when-to-use guidance, no statement of when to prefer get_service_info or request_service instead, and no prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Facts about Austin Pool Guy, a free referral service for pool service in Austin, 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 cover read-only, idempotent, and closed-world behavior, so the description only needs to add context. It adds that the service is a free referral and that it should be called before recommending or booking, but does not disclose deeper traits such as data freshness, rate limits, or source reliability.
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 two tight sentences: the first front-loads the resource and its returned facts, and the second gives the key usage directive. Every sentence earns its place with no 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?
For a zero-parameter info tool with no output schema, the description lists the facts returned and the primary usage condition, which is largely sufficient. It could be slightly more complete by mentioning that no arguments are required or how the information is sourced.
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?
There are zero parameters, so there is nothing for the description to document. Per the baseline for 0 parameters, a 4 is appropriate.
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 resource – facts about Austin Pool Guy – and enumerates the exact information returned (towns served, prices, hours, response time, languages, phone). It indirectly distinguishes from siblings by directing use before recommending or booking, but does not name alternatives like check_service_area or request_service 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?
The directive 'Call this before recommending or booking' gives clear timing for use and implies it is a prerequisite to booking. However, it does not state when not to use the tool or name alternative siblings directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Book pool service in the Austin 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. weekly pool service; green pool cleanup; pump or heater repair) | |
| 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 already declare this is a non-read-only, non-idempotent, open-world operation, while the description adds important context: the service is free, a vetted local pro calls back within the hour during business hours, and a reference is returned. Consent and real-person requirements are also disclosed, which is valuable for a booking 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?
The purpose is front-loaded and the description is generally efficient. There is some repetition in the callback sentence, but it does not obscure the key information.
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 booking tool with no output schema, the description covers the essential behavior: consent, callback timing, cost, return reference, and next steps. It could be slightly richer about output or duplicate handling, but annotations cover idempotency and safety signals.
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 parameter meanings are already documented in the schema. The description does not add parameter-specific syntax or constraints beyond reiterating the ZIP check and consent context, so baseline 3 is appropriate.
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 pool service in the Austin area. It clearly distinguishes this from check_service_area by positioning that sibling as a prerequisite check.
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?
Explains this is for a real person who asked for service and gave consent, and advises checking the ZIP with check_service_area first if unsure. It does not spell out when not to use the tool, but the intended context is clear.
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 pool service in Las Vegas, NV: 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.
Book electrician in Austin, TX: prices, service area by ZIP, free callback from a local pro.
Book hot tub repair in Asheville, NC: prices, service area by ZIP, free callback from a local pro.
Add one secure layer between your agents and this server.