AirTreks MCP

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and the description does not contradict that. It adds useful behavioral context: this is an itinerary-construction tool that recommends carriers and handles non-alliance fare structures, rather than a simple fare lookup. It stops short of describing response format or side-effect details, but with readOnly annotations the gap is small.

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?

Four short sentences; front-loaded with the core action, then capability examples, then an explicit usage rule. The '90% of itineraries' sentence is mildly promotional but reinforces the tool's role as the default for complex routes.

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 moderately complex tool with no output schema, the description explains when to use it, what it produces, and what route shapes it handles. It doesn't detail return structure or error behavior, but the input schema and annotations cover the remaining invocation needs.

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 covers 100% of parameters with clear descriptions and enums, so the description isn't required to restate parameter details. The description adds contextual color (LCCs, surface sectors, Gulf bridge) that helps interpret budget/preferences, but this doesn't significantly extend the schema's already-strong parameter documentation.

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 uses a specific verb ('Break') and resource ('complex multi-city itinerary') and clearly states the deliverable ('individually-ticketable segments with carrier recommendations'). It also distinguishes itself from sibling route/fare tools by targeting routes that don't fit alliance fare rules.

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?

Explicit positive trigger: 'Use this for any route with 4+ stops, backtracking, or region combinations that alliance fares can't cover.' It also gives domain context (mixed carriers, LCCs, Gulf bridge, surface sectors), but it doesn't name when-not-to-use or point to alternative sibling tools, so not a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the tool is read-only (readOnlyHint=true), and the description adds valuable context about the matching logic, such as considering stop count, direction, and backtracking, which clarifies expected behavior without redundancy. It does not introduce any contradictions and supplements the annotations with useful procedural 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 concise, consisting of two sentences that get straight to the point. It front-loads the primary purpose and uses the second sentence to add relevant details about the decision factors, with no fluff or repetition of schema 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 tool's simplicity (three parameters, no output schema), the description provides enough context for an agent to understand what the tool does and what factors are considered. It could be more explicit about the return value's format or edge cases, but for a read-only matching tool, the provided information is largely sufficient.

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?

While the schema already provides descriptions for all parameters, the tool description enriches their semantics by linking 'stop count' to the cities array length, 'direction' to isOneDirection, and 'backtracking' to includeBacktracking. This additional context helps agents understand how the parameters influence the recommendation, going beyond simple type definitions.

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: recommending a fare product type for a route. It uses a specific verb ('Recommend'), names the resource ('best fare product type'), and provides concrete examples ('RTW, Circle Pacific, Circle Atlantic, Open Jaw, or Custom Multi-CCity'), distinguishing it from sibling tools like route_validate or fare_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 implies the tool is for matching routes to fare products by considering specific factors (stop count, direction, backtracking), but it does not explicitly state when to use this tool versus alternatives. There is no mention of when not to use it or a direct comparison to sibling tools, leaving the usage guidance implicit rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With readOnlyHint=true already disclosed, the description adds meaningful behavioral context: every flown leg requires a date, the itinerary is priced as a single fare, and complex multi-continent trips may come back unpriceable. It does not go into failure/response detail, but the annotation plus description gives a clear behavioral picture.

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 purpose, followed by constraint and usage guidance. Every sentence earns its place; it is concise enough while still conveying important edge cases.

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?

Even with no output schema, the description conveys what results to expect ('actual flights, actual prices', 'fare options'), when to invoke it, and when not to. For a tool with 7 parameters and 2 required, this description is sufficient for an agent to select and invoke 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?

The schema already covers 100% of parameters, so the baseline is 3. The description adds extra meaning by explaining the 'single fare' pricing behaviour and the need for a departure date for every flown leg, which helps interpret the dates and cities arrays beyond their schema descriptions.

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 uses a specific verb ('Get live, bookable-quality fares') and resource ('one specific itinerary'), and immediately differentiates itself from route_estimate by contrasting 'real numbers' with a 'ballpark'. This makes the tool's scope unmistakable.

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 this tool ('once the customer has settled on cities and dates') and names an alternative (route_estimate) for the open-dates case. It also gives a practical exclusion: very long or awkward multi-continent trips may need to be split, which is actionable guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and the description reinforces this by using read-only language like 'identifies,' 'suggests,' and 'shows.' It adds meaningful behavioral detail about dead legs, alliance-fare failures, and carrier combinations, going beyond the structured annotation context.

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 compact and front-loaded. The first sentence states the core function, the second adds valuable detail about what it identifies/suggests/shows, and the third tells when it is essential. No filler or repetition.

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?

