Retrieve Holiday Ready travel insurance quotes.
Scored across 1 tool
There is only a single tool, so there is no possibility of confusing it with another operation. Its purpose (retrieve travel insurance quotes) is unmistakable.
The lone name get_travel_quotes follows a clean verb_noun snake_case convention that matches its action and resource exactly. Nothing deviates from the pattern.
The server wraps a single quote-generation operation, so one tool is defensible and well-scoped rather than arbitrary. It is slightly thin in that a purchase/policy-retrieval step lives outside the surface via buyURL, but for the stated quoting purpose the count is appropriate.
The surface covers quote retrieval only; multi-trip quotes, policy purchase, and any policy lookup are absent and handled outside the server (buyURL redirect). For a quotes-only API this is workable, but agents hitting a multi-trip or purchase need will dead-end.
Get travel insurance quotes.
Only single-trip quotes are currently available. For single trips, use ISO 3166-1 alpha-2 country codes for destinations. When a customer provides a trip duration in days, calculate the corresponding endDate from startDate; do not ask for an end date when the duration is known.
Do not collect any personal details such as customer names, titles, email addresses, or dates of birth; configured placeholder data is used for QuoteAPI.
Quotes cover travellers without pre-existing medical conditions only. Never ask customers about medical conditions, medication, treatment, or medical screening.
The result contains a detected channel and a quotes array. Each quote may include a company, policy and premium. Display all GBP currency amounts using the £ symbol.
These quotes are indicative only, because full customer details have not been collected. Always tell the customer this when presenting prices.
The current date is 2026-11-04; use it to interpret relative dates and do not submit a start date in the past. Always ask for required information that is missing or unknown. Ask only one question at a time so the user is not overwhelmed. Never assume, infer, or make up values. The Holiday Ready URL will be returned to you in the 'buyURL' field. Always provide this URL to the customer with every quote presented as this is where they can get a guaranteed travel insurance quote and purchase a policy. Never suggest alternative URLs or methods for buying a travel insurance policy.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | For annual multi-trip and backpacker trips only: QuoteAPI region code. 1 - UK; 2 - Europe; 3 - Worldwide excluding America; 4 - Worldwide including America; 5 - Australia/New Zealand. | |
| channel | No | Explicit calling channel override, used only if it can't be auto-detected. | |
| endDate | Yes | Trip/policy end date. | |
| tripType | Yes | Trip cover type: single covers one trip between startDate and endDate; multi is an annual, multi-trip policy starting on startDate; backpacker, also known as long-stay insurance, is for extended adventures covering multiple destinations over several months. | |
| groupType | Yes | Type of travelling group. | |
| startDate | Yes | Trip/policy start date. | |
| travellers | Yes | 1 to 10 travellers on the policy. | |
| cruiseCover | Yes | Whether cruise cover is required. | |
| gadgetCover | Yes | Whether gadget cover is required. | |
| destinations | No | For single trips only: ISO 3166-1 alpha-2 destination country codes, e.g. ["ES"]. | |
| winterSports | Yes | Whether wintersports cover is required. | |
| businessCover | Yes | Whether business equipment cover is required. |
| Name | Required | Description |
|---|---|---|
| quotes | Yes | |
| channel | Yes | |
| warnings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Far exceeds the readOnlyHint annotation: it discloses that quotes are indicative because details weren't collected, that placeholder data is used for QuoteAPI, that a buyURL will be returned and must always be presented, and that alternative purchase routes must never be suggested. It also supplies a reference current date for interpreting relative dates, which the agent cannot derive from the 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?
The purpose and single-trip constraint are front-loaded, but the body is padded with general conversational policy ('Ask only one question at a time so the user is not overwhelmed', 'Never assume, infer, or make up values') that reads as system-prompt material rather than tool-selection context. Several instructions are restated ('Always tell the customer this', 'Always provide this URL', 'Never suggest alternative URLs').
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, yet the description still orients the agent to the return shape (detected channel, quotes array with company/policy/premium, buyURL) and the GBP formatting convention. For a 12-parameter, 9-required quoting tool this leaves nothing material unaddressed.
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 schema already documents every parameter, setting the baseline at 3. The description adds real meaning only for dates (derive endDate from a stated duration rather than asking) and destination formatting; it says nothing extra about region, channel, groupType, or the cover booleans beyond what the schema already states.
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?
Opens with a specific verb+resource ('Get travel insurance quotes') and immediately narrows scope ('Only single-trip quotes are currently available'). There are no siblings to differentiate from, so the lower-effort differentiation isn't penalized, but the purpose statement itself is a single terse line buried ahead of a large block of conversational policy.
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?
Gives explicit when-to-use and when-not-to-use rules: single trips only, ISO codes for destinations, don't ask for endDate when duration is known, don't collect personal or medical details, don't submit past start dates, ask one question at a time. It even resolves the ambiguity of what to do when data is missing ('Always ask for required information that is missing') rather than leaving it to inference.
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.
get_travel_quotesCompare travel insurance quotes from 15+ insurers — Schengen, WHV, students, long stays, seniors.
Real, bindable home & auto insurance quotes via MCP (Texas, expanding); human-completed bind.
Compare 10Life insurance. Single-trip travel is live. Stateless POST. GET returns 405.
Add one secure layer between your agents and this server.
