ATA Travel

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

Beyond the annotations, it discloses important behavior: consent must follow exact price/payment/cancellation terms, identity verification is not consent, host-approval enquiries may not require payment, and internal tool details should remain private during verification. It also states what the tool returns in each flow, which is substantial context for a write operation with no output 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 is front-loaded and the key consent and flow conditions follow in a logical order. It is dense and long, but most sentences carry useful decision or safety information for a complex booking tool.

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 complex, non-idempotent write tool with no output schema, the description covers the main behavioral, consent, verification, and outcome branches well. It is still incomplete on several of the 20 parameters and does not fully describe return values beyond payment/manual-payment next steps.

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 adds meaningful semantics for policyAcknowledged, guestCountry, travelerAssertion, and agentHandoffId, including required versus optional contexts. However, with 20 parameters and only 50% schema description coverage, many parameters such as propertyToken, roomId, dates, adults, children, internalAgentKey, bookingAssistance, and selectedRoomCount are not clarified in the description.

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 dual purpose: securing a reservation or creating a host-approval enquiry on behalf of a traveler. It distinguishes the two outcomes clearly, but does not explicitly name create_quote as the alternative for quote-only flows, leaving some sibling differentiation implicit.

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 gives clear conditions for the two flows: instant book plus ready payment creates an inventory-holding provisional booking, while disabled instant book or unready Stripe checkout creates an enquiry hold. It also explains when policyAcknowledged may be false, but does not explicitly route quote use cases to create_quote or list when not 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.

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

Annotations declare it is a non-read-only, non-destructive, non-idempotent open-world mutation. The description adds meaningful behavioral context beyond that: quotes do not hold inventory or guarantee availability, verification may be required, and internal tool details should be kept private. It doesn't describe error behavior or what a quote result contains, keeping it from 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?

Four sentences, front-loaded with the core purpose and prerequisites, then privacy guidance and the inventory caveat. Dense but each sentence carries useful information; 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 complex 18-parameter mutation with no output schema and only 39% schema coverage, the description covers the critical auth and non-binding semantics but leaves the majority of parameters and the response shape unaddressed. Adequate but with clear gaps an agent might need.

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 only 39% across 18 parameters, so the description must compensate. It clarifies the auth-related params (travelerAssertion, agentHandoffId) and required guest fields, but leaves many params (priceAudience, displayCurrency, selectedRoomCount, adults/children, dates) undocumented beyond the schema. Partial compensation for a low-coverage 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?

States a specific verb and resource ('Generate a non-binding reference quote for a traveler') and clarifies it is non-binding, which distinguishes it from create_provisional_booking. Clear enough that an agent understands the core operation, though it doesn't explicitly name the booking sibling it differs from.

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 prerequisites: guest name/email plus either a current travelerAssertion or a fresh approved agentHandoffId. It also clarifies the verification path and that quotes don't hold inventory, giving clear when-to-use context. It stops short of naming alternatives like create_provisional_booking.

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 mark it read-only and non-destructive, but the description adds beyond that: it requires an authentication path, returns specific booking data, cannot modify/cancel/pay/create holds, and warns not to misuse the confirmation code as a holdId. No contradiction with the annotations exists.

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?