Considering the lack of an output schema, the description does a good job of indicating what the tool will surface: best connections, dead legs, hub fixes, and carrier combinations. It could be more explicit about the output format or how 'best' is determined, but it is generally complete enough for an agent to select 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?

The schema already covers 100% of parameters with clear descriptions (e.g., IATA codes, alliance options). The description adds general context about alliance fares and routing but does not materially deepen the understanding of the individual parameters beyond what the schema 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 function: 'Check the best connection between two airports' and specifies distinctive outputs like dead legs, hub routing fixes, and proven carrier combinations. It is specific about verb and resource, but it does not explicitly contrast itself with sibling tools like route_suggest or plan_route.

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 says the tool is 'essential for transpacific, kangaroo, and intra-Asia routing,' which provides useful context for when to use it. It does not explain when not to use it or name alternatives from the sibling list, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description discloses key behavioral traits: the operation takes about a minute, returns a quoteReference immediately, and requires that reference to retrieve the quote—noting it is the only way to retrieve it. This is valuable, non-obvious context.

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?

Four dense, purposeful sentences. The description front-loads the core purpose and output, then provides usage guidance and async behavior. 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?

Despite having no output schema, the description conveys what results to expect (cheapest, fastest, fewest stops with actual tickets), explains the asynchronous flow, and warns about the retrieval dependency. This is comprehensive for a tool of this complexity.

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 all six parameters. The description adds contextual framing about multi-stop trips and fare structures but does not add new parameter-level semantics 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 prices a complete multi-stop or round-the-world trip and returns multiple ticketing options. It also distinguishes itself from sibling tools like fare_quote and itinerary_quote_status, making its purpose unmistakable.

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 says when to use this tool ('trips that will not go on a single fare, which is most itineraries with 3+ stops') and names the alternative: 'use fare_quote when you want one specific itinerary on one ticket.' It also directs users to itinerary_quote_status for fetching results.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses cost (nothing) and side-effect (does no searching) beyond the readOnly annotation. Also describes return behavior: status 'pending' with wait time or finished options, providing a clear picture of what happens on invocation.

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 with no redundancy. All key information is included: operation, input, return type, cost, and usage tip. Structure is efficient and clear.

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 simplicity of the tool, the description covers essential context: what it returns, when to use it, and its cost behavior. It does not need to explain error handling or more complex aspects for a straightforward status-check operation.

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 already fully describes the quoteReference parameter as the one returned by itinerary_quote; the description only reiterates this without adding new meaning. No additional parameter semantics are provided.

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?

Clearly states it fetches the result of an itinerary_quote using the quoteReference, distinguishing it from the creation tool (itinerary_quote) and other quote-related tools. The verb 'Fetch' and specific resource 'result of an itinerary_quote' are explicit.

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 advises using this tool for polling rather than starting a second quote, with the rationale that it costs nothing and does no searching. This gives clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the tool automatically evaluates route options and recommends the best approach, and mentions internal processes like direction detection and backtracking analysis. This goes beyond the readOnlyHint annotation by providing insight into its decision-making, though it does not address potential limitations or edge cases.

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 succinct but informative, front-loaded with the purpose, and organized in a clear flow. It avoids unnecessary detail but packs in relevant capabilities 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?

Given the simple schema with full descriptions and no output schema, the description is complete in explaining the tool's function. It covers the types of routes evaluated, the recommendations made, and the internal handling of trip complexities, leaving no significant gaps.

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 description only references cities ('Give it your cities') and does not add any meaning to the pax, budget, or preferences parameters beyond what is already in the schema. Since the schema already fully describes each parameter, the tool description adds no additional semantic value.

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 is the primary entry point for multi-city trip planning, specifically evaluating Star Alliance RTW, oneworld RTW, and custom mixed-carrier builds. It distinguishes itself from sibling tools by positioning as the comprehensive planner for any multi-city itinerary.

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 says it is for 'any multi-city trip' and acts as the 'primary entry point', making it clear when to use this tool over alternatives. It also mentions handling various route complexities, reinforcing its role as the go-to for full planning.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only provide readOnlyHint and openWorldHint, so the description adds valuable behavioral context: it surfaces historical data, per-person USD ranges, confidence via history, and limitations around availability and seasonality. No contradiction with annotations.

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 uses four sentences, each earning its place: purpose and data source, output format, when to use it, and a key limitation. It is front-loaded with the core purpose and avoids unnecessary fluff.

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?

