Book electrician in Austin, TX: prices, service area by ZIP, free callback from a local pro.
Scored across 3 tools
Each tool targets a distinct step: ZIP eligibility, general service facts, and booking. The only soft overlap is that get_service_info also lists 'towns served,' which partially duplicates what check_service_area resolves, so an agent may occasionally pick the wrong one for a location question.
All three tools follow a clean snake_case verb_noun pattern (check_service_area, get_service_info, request_service) with predictable verbs that match their actions.
Three tools is lean but each maps to a real step in the referral funnel (eligibility, information, booking). Nothing is redundant, though the surface is small enough that it borders on thin.
The pre-booking flow is fully covered, but there are dead ends after booking: no way to look up an existing reference, cancel or reschedule, or list alternate electricians. Agents handling follow-up requests would have nothing to call.
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 Volts, a free referral service for electrician 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 the safety profile (readOnly, idempotent, openWorld=false), so the bar is lower. The description adds real context: the entity is a free referral service, and the specific categories of information returned are listed, which matters because there is no output schema. No gaps around auth or rate limits are relevant for a static read.
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 information sentence plus one imperative directive. The field list is front-loaded and every enumerated item earns its place because no output schema exists to document return values.
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 parameters, no output schema, and annotations carrying the safety profile, the description covers everything an agent needs: who the provider is, what facts come back, and when in the workflow to call it. Nothing material 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?
The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies no inputs are required, and there is nothing further it could add about parameter semantics.
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 subject (Austin Volts referral service) and enumerates exactly what facts it returns: towns served, prices, hours, response time, languages, phone. That distinguishes it from check_service_area and request_service by implication, but neither sibling is named, so differentiation is left to inference.
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 a clear sequencing directive and a concrete moment to use it. It stops short of stating when NOT to use it or explicitly routing to check_service_area for address-specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Book electrician 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. panel upgrade or replacement; ev charger installation; electrical repairs) | |
| 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 only declare readOnly=false, openWorld=true, idempotent=false, destructive=false. The description adds meaningful behavior the annotations do not cover: the service is free to the homeowner, the callback happens within the hour during business hours, and the tool returns a reference plus next steps. It does not cover request failure or duplicate-submission behavior, which matters given 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?
The core facts are front-loaded, but the callback behavior is stated twice in the same sentence ('A vetted local pro calls them back (a vetted local pro calls back within the hour...)'), which is wasted repetition that should have been merged into one precise statement.
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 7-parameter write action with no output schema, the description covers the key agent-facing needs: consent requirement, geography, cost, response timing, and what is returned. It stops short of describing error handling or what a declined/non-serviceable ZIP looks like.
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 all seven parameters are already documented in the schema; the baseline of 3 applies. The description adds only the ZIP/check_service_area cross-reference, not format or constraint detail beyond what the schema already provides.
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 ('Book electrician in the Austin area') plus the outcome (a vetted local pro calls back), which is enough to distinguish it from check_service_area and get_service_info. It also states the artifact returned ('a reference and what happens next').
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 precondition (a real person who asked, with their consent) and routes the agent to the sibling check_service_area first 'if unsure' about the ZIP. That is clear contextual guidance, though the 'if unsure' hedge leaves the exact threshold for pre-checking to inference and there is no explicit when-not clause.
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 Kansas City, MO: 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 AC repair in El Paso, TX: prices, service area by ZIP, free callback from a local pro.
Book plumber in Kansas City, MO: prices, service area by ZIP, free callback from a local pro.
Add one secure layer between your agents and this server.