Although seven sentences long, every sentence earns its place: purpose, prohibition, auth requirements, alternative routing, return contents, and sibling-tool warning. The main action is front-loaded and no filler is present.

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 there is no output schema and the tool has multiple authentication modes plus a sibling flow, the description is complete. It covers prerequisite inputs, expected return data, permitted and prohibited behaviors, and the specific alternative to use for stateless clients.

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 extra semantic context on top of the schema, such as 'Never invent a code,' the requirement of matching booking email and code, and the explicit handoff flow involving confirmationCode. It mostly reinforces and contextualizes schema descriptions rather than substantially extending them.

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 verb and resource: 'Read an existing booking by its ATA confirmation code.' It clearly differentiates from siblings by warning against using a confirmation code as holdId in get_reservation_status and by naming the alternative handoff flow.

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 gives explicit eligibility requirements (signed traveler assertion, verified MCP session, or approved BOOKING_READ handoff) and tells stateless third-party clients to use start_traveler_handoff with action BOOKING_READ then poll get_traveler_handoff_status. It also states what the tool cannot do, so an agent knows when to look elsewhere.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description still adds value by qualifying the entity as 'published' — implying unpublished buildings are not retrievable — and by naming what the response contains. It doesn't state error/not-found behavior explicitly.

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 tight sentences: the first declares the resource and its contents, the second declares the required input source. Nothing is redundant and the resource identity is front-loaded.

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 usefully previews the return shape (profile, assigned stays, coordinates), and it covers the only meaningful input. Minor gap: no mention of what happens when the slug is unknown or unpublished.

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 0% for two parameters, so the description must carry the load. It adequately explains where 'slug' comes from, but 'internalAgentKey' is left completely undefined in both schema and prose, leaving half the surface undocumented.

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 published ATA building/complex profile') and enumerates the payload contents (assigned stays, map coordinates). It's clearly distinct from search_buildings, though it doesn't explicitly contrast with the nearest sibling, get_property_details.

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?

'Use slug from search_buildings or property search results' gives an explicit prerequisite and points to the two upstream tools that produce the required identifier. There are no when-not-to-use conditions or notes about behavior for unpublished/unknown slugs.

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, idempotentHint, non-destructive, and openWorld, so the safety profile is fully covered. The description adds only that the content is 'published' (implying stable, canonical text) and roughly what is returned; it does not describe response format, freshness, or whether the mission and description are separate fields.

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, front-loaded with the capability and followed by the use case. Every sentence earns its place with no filler or restatement of the name.

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 read tool with a full annotation set, the description covers what is needed to select and call it. The only minor gap is that, with no output schema present, the description does not say whether the return is plain text or structured fields.

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 takes zero parameters, so the baseline is 4. No parameter explanation is required, and the description correctly spends no words on inputs.

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?

