Real-time passenger van rental availability and pricing across major US cities.
Scored across 7 tools
Each tool targets a distinct verb+resource: availability checking, coverage explanation, self-service reservation lookup, pricing, booking-link generation, location listing, and rate-code listing. The descriptions explicitly draw boundaries (e.g. get_my_reservation points staff detail elsewhere, explain_coverage says 'use this instead of quoting from memory') and even warn that list_rate_codes' rate_code is the key other tools consume. The only wrinkle is a passing reference to a 'lookup_reservation (admin)' tool that isn't in this set, but that doesn't blur boundaries between the tools that exist.
All seven tools follow a clean snake_case verb_noun pattern (check_, explain_, get_, list_) with clear nouns. The only mild deviation is the possessive in get_my_reservation, which is still readable and consistent in style. No camelCase or vague verb mixing.
Seven tools is well within the ideal range and each one covers a discrete step in the rental funnel (locations → vehicle types → availability → quote → booking link → coverage → own reservation). Nothing feels redundant or padded.
The browse/price/book/self-serve-lookup flow is covered end to end, including the deliberate use of a booking-link generator instead of a create_booking tool. Gaps: no modify/cancel reservation operation at all (explicitly punted to the VIP program), and the descriptions reference an admin-side lookup_reservation that isn't part of this server, which could dead-end an agent asked for staff-level detail.
Check which vehicles are available for rental on specific dates and locations. Uses the scheduling engine to account for existing reservations, vehicle positioning, and fleet consolidation. Returns a list of available vehicle types (rate codes) with availability urgency labels.
| Name | Required | Description | Default |
|---|---|---|---|
| end_city | No | 2-letter return location code. Defaults to start_city if not specified (round-trip). | |
| end_date | Yes | Rental end date, YYYY-MM-DD (four-digit year, e.g. 2026-12-18) | |
| rate_code | No | Optional vehicle type filter: an exact rate_code from list_rate_codes (e.g. 'Transit Std', 'SP15'), a display name ('Transit Medium Roof'), or a brand word ('Sprinter', 'Transit') to include every type of that brand. Omit to check all types. | |
| start_city | Yes | 2-letter pickup location code (e.g., 'LA', 'NA', 'SF') | |
| start_date | Yes | Rental start date, YYYY-MM-DD (four-digit year, e.g. 2026-12-18) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that availability is computed by a scheduling engine that accounts for reservations, vehicle positioning, and fleet consolidation, and it states the return shape (rate codes with urgency labels). A minor gap is that the urgency labels are not defined.
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 concise sentences with no filler: the purpose is front-loaded, followed by algorithmic context and return behavior. Every sentence contributes 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 5-parameter tool with no output schema or annotations, the description covers purpose, computation context, and return content. It doesn't detail the meaning or range of urgency labels, but an agent has enough to select and call the tool 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 coverage is 100%, so each parameter already has a description. The tool description adds context around dates/locations but does not need to repeat parameter details; 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?
Description names a specific verb ('Check'), a resource ('vehicles available for rental'), and the key filtering dimensions (specific dates and locations). The return statement about available vehicle types/rate codes distinguishes it from siblings like get_rate_quote and list_rate_codes.
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 establishes a clear use case: checking availability for rental on given dates and locations. It does not explicitly name sibling alternatives or exclusions (e.g., when to use get_rate_quote instead), so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain Bandago's optional insurance / coverage products (CDW, Damage Waiver Plus, RLP, SLI, PAI, and THE WORKS bundle) with authoritative deductibles, dollar limits, PAI benefits, brochure links, and online availability. Reads the centralized policy source of truth, so limits and availability are state-correct. Also covers Damage Waiver Plus, the paid upgrade that lowers the customer's damage responsibility below the standard CDW deductible, so call this for any question about deductibles or lowering the deductible. Pass a state or location to get the exact SLI limit and whether RLP/SLI can be bought online there (they are restricted in some states, e.g. FL/GA/TX). Use this instead of quoting coverage details from memory.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | 2-letter US state code (e.g., 'TX', 'CA') for state-correct SLI limits and online availability. | |
| location | No | 2-letter Bandago location code (e.g., 'MI', 'LA'); resolved to its state when 'state' is not given. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool 'Reads the centralized policy source of truth,' implying a non-mutating operation, and mentions state-correctness and restrictions. It does not explicitly state it makes no changes or discuss potential errors, but the read-only nature is clear from 'Reads' and 'Explain.'
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 somewhat long but every sentence adds unique value: product list, data sources, DWP detail, parameter usage, and explicit guidance to not rely on memory. It is structured logically from products to usage, but could be tightened by reducing redundancy (e.g., 'DWP' is mentioned with its full name and purpose twice).
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 the complexity of coverage products and no output schema, the description thoroughly explains what the tool returns (deductibles, limits, benefits, links, availability), how to get state-correct info, and why it should be used over memory. It covers the essential aspects an agent needs to confidently invoke and interpret the 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 baseline is 3. The description adds meaningful context by explaining the purpose of passing state or location—to get exact SLI limits and online availability restrictions (FL/GA/TX examples). This goes beyond the bare schema descriptions of state and location.
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 purpose: explaining Bandago's optional insurance/coverage products. It lists specific products (CDW, DWP, RLP, SLI, PAI, THE WORKS) and distinguishes it from sibling tools like get_rate_quote and check_availability by focusing on coverage details rather than pricing or availability.
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?
Provides explicit usage guidance: 'call this for any question about deductibles or lowering the deductible' and 'Use this instead of quoting coverage details from memory.' Also gives context for when to pass state/location to get state-correct limits and online eligibility, effectively covering when and why to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Self-service lookup of a customer's own reservation. Requires BOTH the confirmation number AND an email that matches the reservation (renter or cardholder). Returns customer-facing details only: status, vehicle, pickup/return dates, locations, and totals. Use this to answer 'what are my dates / where do I pick up / what did I book'. For changing or cancelling, point the customer to the VIP program. Does NOT expose internal notes or staff fields — use lookup_reservation (admin) for full staff detail.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The customer's email on the reservation (renter or cardholder). Must match for the lookup to return. | ||
| conf_id | Yes | The reservation confirmation number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it requires both confirmation number and a matching email, returns only customer-facing details, and does not expose internal notes or staff fields. It also implies read-only behavior by directing change/cancel requests elsewhere. No contradictions exist.
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 primary action, and every subsequent sentence adds value: required fields, returned data, use cases, exclusions, and alternative tools. It is concise yet comprehensive without being verbose.
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?
Despite having no output schema, the description lists the specific return fields (status, vehicle, pickup/return dates, locations, totals), which informs the agent about expected output. It also covers authentication requirements, use cases, and when to use other tools. For a self-service lookup of modest complexity, the description is complete.
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. The description adds emphasis ('Requires BOTH...') and clarifies that the email must match the reservation (renter or cardholder), but this information is largely already present in the schema descriptions. No additional syntax or format details are provided beyond the schema.
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 purpose: 'Self-service lookup of a customer's own reservation.' It specifies the resource (reservation), the actor (customer), and the typical use cases. It also distinguishes itself from the admin-level lookup_reservation tool.
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?
Explicitly states when to use it: 'Use this to answer what are my dates / where do I pick up / what did I book.' Also gives exclusions and alternatives: 'For changing or cancelling, point the customer to the VIP program' and 'use lookup_reservation (admin) for full staff detail.' This leaves no ambiguity about appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a full pricing breakdown for a rental including day rate, insurance options, mileage allowance, applicable taxes, and grand total. Uses the Bandago rate engine with DIA (days-in-advance) multipliers and multi-jurisdiction tax calculations. grand_total includes every optional coverage and its tax. sales_tax is every tax and fee on the price without optional coverage (state, city and county taxes, surcharges, per-day fees), itemized in taxes; price_without_coverage is subtotal plus sales_tax. Each coverage chosen adds its _total and its _tax (the tax charged on it at that location, 0 where it is untaxed).
| Name | Required | Description | Default |
|---|---|---|---|
| No | Customer email (used for VIP rate detection) | ||
| end_city | No | 2-letter return location code. Defaults to start_city. | |
| end_date | Yes | Rental end date, YYYY-MM-DD (four-digit year, e.g. 2026-12-18). A one-day rental returns the next day at the same time; never equal to start_date. | |
| end_time | No | Return time in 24hr format without colon (e.g., '1000' for 10:00 AM, '1400' for 2:00 PM). Defaults to '1000'. Valid values: 0900, 0930, 1000, 1030, 1100, 1130, 1200, 1230, 1300, 1330, 1400, 1430, 1500, 1530, 1600, 1630. | |
| rate_code | Yes | Vehicle type as an exact rate_code from list_rate_codes, e.g. 'Transit Std' (Ford Transit medium roof, 15 passengers), 'SP15' (Sprinter 15-passenger), 'SP Crew 12'. A display name such as 'Transit Medium Roof' is also accepted. Brand-only values such as 'Ford Transit' or 'Sprinter' match several types and are rejected with the candidates listed. | |
| start_city | Yes | 2-letter pickup location code | |
| start_date | Yes | Rental start date, YYYY-MM-DD (four-digit year, e.g. 2026-12-18) | |
| start_time | No | Pickup time in 24hr format without colon (e.g., '1000' for 10:00 AM, '1400' for 2:00 PM). Defaults to '1000'. Valid values: 0900, 0930, 1000, 1030, 1100, 1130, 1200, 1230, 1300, 1330, 1400, 1430, 1500, 1530, 1600, 1630. | |
| discount_code | No | Promotional or discount code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that pricing comes from the Bandago rate engine with DIA multipliers and multi-jurisdiction tax logic, and it defines exactly how grand_total, sales_tax, price_without_coverage, and per-coverage _total/_tax are composed. It does not say whether quotes expire, are guaranteed, or have rate limits, which keeps it below a 5.
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 purpose in the first clause, then moves into output semantics. It is dense but nearly every sentence carries distinct information; the tax/coverage definitions are slightly repetitive across sentences but justified given the absence of an output schema.
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 9-parameter pricing tool with no output schema, the description substitutes well by defining the returned price components and their relationships. Gaps remain around quote validity/lifetime and interaction with check_availability and list_rate_codes, which an agent would need to sequence calls 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 every parameter is already documented, including the rate_code matching rules and time/date formats. The description adds essentially no parameter-level meaning beyond what the schema provides, so the baseline of 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 and resource ('Get a full pricing breakdown for a rental') and enumerates exactly what the breakdown contains (day rate, insurance options, mileage allowance, taxes, grand total). This clearly separates it from siblings like check_availability and list_rate_codes, which do not price a rental.
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 only implied: the tool is evidently for pricing a specific vehicle/date/location combination, and the rate_code parameter notes the value comes from list_rate_codes. There is no explicit statement of when to prefer this over check_availability, whether availability should be confirmed first, or whether the quote reserves anything.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a link to start a reservation on Bandago's website with dates and locations pre-filled. The customer will choose their vehicle and complete the booking on the website. This is the only valid way to produce a booking URL.
| Name | Required | Description | Default |
|---|---|---|---|
| end_city | No | 2-letter return location code. Defaults to start_city if not specified (round-trip). | |
| end_date | Yes | Rental end date (YYYY-MM-DD). A one-day rental returns the next day; never equal to start_date. | |
| end_time | No | Return time in 24hr format without colon (e.g., '1000' for 10:00 AM, '1400' for 2:00 PM). Defaults to start_time. Valid values: 0900, 0930, 1000, 1030, 1100, 1130, 1200, 1230, 1300, 1330, 1400, 1430, 1500, 1530, 1600, 1630. | |
| rate_code | No | Pre-select one vehicle type: the exact rate_code from list_rate_codes or from the get_rate_quote result (e.g. 'Transit Std', 'SP15'). Use the same value you quoted so the page matches the quote. Omit to let the customer choose. | |
| start_city | Yes | 2-letter pickup location code (e.g., 'LA', 'NA', 'SF') | |
| start_date | Yes | Rental start date (YYYY-MM-DD) | |
| start_time | No | Pickup time in 24hr format without colon (e.g., '1000' for 10:00 AM, '1400' for 2:00 PM). Defaults to '1000'. Valid values: 0900, 0930, 1000, 1030, 1100, 1130, 1200, 1230, 1300, 1330, 1400, 1430, 1500, 1530, 1600, 1630. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It usefully clarifies that the customer, not the agent, chooses the vehicle and completes the booking on the website, and that this is the only valid way to produce a booking URL. It does not describe return format, permissions, or other side-effect details, but for a link-generation tool the stated context is reasonably adequate.
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 sentences with no wasted words. It front-loads the core purpose, then adds the critical clarification that the customer completes the booking, and finishes with a strong selection rule. Every sentence earns its place.
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 has rich schema documentation for all 7 parameters, and the description provides the main behavioral context: it generates a pre-filled reservation link, the customer finishes booking on the website, and this is the only valid way to produce such a URL. Since there is no output schema, a slightly more explicit statement of the return value format would make it fully complete, but the word 'link' and the stated purpose largely cover this.
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 parameters are already well documented. The description adds no new parameter-level meaning beyond saying that dates and locations will be pre-filled, which is a minor behavioral note rather than an enrichment of individual parameter semantics. A baseline of 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?
The description states a specific action ('Generate a link'), a specific resource ('a reservation on Bandago's website'), and the key behavior of pre-filling dates and locations. It also differentiates itself by noting this is the only valid way to produce a booking URL, which clearly separates it from the sibling tools.
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 phrase 'This is the only valid way to produce a booking URL' gives a clear selection rule for when to use this tool. However, it does not explicitly name alternatives or state when NOT to use this tool in favor of siblings like check_availability or list_rate_codes, so it stops just short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Bandago rental locations with addresses and contact info. Returns active locations by default.
| Name | Required | Description | Default |
|---|---|---|---|
| include_inactive | No | Include inactive/non-public locations (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that active locations are returned by default and that addresses/contact info are included, which is useful. However, it does not mention whether authentication is required, pagination, or the meaning of 'active', leaving some room for interpretation.
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 concise sentences that front-load the primary purpose and include the key behavioral nuance (default active). No filler or redundant 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?
Given the simple nature of the tool (list locations) and no output schema, the description covers the basic return content (addresses, contact info) and default behavior. It could mention authentication or edge cases, but for a list tool this is reasonably complete.
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 schema provides 100% coverage for the single parameter 'include_inactive' with a clear description and default. The tool description adds no additional parameter semantics beyond what the schema already states. Baseline 3 is appropriate since schema fully documents the only parameter.
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 a specific verb 'List' with a specific resource 'Bandago rental locations', and specifies the returned data (addresses and contact info). It distinguishes from sibling tools like 'get_rate_quote' or 'check_availability' which focus on pricing or availability.
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 for listing locations and notes default behavior (active only), but does not explicitly state when to use this tool versus alternatives or any exclusions. It provides enough context for a simple list tool, but lacks explicit 'when to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List vehicle types with specs. The rate_code value returned here (e.g. 'Transit Std', 'SP15', 'SP Crew 12') is the exact string the availability, quote and booking-link tools take; display_name is the customer-facing name.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the meaning of the returned fields (rate_code vs display_name) and their relationship to other tools, which is helpful. However, it does not explicitly state that the operation is read-only, nor does it mention any permissions, limits, or potential side effects. For a simple listing tool, this is adequate but not comprehensive.
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 sentences, front-loaded with the core action ('List vehicle types with specs') followed by the crucial detail about the rate_code field. Every sentence adds essential value, and the examples make it concrete without padding. This is a model of concise, well-structured tool documentation.
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 tool with no output schema, the description covers the key aspects: what the tool returns and how the returned values are used downstream. It explains the distinction between rate_code and display_name, which is critical. However, it does not enumerate all fields returned (e.g., what 'specs' includes), though the examples provide enough context for an agent to proceed. The description is largely complete for 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?
The tool has zero parameters, so the schema coverage is effectively 100%. The description does not need to explain parameters since there are none. It does, however, clarify the meaning of the output fields, which is valuable for the agent. With no parameters, the baseline score of 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 clearly states the verb 'List' and the resource 'vehicle types with specs', making the purpose unambiguous. It further distinguishes this tool from siblings by explicitly noting that the rate_code returned is the exact string consumed by availability, quote, and booking-link tools, which positions it as the canonical source for those values.
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 provides clear context: use this tool to obtain the exact rate_code string needed by other tools. It does not explicitly mention when not to use it or name alternatives, but the guidance is specific enough to guide an agent. The emphasis on rate_code being the exact input for other tools implies when this tool is relevant.
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_availability1 field changedInput schema / properties / rate_code / descriptionPrevious value: -"Filter by vehicle type/rate code (e.g., 'Ford Transit', 'Sprinter'). Omit to check all types."New value: +"Optional vehicle type filter: an exact rate_code from list_rate_codes (e.g. 'Transit Std', 'SP15'), a display name ('Transit Medium Roof'), or a brand word ('Sprinter', 'Transit') to include every type of that brand. Omit to check all types."email_quoteget_rate_quote2 fields changedInput schema / properties / end_date / descriptionPrevious value: -"Rental end date, YYYY-MM-DD (four-digit year, e.g. 2026-12-18)"New value: +"Rental end date, YYYY-MM-DD (four-digit year, e.g. 2026-12-18). A one-day rental returns the next day at the same time; never equal to start_date."Input schema / properties / rate_code / descriptionPrevious value: -"Vehicle type/rate code (e.g., 'Ford Transit', 'Sprinter')"New value: +"Vehicle type as an exact rate_code from list_rate_codes, e.g. 'Transit Std' (Ford Transit medium roof, 15 passengers), 'SP15' (Sprinter 15-passenger), 'SP Crew 12'. A display name such as 'Transit Medium Roof' is also accepted. Brand-only values such as 'Ford Transit' or 'Sprinter' match several types and are rejected with the candidates listed."get_reservation_link2 fields changedInput schema / properties / end_date / descriptionPrevious value: -"Rental end date (YYYY-MM-DD)"New value: +"Rental end date (YYYY-MM-DD). A one-day rental returns the next day; never equal to start_date."Input schema / properties / rate_code / descriptionPrevious value: -"Filter to a specific vehicle type (e.g., 'Ford Transit', 'Sprinter'). When provided, only this vehicle will be shown on the booking page."New value: +"Pre-select one vehicle type: the exact rate_code from list_rate_codes or from the get_rate_quote result (e.g. 'Transit Std', 'SP15'). Use the same value you quoted so the page matches the quote. Omit to let the customer choose."email_quote1 field changedInput schema / properties / include_cdw_plusAdded value: +{
+ "description": "Quote Damage Waiver Plus, the upgrade that lowers the customer's damage responsibility from the standard deductible to the Plus deductible for a per-day upcharge. Only honored when include_cdw is also true and Plus is currently offered; otherwise the quote falls back to the standard waiver. Call explain_coverage for the current deductibles and price. Default false.",
+ "type": "boolean"
+}check_availability4 fields changedInput schema / properties / end_date / descriptionPrevious value: -"Rental end date (YYYY-MM-DD)"New value: +"Rental end date, YYYY-MM-DD (four-digit year, e.g. 2026-12-18)"Input schema / properties / end_date / patternAdded value: +"^\\d{4}-\\d{2}-\\d{2}$"Input schema / properties / start_date / descriptionPrevious value: -"Rental start date (YYYY-MM-DD)"New value: +"Rental start date, YYYY-MM-DD (four-digit year, e.g. 2026-12-18)"Input schema / properties / start_date / patternAdded value: +"^\\d{4}-\\d{2}-\\d{2}$"get_rate_quote4 fields changedInput schema / properties / end_date / descriptionPrevious value: -"Rental end date (YYYY-MM-DD)"New value: +"Rental end date, YYYY-MM-DD (four-digit year, e.g. 2026-12-18)"Input schema / properties / end_date / patternAdded value: +"^\\d{4}-\\d{2}-\\d{2}$"Input schema / properties / start_date / descriptionPrevious value: -"Rental start date (YYYY-MM-DD)"New value: +"Rental start date, YYYY-MM-DD (four-digit year, e.g. 2026-12-18)"Input schema / properties / start_date / patternAdded value: +"^\\d{4}-\\d{2}-\\d{2}$"explain_coverageget_my_reservationemail_quoteget_rate_quote2 fields changedInput schema / properties / end_timeAdded value: +{
+ "description": "Return time in 24hr format without colon (e.g., '1000' for 10:00 AM, '1400' for 2:00 PM). Defaults to '1000'. Valid values: 0900, 0930, 1000, 1030, 1100, 1130, 1200, 1230, 1300, 1330, 1400, 1430, 1500, 1530, 1600, 1630.",
+ "type": "string"
+}Input schema / properties / start_timeAdded value: +{
+ "description": "Pickup time in 24hr format without colon (e.g., '1000' for 10:00 AM, '1400' for 2:00 PM). Defaults to '1000'. Valid values: 0900, 0930, 1000, 1030, 1100, 1130, 1200, 1230, 1300, 1330, 1400, 1430, 1500, 1530, 1600, 1630.",
+ "type": "string"
+}get_reservation_link1 field changedInput schema / properties / rate_codeAdded value: +{
+ "description": "Filter to a specific vehicle type (e.g., 'Ford Transit', 'Sprinter'). When provided, only this vehicle will be shown on the booking page.",
+ "type": "string"
+}get_reservation_linkcheck_availabilityget_rate_quotelist_locationslist_rate_codesFree, no-login rental car search with real-time pricing.
Last-minute booking slots across 11 suppliers. Search, price, and execute bookings via AI agents.
Real availability, prices and bookings of car rental companies (rent-a-car), by conversation.
Book parking, car washes, EV charging, gas and auto repair across the US with live pricing.
Add one secure layer between your agents and this server.