Real-time passenger van rental availability and pricing across major US cities.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 8 of 8 tools scored. Lowest: 3.6/5.
Each tool targets a distinct action: availability, quoting, coverage, reservation lookup, link generation, locations, and vehicle types. There is no meaningful overlap that could cause an agent to select the wrong tool.
All tools follow a consistent verb_noun pattern using lowercase snake_case (check_, email_, explain_, get_, list_). The convention is uniform across the set.
Eight tools is well-scoped for a rental information and assistance server. Each tool serves a clear purpose and the count is within the ideal range for a domain-specific MCP.
The set has significant gaps: email_quote references a 'saved rate quote' but there is no save_quote tool to create one, and get_my_reservation mentions an admin lookup tool that isn't present. This creates dead ends and will cause agent failures in follow-through workflows.
check_availabilityAInspectCheck 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 | Filter by vehicle type/rate code (e.g., 'Ford Transit', 'Sprinter'). 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?
No annotations are provided, so the description carries the burden. It discloses that the tool uses a scheduling engine to account for reservations, vehicle positioning, and fleet consolidation, and returns availability urgency labels. However, it does not explicitly state that the tool is read-only or mention any error conditions or limitations, leaving some behavioral ambiguity.
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: the first states the purpose, and the second explains the function and return value. There is no fluff or repetition, and it is well-structured.
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 tool's simplicity (5 flat parameters, no output schema), the description covers the essential aspects: what it does, how it works, and what it returns. It lacks a few details like result limits or pagination, but for an availability check, it is sufficiently 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 description coverage is 100%, and each parameter is already well-documented with types, examples, and defaults. The description adds no information about parameters beyond what the schema provides, so a baseline score 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 clearly states the tool's function: checking vehicle availability for rental on specific dates and locations. It names the verb 'check', the resource 'vehicles', and the specific scope 'available for rental', which distinguishes it from sibling tools like get_rate_quote (pricing) and list_rate_codes (catalog).
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 gives clear usage context: 'for rental on specific dates and locations.' It does not explicitly name alternatives or exclusions, but the context is strong enough that an agent can infer when to use this tool versus others like email_quote or get_rate_quote.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
email_quoteAInspectEmail a saved rate quote to a customer. Stores the quote under a token and includes a resume link in the email — when the customer clicks it, they're dropped into the booking flow with their vehicle, dates, and insurance selections already filled in. Rate-limited to 3 emails per day per address.
| Name | Required | Description | Default |
|---|---|---|---|
| email_to | Yes | Customer email address to send the quote to. | |
| end_city | No | 2-letter return location code. Defaults to start_city. | |
| end_date | Yes | Rental end date (YYYY-MM-DD) | |
| end_time | No | Return time, 24hr format without colon. Default '1000'. | |
| rate_code | Yes | Vehicle type/rate code (e.g., 'Ford Transit', 'Sprinter') | |
| start_city | Yes | 2-letter pickup location code | |
| start_date | Yes | Rental start date (YYYY-MM-DD) | |
| start_time | No | Pickup time, 24hr format without colon (e.g., '1000'). Default '1000'. | |
| include_cdw | No | Pre-select Damage Waiver (CDW) on the resumed booking page. Default false — shown as optional add-on. | |
| include_pai | No | Pre-select Personal Accident Insurance (PAI). Default false. | |
| include_rlp | No | Pre-select Primary Liability (RLP). Default false. | |
| include_sli | No | Pre-select Supplemental Liability (SLI). Default false. | |
| discount_code | No | Promotional or discount code | |
| include_cdw_plus | No | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses notable behaviors not visible from schema alone: the token storage, the resume link that pre-fills selections, and the rate limit of 3 emails per day per address. Since there are no annotations, this adds valuable context about side effects and constraints.
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 three concise sentences, front-loaded with the main action. It packs the purpose, key behavior, and a constraint with 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?
The description provides a good high-level context for a complex 14-parameter tool with no output schema. It explains the emailing flow and rate limit. However, it does not mention the return value or what happens on rate-limit failure, leaving a minor gap given the lack of annotations and output schema.
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 covers all 14 parameters with descriptions (100% coverage), so the baseline is 3. The tool description mentions that insurance selections are pre-filled, which relates to the boolean parameters, but it does not add specific parameter-level details 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 clearly states the tool's purpose with a specific verb and resource: 'Email a saved rate quote to a customer.' It distinguishes itself from sibling tools like get_rate_quote or get_reservation_link by focusing on the email-sending action and the resume-link behavior.
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 the usage context: it sends a saved quote and describes the resume flow, which helps an agent understand when to use it. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_coverageAInspectExplain 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.
get_my_reservationAInspectSelf-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_rate_quoteAInspectGet 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.
| 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) | |
| 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/rate code (e.g., 'Ford Transit', 'Sprinter') | |
| 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. It partially discloses internal logic ('Bandago rate engine with DIA multipliers and multi-jurisdiction tax calculations') but does not explicitly state it is a read-only operation, whether the quote depends on availability, or what happens with invalid inputs. No side effects or prerequisites are addressed.
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: the first front-loads the purpose and output specifics, the second adds rate-engine context. Every word earns its place, with no filler or 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?
The description lists expected output components (day rate, insurance, mileage, taxes, total), partially compensating for the lack of an output schema. It also gives useful rate-engine context. However, it omits guidance on prerequisites (e.g., availability check, location code meanings) and error handling, so it is not fully 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 no parameter-specific meaning beyond what the schema already provides; it only lists output components and high-level rate-engine behavior.
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 opens with a specific verb and resource: 'Get a full pricing breakdown for a rental' and enumerates the breakdown components (day rate, insurance, mileage, taxes, grand total). This clearly distinguishes it from sibling tools like check_availability (availability) and email_quote (sending quotes).
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 no explicit guidance on when to use this tool versus alternatives. It does not mention that check_availability might be a prerequisite or that email_quote could send the generated quote. Usage context is only implied by the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reservation_linkAInspectGenerate 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.
| 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) | |
| 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 | Filter to a specific vehicle type (e.g., 'Ford Transit', 'Sprinter'). When provided, only this vehicle will be shown on the booking page. | |
| 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool only generates a link, not a booking, and that the customer completes the booking on the website. This is a critical behavioral trait. However, it does not explicitly state whether any reservation is created immediately or provide other edge-case details.
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 concise sentences with no fluff, front-loaded with the primary action. It is appropriately sized for the tool's simplicity.
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 description explains the tool's purpose, what the customer does, and implicitly indicates the return type (a link). Given no output schema, it does not detail the exact return format, but the description is adequate for understanding the tool's place in the workflow.
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 baseline is 3. The description adds no parameter-specific details beyond what the schema already provides. It only refers to 'dates and locations' which maps to some parameters, but does not enhance schema knowledge.
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: 'Generate a link to start a reservation on Bandago's website with dates and locations pre-filled.' This uses a specific verb ('generate') and identifies the resource (reservation link), clearly distinguishing it from siblings like check_availability or email_quote.
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: this tool is used to generate a link for the customer to self-complete booking. It implies usage (when you need to provide a booking link) but does not explicitly name alternatives or exclusions. The sentence 'The customer will choose their vehicle and complete the booking on the website' clarifies the intended workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_locationsAInspectList 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_rate_codesAInspectList vehicle types/rate codes (e.g., Ford Transit, Sprinter) with specs. These codes are used to identify vehicle classes for availability and pricing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It implies a read-only 'list' operation but does not explicitly state there are no side effects or describe the return format beyond 'with specs.' This is adequate but not rich.
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 redundant wording. The first sentence states what it lists, and the second explains the relevance of the codes. Every word 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?
For a simple list tool with no parameters and no output schema, the description is reasonably complete. It explains the purpose and usage context. However, it could be more specific about what 'specs' are included, which would strengthen completeness for an agent.
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, and the schema coverage is 100% (trivially). Per the calibration baseline, a 0-parameter tool merits a 4, and the description adds context about the purpose of the codes, satisfying any need for semantic explanation.
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 with a specific verb ('List') and resource ('vehicle types/rate codes'), including examples. It distinguishes itself from sibling tools like list_locations and get_rate_quote by focusing on enumerating vehicle classes rather than locations or quotes.
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 by noting these codes are used for availability and pricing, which indicates when this tool would be relevant. However, it does not explicitly name alternative tools or state when not to use it, leaving some room for interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