Names a specific verb ('Read') and a specific resource (ATA's published company mission and company description). No sibling among the booking/travel tools overlaps this content, so an agent can instantly tell it apart from the availability, quote, and traveler 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?

Explicitly states the trigger condition: 'Use for questions about ATA's purpose or services.' It gives clear context but offers no exclusions or alternative routing, which is acceptable since no sibling serves the same informational need.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real context beyond them: it enumerates the categories of data returned and clarifies the date-availability exclusion, which prevents a misinvocation. Missing only pagination/size hints, which with zero params is minor.

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, front-loaded with what is returned and only slight waste in the long field enumeration. The exclusion clause is placed after the usage clause where it belongs.

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 and no parameters, the description carries the return-shape burden and does so by listing the data categories. It is essentially complete for an agent deciding whether to call it; only the concrete response format remains unstated, which is acceptable for a summary 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 tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description's field list usefully sets expectations for the summary's contents instead of leaving them unstated.

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 ('Return a summary of ATA's current destinations, property types, capacity, amenities, views...'), which tells an agent exactly what comes back. It distinguishes itself from availability-search siblings only indirectly via the scope clause, and 'ATA' is unexplained jargon, so it falls short of a 5.

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 it ('when the traveler has not specified a property or destination') and adds a negative constraint ('Does not check availability for specific dates'), which implicitly routes to the search_network_availability family. It stops short of naming those alternatives, so 4 rather than 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 read-only, idempotent, non-destructive, open-world behavior, so the safety bar is pre-cleared. The description adds genuinely useful behavioral detail beyond that: previews are capped at two, missing previews fall back to retained links, and no dates are required — all things an agent could not infer from the annotation block.

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, no filler, with the resource scope front-loaded before the parameter-handling instruction. The first sentence is dense and slightly run-on with its long enumeration, but every clause carries information an agent needs.

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 two-parameter read tool with no output schema and annotations already covering the safety profile, the description covers resource scope, payload contents, edge-case behavior for missing previews, and the roomQuery convention. Nothing essential to calling it correctly is absent.

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 only 50%: roomQuery is well documented in-schema and reinforced by the description's traveler-wording rule, but propertyToken has no schema description at all. The description never explains where propertyToken comes from or its expected format, so it only partially compensates for the coverage gap.

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) with a clearly scoped resource (date-free property and room details) and enumerates the payload: amenities, direct-booking benefits, policies, Events & Weddings, room profiles, image links and previews. An agent can tell this apart from get_building_details and search_property_catalog by the 'date-free' framing and image preview contents, though no sibling is named explicitly.

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 gives one concrete conditional rule — pass traveler room wording as roomQuery before treating it as another property — and implies no stay dates are needed. However, it never states when to prefer this over get_building_details, search_property_catalog, or search_property_availability, so the broader routing decision is left to inference.

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 annotations (readOnlyHint=true, destructiveHint=false), the description adds meaningful behavioral detail: it names the required authentication/authorization paths, states that the tool returns 'stored prices and payment terms,' and explicitly clarifies that a quote is not a booking or inventory hold. This enriches the agent's mental model of the tool's state and side effects without contradicting any annotation.

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 dense sentences with zero filler: the first states the purpose and identifiers, the second enumerates auth prerequisites, and the third sets expectations about return values and limitation. Information is front-loaded and 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?

In the absence of an output schema, the description covers the main return type ('stored prices and payment terms') and all auth paths. It does not specify whether the three identifiers are mutually exclusive or what happens when multiple are provided, nor does it state a precedence order. For a 6-parameter tool with no required fields and no output schema, this is a minor but meaningful gap.

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?

With schema description coverage at only 50%, the description compensates by explaining that quoteId, quoteHash, and quoteUrl are interchangeable identifiers ('using its actual quoteId, quoteHash or quoteUrl'). It also clarifies that agentHandoffId must be a 'still-valid USED QUOTE handoff' and travelerAssertion must be 'current signed.' However, propertyToken remains undescribed in both schema and description, so compensation is incomplete.

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 ('Read'), resource ('previously created quote'), and the three accepted identifiers, immediately distinguishing it from sibling tools like create_quote and get_booking_details. The clarifying sentence 'A quote is not a booking or inventory hold' reinforces the differentiation. No ambiguity remains about what operation this tool performs.

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 the conditions under which the tool can be used ('Requires a current signed traveler assertion, verified legacy session, or the still-valid USED QUOTE handoff'), and warns against misuse ('never substitute another room's payment schedule'). It does not name sibling alternatives explicitly, but the caveat about quotes vs bookings implies when not to use it. Clear context with a minor exclusion makes this a 4.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description still adds real value by spelling out the authentication prerequisite and by explicitly enumerating the mutations it cannot perform (change, pay, cancel, check in, check out).

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 sentences, front-loaded with what is returned, then prerequisites, then scope limits. Zero filler and every sentence carries actionable 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?

With no output schema, the description correctly enumerates the returned payload (status, exact stay, price, payment schedule, cancellation terms) and covers auth requirements and mutation limits. The main gap is that it does not clarify how this differs from get_booking_details, which matters given the sibling list.

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 goes beyond the per-field schema text by clarifying the either/or relationship between travelerAssertion and agentHandoffId and by noting that the hold ID is required alongside that verified context, which helps an agent choose the right auth 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?

States a specific verb and resource: returns status plus stay, price, payment schedule, and cancellation terms for an ATA-created reservation. Clear on its own, but it never distinguishes itself from the close sibling get_booking_details, which an agent could easily confuse it with.

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?

Implies usage by scoping to reservations 'previously created through ATA' and by listing prerequisites (hold ID plus verified traveler context or booking handoff). It does not name an alternative or state when another tool should be preferred, leaving the get_booking_details boundary ambiguous.

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, openWorldHint, idempotentHint, and destructiveHint. The description adds minor context like 'published building' and filtering options, but does not elaborate on error handling, pagination, or what 'ATA stays' precisely means.

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?

Single sentence, no unnecessary words. Efficient but could be slightly more structured to separate purpose and optional filters.

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?

Lacks details on return format, error conditions, or behavior for missing buildings. With 8 parameters and no output schema, the description is too minimal to be fully complete for an AI 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?

Schema description coverage is low (13%), so the description must compensate. It mentions 'live dates' and 'guest counts' which map to checkIn/checkOut and adults/children, but ignores other parameters like priceAudience, displayCurrency, and internalAgentKey. Adds partial 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 action ('Return'), the resource ('ATA stays assigned to a published building'), and optional filters ('live dates and guest counts'). It effectively distinguishes this tool from siblings like search_buildings or search_property_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?

No explicit guidance on when to use this tool versus alternatives. The description implies it is for retrieving stays for a specific building, but does not mention when not to use it or suggest sibling tools for other scenarios.

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 goes beyond the readOnly and idempotent annotations by explicitly stating it 'does not send messages, create a case, or transfer the traveler to a person.' This fully discloses the non-destructive, side-effect-free behavior.

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, stating the main purpose first, then use cases, then key behavioral clarifications. Every sentence adds value without 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 simple retrieval tool with no output schema, the description adequately covers what the tool does, when to use it, and what it will not do. No missing information would prevent correct invocation.

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 only parameter, propertyToken, is described with its purpose and when it should be included. The schema coverage is 100%, and the description adds meaningful context about the traveler needing help from that property.

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 retrieves contact details for ATA support and optionally for a specific property. It distinguishes between the two modes and makes clear what resource is being accessed.

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 when to use it ('Use for human help, unanswered property questions, or booking support') and gives the key instruction to omit propertyToken for ATA support. It does not name alternative tools, but the use cases are specific enough for selection.

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 establish read-only, idempotent, non-destructive behavior, and the description adds concrete domain-specific exclusions: it does not send email, create a quote, or create a booking. It also signals that the response includes permitted next actions, though it omits auth/rate-limit 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?

Two compact sentences, front-loaded with the tool's purpose, followed by the required input source and key exclusions. No wasted language.

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 one-parameter read-only status tool with rich annotations, the description covers purpose, input source, and major side-effect boundaries. It could go slightly further in describing the shape of returned status/next-action data, especially since no output schema exists.

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%, and the single handoffId parameter is fully documented in the schema. The description repeats that the ID comes from start_traveler_handoff but adds no format or validation details 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?

States a specific verb and resource: it checks verification status and permitted next actions for an existing ATA traveler handoff. It distinguishes itself from start_traveler_handoff and from quote/booking creation, though it does not explicitly contrast with get_traveler_verification_status.

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 clear precondition context by instructing the agent to use the handoffId returned by start_traveler_handoff. It also clarifies that it does not send email or create a quote/booking, but it does not name alternatives for related status checks.

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, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds useful filtering context ('active' memories, 'verified traveler'), but it does not disclose what happens on failure, authentication requirements beyond the schema hint, or open-world variability.

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 filler. The primary function is front-loaded, and the usage guidance 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?

Given the annotations cover safety and the schema fully documents the parameters, the description is largely complete. It explains the return concept ('active structured memories') since there is no output schema, though it does not describe memory shape or pagination.

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 travelerId and travelerAssertion. The description's phrase 'verified traveler' loosely maps to travelerId but adds no new parameter-level meaning 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 names a specific verb ('Returns') and a specific resource ('active structured memories for a verified traveler'), so the tool's function is immediately clear. It also gives a use-case hint ('durable personalization beyond the context already provided') that helps distinguish it from related memory or traveler 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 description provides an explicit 'Use this when...' condition tied to needing durable personalization beyond current context. It does not name an alternative or state a clear when-not-to-use case, but the guidance is concrete enough for an agent to select the 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by explaining the consequence of a completed challenge, namely the private binding of the traveler to this MCP session. No contradiction with annotations exists.

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 tight sentences with no filler. The main purpose is front-loaded ('Check whether...'), and the additional binding context is compact and relevant.

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 one-parameter, read-only status check, the description provides enough context about what the challenge is and its scope. There is no output schema, so a slightly more explicit statement about the returned status shape would strengthen it, but this omission is minor given how straightforward the tool's purpose is.

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 0%, so the description must compensate, and it partially does by clarifying that the challenge is a code or email-link challenge within this session. However, it never explicitly says challengeRef is the identifier returned from start_traveler_verification or how to obtain it, leaving that connection implied rather than direct.

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 ('check whether') and names the exact resource: 'a code or email-link challenge started in this MCP session.' It clearly targets completion status and even explains what completion means ('binds the traveler privately'), distinguishing this from sibling tools like start_traveler_verification and verify_traveler_code.

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 useful scope ('started in this MCP session') but never explicitly says when to use this tool instead of a sibling or what steps should precede it. The workflow is implied rather than stated, so an agent must infer that this follows starting a challenge and that it is not for verifying codes or checking handoff status.

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 annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint:false. The description adds useful context beyond these by explaining the 'date-free' scope, the 'published on ATA' condition, and explicitly stating it 'does not create an order.' This goes beyond simply restating the 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?

Two sentences, no fluff. The first sentence states the primary function and scope; the second clarifies return details and non-mutation. Every phrase contributes to understanding without 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?

For a list tool with no output schema, the description adequately covers the return values (read-only details and ATA purchase links) and the key condition (published on ATA). It could mention pagination or sorting, but these are not critical for selection. The description is complete enough for an agent to decide when to call it.

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?

Input schema coverage is 67% (two of three parameters have descriptions). The description adds domain context like 'date-free' and 'for a known property,' which informally ties to parameters, but it does not explain the propertyToken parameter or any parameter-specific behavior beyond what is in the schema. The description is helpful but doesn't fully compensate for the missing 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 clearly identifies the verb 'List' and specific resources (date-free published events, services, etc.) for a known property, with scope indicated by 'for a known property' and non-mutating behavior stated. This distinguishes it from sibling tools like search_property_catalog, though it doesn't name alternatives explicitly.

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 when to use the tool (when you have a known property) and mentions a condition (when the property is published on ATA), but it does not reference any alternative tools or exclusionary criteria. There is no explicit 'when not to use' or naming of siblings, so the guidance is clear but incomplete.

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, idempotentHint, non-destructive behavior, and openWorldHint. The description adds useful behavior beyond that: the exact return value ('pong') and explicit assurance that it does not search properties or change quotes/bookings. It could mention latency or failure behavior, but the core behavioral profile is well covered.

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 short sentences with no waste. The core purpose and return value come first, followed by the most relevant exclusions for this tool set.

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 zero-parameter connectivity check with no output schema, the description supplies everything an agent needs: what it does, what it returns, and what it does not do. No further behavioral or parameter detail is required.

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?

There are zero parameters, so there is nothing for the description to document beyond what the empty schema already shows. The description appropriately avoids inventing parameters, and the baseline for a zero-parameter tool is a 4.

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: checks whether the ATA MCP server responds. It also names the exact return value ('pong') and explicitly distinguishes itself from property search and quote/booking mutation tools, so an agent can identify it without opening the schema.

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 makes clear this is a connectivity check and not a business-action tool by explicitly excluding property search and quote/booking changes. It does not spell out the exact diagnostic scenarios (e.g., before a retry after timeout), but the implied use case is unambiguous given the sibling tool set.

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 destructiveHint=false, so the description doesn't need to restate safety. It adds context about the data source ('published ATA building/complex profiles') but doesn't discuss any other behavioral traits like pagination or rate limits.

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, front-loaded with purpose and usage. No wasted words; the 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 lack of output schema and 6 parameters, the description is adequate for a search tool but could be more complete by mentioning what the response contains (e.g., building IDs, names) or any result limits.

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?

With only 17% schema description coverage, the description compensates by mapping search dimensions (destination, neighborhood, tag, amenity, free-text) to parameters, but it does not detail individual parameters or formats.

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 'Find' and the resource 'published ATA building/complex profiles' and lists multiple search dimensions. However, it doesn't explicitly differentiate from sibling tools like get_building_details or search_property_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 provides clear usage context ('Use this for questions about buildings...') but does not specify when not to use or mention alternative tools for specific functions, such as get_building_details for detailed info on a single building.

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 read-only, idempotent, open-world, non-destructive behavior, so the safety profile is covered. The description adds genuinely useful traits annotations cannot express: silent defaulting of dates, nights and adults, and the requirement to surface those defaults as explicit assumptions. It also discloses that ranking signals are soft rather than a closed taxonomy — behavior an agent could easily get wrong.

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 sentences, all front-loaded with the core action first and qualifications after. Minor friction: 'always return those defaults as explicit assumptions' is phrased as an instruction to the caller rather than as a description of tool behavior, but the density is appropriate for a 16-parameter tool.

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 16-parameter, zero-required, no-output-schema tool, the description covers the highest-risk ambiguities: default injection, soft vs. hard filtering, and search scope. It does not mention the maxResults cap of 6 or how mixed-currency pricing and priceAudience behave, but those are documented in the schema and are secondary to correct invocation.

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 88%, so the schema already documents nearly all 16 parameters, including the 28/56-day defaults and the defaults for nights and adults. The description mostly restates those defaults rather than adding syntax or interpretation; its only real addition is explaining that views, amenities, propertyType and preferences are soft ranking inputs, which the schema already hints at.

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: 'Search participating ATA properties for availability and prices across a flexible date window.' The word 'flexible' implicitly separates it from fixed-date siblings like search_network_availability and search_property_availability, but no sibling is named explicitly, so the distinction is inferred rather than stated.

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 traveler supplies a window rather than exact dates, and preferences are soft signals. There is no explicit 'use this when…' guidance and no reference to the alternative availability-search tools, leaving the agent to infer when this is preferred over search_network_availability or search_property_availability.

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 readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds only that pricing is real-time, which signals live/volatile data but says nothing about rate limits, result caps, pagination, or response shape. Useful but thin beyond what annotations provide.

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 short sentences with zero padding, and the core purpose leads before the usage condition. Could be marginally tighter, but every clause carries information an agent can act on.

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 16 parameters, a nested budget object and no output schema, the schema covers most of the parameter semantics well, but the description says nothing about result shape, result limits, or how to interpret ranked output. It also does not explain the relationship between the modern budget object and legacy maxPrice, leaving that entirely to the schema. Adequate but with clear gaps 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 88%, so the schema already carries the heavy lifting, including the nested budget object and the maxPrice/maxPriceCurrency legacy interaction. The description's mention of amenities, views, property type and keyword filtering merely restates filterable dimensions the schema documents in detail. 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?

States a specific verb and resource ('Find accommodations') plus scope ('across the ATA Travel Network with real-time pricing'). It implicitly separates itself from the flexible-dates sibling via 'Use when dates are known', but never names search_flexible_network_availability or search_property_availability, so differentiation is inferential rather than 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?

'Use when dates are known' gives a clear triggering condition and effectively rules out the flexible-search sibling without naming it. The note that free-text keyword 'handles vague requests' tells the agent how to proceed when the request is fuzzy. No explicit exclusions or named alternatives, which keeps it 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond them: no note on whether prices returned are native vs converted, whether results are live or cached, how budget filtering behaves, or what happens with priceAudience. Behavioral context is essentially absent.

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?

One front-loaded sentence with zero padding, which is good structurally, but it is under-specified rather than concise for a 9-parameter tool with a nested budget object. Nothing unearned, but too little is earned.

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, non-trivial search with a nested budget constraint and no output schema, the description omits the return shape, currency/basis expectations, and guest-count semantics. It leaves the agent to reconstruct intent from schema fragments alone.

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 only 56% and the description compensates only minimally by naming dates and occupancy. It says nothing about the budget object's basis/scope semantics, priceAudience, displayCurrency, adults/children defaults, or internalAgentKey, leaving several parameters explained only in the schema or not at all.

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 clear verb (search), resource (availability for a property) and scope qualifier ('known property using its propertyToken'), which separates it from the network-wide siblings search_network_availability and search_flexible_network_availability. It stops short of saying what is returned (rooms, rates, occupancy) or that it is date-range based.

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?

'a known property using its propertyToken' implies this tool is for properties already resolved via get_property_details/search_property_catalog, which hints at when to use it. There is no explicit when-not, no mention of the flexible/network siblings, and no prerequisite statement about obtaining the token.

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 establish read-only, idempotent, open-world, non-destructive behavior, so the bar is lower. The description adds the substantive behavioral fact that results are date- and price-agnostic, which prevents an agent from misreading the output as availability. No pagination or result-count behavior is described.

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 tight sentences; the scoping constraint and the negative capability check are front-loaded with no filler. Every clause carries information an agent needs before calling.

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 10-parameter, all-optional browse tool with strong annotations and 90% schema coverage, the description covers purpose and the key exclusion. The remaining gap is the soft-ranking behavior of 'preferences' versus the hard 'keyword' match, which is only explained in the schema, not the description.

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 90%, so the schema carries most parameter meaning. The description enumerates the filter dimensions (location, property type, amenities, views, keyword), which mirrors rather than extends the schema. It says nothing about maxResults, preferences (soft vs. hard matching), or adults/children occupancy effects.

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 ('Browse participating ATA properties') and immediately scopes it with 'without stay dates'. The filter list makes the catalog-search intent concrete. It doesn't name a sibling explicitly, but the 'no date-specific availability or prices' line clearly separates it from the availability-search siblings.

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 a clear usage context (browse when you have no stay dates) and an explicit exclusion (does not check date availability or prices). It stops short of naming the alternative tool an agent should switch to when dates/prices are needed, so it is not a full routing statement.

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 mutation and open-world behavior, and the description usefully adds that an email may be sent, that the traveler should only be told to check their inbox and click the ATA link, and that handoff/tool details must not be mentioned. It still does not fully describe what internal state is created or returned, but it adds valuable behavioral context beyond the 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 is short and front-loads the approval-step context before the operational instructions. Most sentences earn their place, though the purpose sentence could be more concrete.

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?

This is a complex 20-parameter mutation/handoff tool with no output schema, and the description does not explain return values, failure behavior, or action-specific outcomes. It provides workflow guidance but is not complete enough for an agent to call it confidently across the QUOTE, BOOKING_HOLD, and BOOKING_READ cases.

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 only 45% across 20 parameters, so the description needs to compensate. It only explains guestEmail and emailConfirmedByTraveler, leaving key required fields and action-specific parameters without added meaning in the description.

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 calls it an "Internal approval step for quote or booking tools," which gives a general domain but does not clearly state the concrete action (starting a traveler handoff) or distinguish it from siblings like start_traveler_verification and get_traveler_handoff_status.

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 gives a clear pre-call workflow: read guestEmail back to the traveler, confirm it, then set emailConfirmedByTraveler=true. However, it does not say when to use this instead of related tools such as start_traveler_verification or get_traveler_handoff_status.

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 annotations already declaring readOnlyHint=false and destructiveHint=false, the description adds useful context: it uses the property's configured verification method, is scoped to the MCP session, and explicitly has no booking/quote side effects. It still does not disclose whether it sends an email/SMS, what happens on repeated calls, or permission requirements.

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 tight sentences with the core action front-loaded, followed by the method source and a clarifying negative scope. No sentence is wasted.

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 an eight-parameter, non-idempotent write tool with no output schema, the description is thin: it omits what the call returns (e.g., a verification session or status), how method selection interacts with property configuration, and what the agent fields or phone are for. It covers the high-level purpose but not enough for correct invocation.

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 only 13% – just one of eight parameters is documented in the schema. The description only indirectly relates to guestEmail/emailConfirmedByTraveler via the confirmation precondition and does not explain the method enum values, agentName, guestPhone, agentProvider, or propertyToken. It leaves most parameter meaning to inference.

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 ('Start') and resource ('traveler verification'), scopes it to 'this MCP session', and explicitly distinguishes it from quote/enquiry/hold/booking creation. An agent can tell this apart from siblings like create_quote or verify_traveler_code without opening the schema.

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 states the key precondition ('after the traveler confirms their email address') and what it is not for ('does not create a quote, enquiry, hold, or booking'). It does not explicitly name the follow-up sibling (verify_traveler_code) or when to choose a specific verification method, so it stops short of full when/when-not routing.

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 adds 'durable' and confirms write/update semantics, which is consistent with readOnlyHint=false and idempotentHint=false. But it does not disclose return behavior, side effects, or the fact that the schema explicitly permits inferred memories, and the 'explicitly stated' restriction is potentially misleading.

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 short sentences with the core action front-loaded and no redundant phrasing. Every sentence adds essential selection or invocation context.

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 9 parameters, no output schema, and many sibling tools, the description is minimal but mostly adequate for selecting it. It is incomplete because it does not clarify upsert behavior, expected response, or how to handle the schema's INFERRED source option, leaving an internal inconsistency for the agent to resolve.

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 78%, so the schema already documents most parameters. The description itself adds no per-parameter detail, and its 'explicitly stated by the traveler' guidance may actually conflict with the source and confidence parameters that allow inferred input.

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 action ('Save or update') and the resource ('one durable traveler memory for personalization'), which is specific and distinguishable from read-only siblings like get_traveler_memories. It also clarifies the arguably ambiguous tool name 'suggest_traveler_memory' by indicating it is actually a persistence operation.

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 'Use only for stable, travel-relevant preferences or constraints explicitly stated by the traveler' provides a useful eligibility rule. However, it does not mention alternatives such as get_traveler_memories, and it conflicts with the schema's support for source='INFERRED' and confidence guidance for inferred patterns, making the usage boundary inconsistent.

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 mark this as a mutation (readOnlyHint=false) and non-destructive. The description adds valuable behavioral detail: 'On success, ATA privately binds the verified traveler to this MCP session; no reusable bearer credential is returned.' This explains the side effect (session binding) and the absence of a token, which is critical for an agent. However, it does not describe failure behavior or what happens if the code is invalid, so it's not fully transparent.

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 fluff. The primary action and side effect are front-loaded, and the security note about no bearer token is a single concise sentence. Every word contributes to understanding.

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?

This is a mutation with no output schema, so the description should ideally mention what is returned or emitted. It notes that no reusable credential is returned, implying a success indication, but does not specify the return format or error conditions. The flow context (part of traveler verification) is partially covered via the session-bound challenge, but the agent lacks guidance on failure handling and expected response, leaving some 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?

With schema description coverage at 0%, the description must compensate for parameter meanings. It does connect challengeRef to 'a challenge started in this MCP session' and identifies code as 'six-digit,' which aligns with the schema patterns. But it does not explain how to obtain the challengeRef, what constitutes a valid code beyond the pattern, or error semantics. The added context is helpful but minimal for a 0% coverage scenario.

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 action: 'Consume the six-digit code for a challenge started in this MCP session.' It names the specific resource (challenge) and the context (this session), and clarifies the outcome (binds traveler to session). This distinguishes it from sibling tools like start_traveler_verification and get_traveler_verification_status by focusing on the code consumption step.

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 that this tool is used after a challenge is started in the same MCP session, which selects it from the verification flow. However, it does not explicitly state when to use it versus alternatives (e.g., 'after start_traveler_verification') or when not to use it. The context is clear but exclusions are absent, leaving some inference to the agent.

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