Auto repair quote auditor, labor price benchmarks, and service deals for any US ZIP.
Scored across 2 tools
The two tools have distinct primary purposes (auditing an existing quote vs. finding local deals), but both mention evaluating quote fairness and coupons/rebates. The overlap around 'whether a quote is fair' creates a real risk of misselection.
Both names use snake_case and begin with a verb, which is predictable. However, audit_repair_quote vs. get_evaluated_savings differ in verb style and the latter is slightly awkward, so there is minor inconsistency.
Two tools is thin for a domain that includes quote auditing, local pricing, coupons, rebates, state caps, and OBD checks. Each tool carries many responsibilities, so splitting could improve clarity, but the count is not extreme.
The surface covers the two main workflows: audit an existing quote and find the best local deal with effective price. Minor gaps exist, such as no separate tool for pure price lookup or multi-quote comparison, but agents can work around them.
Audit a mechanic quote, repair estimate, or bill from an image URL or pasted text against US fair market labor rates and parts benchmarks. Identifies potential overcharges, checks state statutory inspection fee caps, flags OBD-II diagnostic inconsistencies, and matches active shop coupons or manufacturer rebates to reduce out-of-pocket costs without adversarial confrontation. US only.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | 5-digit US ZIP code where the repair is quoted. Used for localized labor rates and regional price parity. | |
| text | No | Pasted plain text of the repair estimate, invoice, or list of line items with prices. | |
| vehicle | No | Vehicle details if known. Overrides or supplements details extracted from the document. | |
| image_url | No | URL or base64 data URI of the mechanic quote, invoice, or estimate image/PDF. |
| Name | Required | Description |
|---|---|---|
| shop | No | |
| items | Yes | Line-by-line audit of each repair task on the bill. |
| summary | Yes | Human-readable breakdown of the audit, line item verdicts, and actionable deal savings. |
| vehicle | No | |
| best_coupon | Yes | Highest-value coupon or discount found for this repair job. |
| is_car_sale | No | True if the quote was detected as a car sales/purchase quote rather than auto repair. |
| total_quoted | Yes | Total price quoted on the document in USD. |
| clunker_alert | Yes | Warning if the repair quote exceeds 50% of the vehicle value. |
| document_type | Yes | Type of document analyzed. |
| coupon_savings | Yes | Dollar savings specifically from active coupons or promotions. |
| market_position | No | How the total quote compares to fair market benchmarks. |
| is_international | Yes | True if the quote was detected as non-US or non-USD. |
| potential_savings | Yes | Actionable savings in USD available through verified coupons or rebates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful context beyond them: it is non-adversarial by design, US-scoped, and performs state-by-state fee-cap checks, which explains why idempotentHint=false (live coupon/rebate lookups) rather than contradicting it.
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 action and then the value-added capabilities, with the US-only constraint placed last as a scope tag. Dense but nearly every clause carries information; only the OBD-II clause is arguably niche for selection purposes.
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?
An output schema exists, so return values need no explanation. The accepted input sources (image URL or pasted text) and the optional-vehicle-override behavior are covered; the only real gap is the undefined relationship to the sibling savings tool.
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 zip, text, vehicle sub-fields, and image_url are all already documented in the schema, including the note that vehicle details override extracted document data. The description adds no syntax, format, or precedence guidance beyond that, so the 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 (audit) and resource (mechanic quote, repair estimate, or bill), and enumerates the concrete analyses performed: overcharge detection, statutory fee-cap checks, OBD-II consistency, and coupon/rebate matching. It never names or contrasts with the sibling get_evaluated_savings, so the agent must infer the boundary between the two.
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 description (auditing an existing quote you already have), and 'US only' is a genuine scope constraint. However, no explicit when-to-use vs when-not guidance is given, and the relationship to get_evaluated_savings is left entirely unstated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the best current auto-service deal near a US ZIP or metro and see what you'd actually pay. Returns the local typical price for the service (oil change, brakes, battery, diagnostic, coolant flush, tire rotation, tires), the best current coupon, discount, or rebate, and the net out-of-pocket "effective price" after discounts and rebates, with caveats. Optionally compares against a shop quote the user already has. Use when someone asks what a repair should cost, whether a quote is fair, or where to find a coupon. US only; 16 major metros are priced locally, other ZIPs use national averages.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | 5-digit US ZIP, e.g. "11205". Give zip or city for local pricing; omit both for national averages. | |
| city | No | Metro slug, e.g. "new-york-city", "los-angeles", "houston". Overrides zip. | |
| shop_name | No | Shop or chain the user mentioned, e.g. "Jiffy Lube", to prioritise that brand's deals. | |
| quoted_price | No | A quote the user already has, in USD, e.g. 119. Enables "is this quote fair?" comparison. | |
| service_variant | No | Oil type (oil_change only). Omit to evaluate each offer on its own stated oil type. | |
| service_category | No | Service to price. | oil_change |
| Name | Required | Description |
|---|---|---|
| cached | Yes | True if served from the 12-hour deal cache. |
| summary | Yes | Plain-English summary of the local price and best deal. |
| benchmark | Yes | |
| best_match | Yes | Highest-savings offer, or null if none found. |
| offers_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safe, read-only nature is already declared. The description adds useful behavior: it returns typical price, best coupon, effective price with caveats, and optionally compares against a quote. It doesn't go into details like data freshness, but given strong annotations, this is solid.
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 a single well-structured paragraph that starts with the main purpose, then details the returns and usage context. It is concise, though a bit long; every sentence adds useful information, but a slight restructuring could make it even more scannable.
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?
The tool returns an effective price with caveats, and there is an output schema (not shown) that likely documents the return structure. The description covers input semantics, including service types and the quote comparison, and notes US-only and local coverage. It's complete for agent use, though it doesn't mention error conditions, but these are not critical.
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%, and the description adds value by explaining the overarching logic: zip/city for local pricing, shop_name for brand priority, quoted_price for comparison, and service_variant for oil type. This goes beyond schema descriptions, especially for the interplay between zip and city and the commas in effective price.
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 clearly states the tool's function: find the best auto-service deal near a US ZIP or metro and compute the effective price after discounts. It specifies available service types and the comparison option. The title reinforces this, and there are no siblings that could cause confusion.
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 explicitly states when to use the tool: 'Use when someone asks what a repair should cost, whether a quote is fair, or where to find a coupon.' It also notes US-only and explains the distinction between local pricing for 16 metros and national averages for other ZIPs, providing clear context without naming alternatives.
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.
audit_repair_quote1 field changedOutput schema / properties / is_car_saleAdded value: +{
+ "description": "True if the quote was detected as a car sales/purchase quote rather than auto repair.",
+ "type": "boolean"
+}audit_repair_quoteget_evaluated_savingsCar repair cost estimates by make, model and repair type. 31 cost guides, VIN decode. Free.
US vehicle recalls, complaints, EPA figures, VIN decode and trouble codes, with sources.
Mechanic-grade used-car listing verdicts: risk score, failure points, repair costs, fair price.
Recalls, known issues, and honest maintenance costs for any US-market vehicle since 1990.
Add one secure layer between your agents and this server.