With no output schema, the description adequately explains the return value as a per-person USD range with historical backing. It also covers the main selection context and limitations. It could be slightly stronger by naming alternative live-quote tools, but it is sufficient for a two-parameter 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%, with both cities and cabin documented in detail including IATA code syntax and the '000' overland marker. The description adds no parameter meaning beyond what the schema already provides, so the baseline 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 gets a price range for multi-city or round-the-world trips from historical AirTreks customer bookings. It specifies the resource, data source, and key scope, and distinguishes itself from a live quote even without naming 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?

It explicitly says to use this tool when someone asks trip cost without exact dates and notes it needs no dates or passenger details. It also clarifies it is not a live quote, implying the alternative for live quotes, though it does not name a specific sibling tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With readOnlyHint=true already covering safety, the description adds genuinely valuable behavior: 'up to 3 proven routing templates with bookability ratings' informs the agent about result cardinality and quality signals, and 'proven' suggests historical/heuristic data. This enriches the output semantics beyond the Boolean annotations, though it could have elaborated on determinism or result freshness.

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 tightly constructed sentences: the first states the tool's function, the second the output contract, and the third the use case. Every clause earns its place with zero 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?

For a read-only suggestion tool with flat, fully-documented parameters and no output schema, the description covers the key bases: purpose, filters, output count, result quality, and intended scenario. It doesn't address pagination or determinism, but given the low complexity and strong annotations, those are minor omissions rather than critical gaps.

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% with rich inline details (e.g., region enums, maxStops recommendation, tripType examples), so the baseline is 3. The description's mention of 'regions, direction, and alliance preference' only restates what the schema already documents, adding no semantic value beyond it.

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 uses a specific verb-resource pairing ('Get suggested multi-stop flight routings') and names the key filters (regions, direction, alliance preference), clearly framing this as an inspiration/suggestion tool. 'Proven routing templates with bookability ratings' plus 'trip planning inspiration' differentiates it from siblings like route_validate or custom_route_build, which imply validation and precise construction respectively.

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 'Great for trip planning inspiration' implies a light-weight, idea-generation use case, and 'suggested' signals this isn't for precise booking. However, there are no explicit 'when not to use' rules or named alternatives among siblings like route_estimate or plan_route, so guidance remains implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and the description aligns, adding behavioral details like checking dead legs and warning about poison carriers, plus estimating bookability. This enriches context beyond the read-only flag without contradiction.

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 purpose, and every sentence adds value. It is concise and clear with no filler.

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 read-only validation tool with no output schema, the description adequately covers what it does, when to use it, and the checks performed. It hints at output via 'estimates bookability' but could be slightly more explicit about the result format, though 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?

The input schema covers all three parameters with 100% description coverage. The tool description does not add extra semantics beyond the schema, so it meets the baseline but no more.

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 validates a multi-city flight routing for feasibility, using the specific verb 'validate' and resource. It enumerates specific checks (alliance carrier rules, dead legs, poison carriers, bookability) that distinguish it from sibling routing and planning 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?

Provides explicit when-to-use guidance: 'Use this before building an itinerary to catch routing problems early.' It does not mention alternatives or when not to use, but the context is sufficient given sibling tools like plan_route and route_suggest.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses important behavioral traits beyond the annotations: it triggers a human consultant handoff, automatically runs plan_route, and requires the caller to first invoke without questionsAnswers to obtain the questionnaire. This adds meaningful context about side effects and prerequisites on top of readOnlyHint=false and openWorldHint=true.

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 dense but every sentence contributes: it states the core action, the automatic side effect, and the preconditions/usage flow. There is no filler or repetition of schema details; the length is justified by the tool's complexity.

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 tool with 13 parameters, no output schema, and notable side effects, the description covers the key invocation requirements, the consultant handoff, and the questionsAnswers prerequisite. A minor gap is that it does not mention what the response contains (e.g., trip ID or next steps), but the provided context is still sufficient for selecting and invoking 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?

Although schema coverage is 100%, the description adds valuable cross-parameter semantics: it clarifies the need for at least 2 IATA codes, a departure date for every leg, and explains the questionsAnswers flow ('call once without questionsAnswers to receive the current questions to ask'). This goes beyond the schema's individual property descriptions.

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: 'Submit the customer's trip to AirTreks — a human travel consultant takes over from there.' It further distinguishes this from sibling tools by mentioning the automatic plan_route integration and the consultant handoff, making the purpose specific and differentiated.

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: 'Use this when the customer is ready to get a real quote' and explains the two-step flow of calling once without questionsAnswers to get the current questions. It does not explicitly name alternatives to avoid, but the context is clear enough for an agent to select this tool appropriately.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.