Skip to main content
Glama
Sign In

Bandago Van Rentals

by com.bandago
OverviewDiscussionsAdmin

get_rate_quote

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).

Input Schema

NameRequiredDescriptionDefault
emailNoCustomer email (used for VIP rate detection)
end_cityNo2-letter return location code. Defaults to start_city.
end_dateYesRental 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_timeNoReturn 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_codeYesVehicle 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_cityYes2-letter pickup location code
start_dateYesRental start date, YYYY-MM-DD (four-digit year, e.g. 2026-12-18)
start_timeNoPickup 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_codeNoPromotional or discount code

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / end_date / description
      Previous 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."
    • changedInput schema / properties / rate_code / description
      Previous 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."
  2. Changed4 schema fields changed
    • changedInput schema / properties / end_date / description
      Previous value: -"Rental end date (YYYY-MM-DD)"New value: +"Rental end date, YYYY-MM-DD (four-digit year, e.g. 2026-12-18)"
    • addedInput schema / properties / end_date / pattern
      Added value: +"^\\d{4}-\\d{2}-\\d{2}$"
    • changedInput schema / properties / start_date / description
      Previous value: -"Rental start date (YYYY-MM-DD)"New value: +"Rental start date, YYYY-MM-DD (four-digit year, e.g. 2026-12-18)"
    • addedInput schema / properties / start_date / pattern
      Added value: +"^\\d{4}-\\d{2}-\\d{2}$"
  3. Changed2 schema fields changed
    • addedInput schema / properties / end_time
      Added 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"
+}
    • addedInput schema / properties / start_time
      Added 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"
+}
  4. First observed

TDQS

A3.9/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

All Bandago Van Rentals toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources