ATA Travel

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

Annotations indicate write, non-deterministic, not idempotent, not destructive. Description adds significant context: if instant book and payment ready, returns payment steps; otherwise creates enquiry. Also mentions inventory consumption and host approval process. No contradictions.

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?

Description is relatively lengthy but packed with useful information. Front-loaded with purpose. No wasted text, but could be slightly more concise.

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?

Covers main flow and parameter hints for a complex tool (17 params, no output schema). Explains success behavior and what not to misinterpret. Missing details on return values, error scenarios, and some parameters like priceAudience, internalAgentKey, travelerAssertion.

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 35%, with 17 parameters. Description adds guidance for key parameters like using defaultRoomId and defaultRatePlanId from search results, and collecting guestName/guestEmail. However, many parameters (adults, checkIn, checkOut, children, guestPhone, etc.) lack explanation, partially compensating but not fully.

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?

Description clearly states the tool secures a reservation or creates a host-approval enquiry, and distinguishes between instant book enabled vs disabled scenarios. It differentiates from sibling tools like create_quote by focusing on booking.

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 (securing reservation on behalf of traveler) and prerequisites (requires guest name and email). Also warns not to misinterpret same-date availability drop after success. Lacks explicit when-not alternatives.

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 annotations (non-readOnly, openWorld), the description details exact side effects: saves snapshot, creates lead, emails link, and clarifies it does not hold inventory. No contradictions 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?

Six sentences with no wasted words. Front-loaded purpose, then side effects, prerequisites, mapping advice, and return. Well-structured and efficient.

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?

Covers purpose, side effects, prerequisites, mapping, and return type. Missing guidance on optional parameters like priceAudience or agentHandoffId, but sufficient for core usage given no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning for key parameters (guestName, guestEmail, roomId, ratePlanId) with usage guidance. However, with 31% schema coverage, many parameters (e.g., checkIn, adults, propertyToken) lack elaboration, relying on schema names.

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 generates a non-binding reference quote, distinguishing it from a booking. It specifies side effects (price snapshot, lead capture, email) and prerequisites (guest name/email).

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 (generate a quote), what it does not do (hold inventory/guarantee), and prerequisites. It implies the alternative create_provisional_booking for binding bookings but does not name it explicitly.

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 value beyond annotations by detailing the content of the response (assigned stays and map coordinates). It is consistent with annotations and provides a clear picture of the tool's 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 extremely concise: two sentences with no filler. The first sentence covers purpose and return, the second gives usage context. Every statement earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one parameter and no output schema, the description is sufficient to select and invoke the tool correctly. It could be slightly improved by noting that the tool is read-only (though annotations cover this), but overall it is complete enough.

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 0% schema description coverage, the description does not add meaning beyond the schema for the 'slug' parameter. It only mentions the source of the slug but lacks details on format, constraints, or examples, leaving the agent to infer from context.

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 'Get' and the resource 'ATA building/complex profile', and explicitly lists what is returned (assigned stays and map coordinates). It distinguishes from siblings by specifying the source of the slug, making it clear when to use this tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises to use a slug from 'search_buildings or property search results', providing clear context on how to obtain the required input. However, it does not explicitly mention when not to use this tool or suggest alternatives from the sibling list.

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 provide safety profile (readOnly, idempotent, not destructive). Description adds context on exact output (mission and description), but no further behavioral details needed.

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, front-loaded with action. No wasted words.

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?

Simple tool with no output schema; description explains return value. Complete for its purpose.

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?

No parameters; baseline 4 per rubric. Description appropriately omits param info as none exist.

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?

Description uses specific verb 'Returns' and clearly identifies resource 'ATA company mission and description'. Distinguishes from siblings as no other tool provides company info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to call: when user asks about ATA, what we do, vision, or company. Provides clear context for use.

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 indicate readOnlyHint=true, idempotent, non-destructive. Description adds specific behavioral details about the response (image gallery, room images, links), which is useful context beyond 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?

One concise sentence covering purpose, content, and parameter usage. Could be slightly more structured but is efficient and 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?

For a simple retrieval tool with one parameter, annotations, and no output schema, the description adequately covers purpose, parameter source, and expected response contents. Lacks some detail on response format but is 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?

Single parameter 'propertyToken' has 0% schema coverage, but description explains its origin ('from search results'), compensating and adding meaning beyond the schema's type-only definition.

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?

Description clearly states it gets detailed property information including image gallery, room images, and links. Distinguishes from siblings like get_building_details and search_buildings.

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 'Use propertyToken from search results', providing clear context for when to use this tool. Does not mention alternatives or when not to use, but usage is well implied.

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 non-destructive. The description adds the fact that it returns stays tied to a published building with optional filters, which is consistent but not significantly beyond 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?

Single sentence, 15 words, no redundancy. All information is front-loaded and justified.

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 good annotations and concise purpose, the description lacks details on return format, meaning of 'ATA', edge cases, and how to properly use the 8 parameters. For a tool with no output schema and low parameter coverage, this is insufficient.

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% (one parameter described). The description hints at date and guest count filters, partially compensating, but does not explain critical parameters like slug, priceAudience, internalAgentKey, or the enum values.

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 'Return' and resource 'ATA stays assigned to a published building'. It clearly states the main action and scope. While 'ATA' is undefined, the overall purpose is clear and distinct from siblings like get_building_details and search_buildings.

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 guidance on when to use this tool versus alternatives. The description mentions optional filtering but does not compare to other tools like search_property_availability or mention prerequisites (e.g., building must be published).

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, destructiveHint. Description adds context about checking traveler verification and ATA approval, which is useful beyond 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?

Single sentence, front-loaded with purpose, no wasted words.

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?

Adequate for a simple status-check tool with one parameter and good annotations. Could specify output format, but not essential.

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 has 1 parameter with description 'ID returned by start_traveler_handoff'. Description doesn't add extra meaning; schema coverage is 100%, baseline 3.

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?

Description clearly states it checks traveler verification and approval of ATA action, with specific verb 'get' and resource 'traveler handoff status'. Distinguishes from sibling 'start_traveler_handoff'.

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 'use this when an agent has started a traveler handoff', providing clear context. Does not mention when not to use or alternatives, but the condition is well-defined.

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, and non-destructive behavior. The description adds no further behavioral details beyond the action itself, missing context about data format, performance, or authentication 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?

The description is two sentences, front-loaded with the purpose, and contains no unnecessary words. Every sentence serves a clear function.

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 tool with one parameter and no output schema, the description covers the essential purpose and usage context. It could mention output structure but is sufficient given annotations and sibling differentiation.

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 has 100% coverage with a description for 'travelerId'. The tool description does not add any additional parameter information beyond what the schema already provides, so it meets the baseline but adds no extra 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 returns 'active structured memories for a verified traveler', using a specific verb and resource. It is distinct from siblings like 'suggest_traveler_memory' which suggests memories rather than retrieving them.

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 'Use this when you need durable personalization beyond the context already provided', providing clear when-to-use guidance. It does not explicitly state when not to use or list alternatives, but the context is sufficient.

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 fully cover behavioral traits (readOnlyHint, idempotentHint, etc.). The description adds no new behavioral context beyond stating it is simple, which is acceptable given that annotations are rich and not contradicted.

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 a single sentence with no extraneous information. It is highly concise and 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?

Given zero parameters and comprehensive annotations, the description is largely complete for a ping tool. However, mentioning expected return value (e.g., 'pong') would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the description does not need to add parameter details. Baseline score of 4 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 states it is a 'simple ping tool', clearly indicating a connectivity test. The verb 'ping' and resource 'tool' are specific, and it is easily distinguishable from sibling tools that perform data operations.

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 when-to-use or alternative guidance is provided. Usage is implied by the name 'ping' (check connectivity), but the description does not clarify when it should be used over other tools.

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 openWorldHint. The description adds context about searchable dimensions (destination, neighborhood, tag, amenity, free-text). However, it does not describe behavior like result ordering or pagination. With annotations covering safety and idempotency, a 3 is appropriate.

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 contains no extraneous information. Every sentence adds value.

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 search nature, the description covers the key search dimensions and usage context. Annotations provide behavioral safety. However, absence of output schema and lack of detail on result format or pagination slightly reduce completeness. Still, it is sufficient for an agent to select and invoke 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?

Schema coverage is low (17%: only 'query' has a description). The description partially compensates by listing search dimensions (destination, neighborhood, tag, amenity, free-text) that map to parameters. However, it does not detail parameter format or constraints, and missing descriptions for 'city', 'tags', 'amenities', 'neighborhood', and 'maxResults' reduce clarity.

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 search criteria. It distinguishes from siblings by specifying use for buildings, complexes, neighborhoods, etc., which are not covered by other 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 explicitly says 'Use this for questions about buildings...' and lists example use cases. It provides clear context for when to use the tool, though it does not explicitly mention when not to use it or list specific alternatives.

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 real-time pricing and filtering capabilities, which enhance transparency without contradicting 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 concise sentences effectively convey purpose and usage. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 14 parameters and no output schema, the description covers key behavioral aspects and filtering options. It could mention return format, but overall it is complete enough.

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 86% schema coverage, most parameters are already described. The description lists a few filter types but does not add significant 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 clearly states the verb 'find' and resource 'accommodations across the ATA Travel Network', distinguishing it from sibling tools 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?

It explicitly says 'Use when dates are known', providing a clear condition. It does not mention alternatives or exclusions, but the context is clear.

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 destructiveHint, so the description's minimal addition of 'Search specific dates and occupancy' does not provide extra behavioral context beyond what annotations offer.

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 a single concise sentence with no wasted words, but could be slightly more informative without losing conciseness.

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 8 parameters, no output schema, and no description of return values, the description is too sparse for a moderately complex tool. Missing guidance on output format or behavior.

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 50%, but the description adds no parameter-level detail. It does not compensate for undocumented parameters like adults, children, or priceAudience.

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 searches availability for a known property using its propertyToken, distinguishing it from sibling tools like search_buildings and 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 implies usage when a propertyToken is known but does not explicitly mention when not to use it or suggest alternatives like search_property_catalog for unknown properties.

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, destructiveHint=false. The description adds that it is 'Fast, lightweight' and explicitly says 'no availability or pricing check,' which complements the annotations by clarifying the behavioral scope 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?

Two concise sentences covering purpose, key differentiator (no dates), and use cases. No wasted words; each 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?

Given the tool has no output schema and 6 parameters, the description is adequate for a catalog browse tool. It lacks explicit mention of output format or pagination, but the 'maxResults' parameter implies common search behavior. Overall, it provides sufficient context for an agent to use 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?

Schema description coverage is 100%, so the schema already documents all 6 parameters with descriptions. The description does not add new semantic details about parameters; it only provides context for the tool's overall purpose. Baseline score of 3 is appropriate as the description adds marginal value over 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 'Browse the ATA property catalog' and emphasizes 'without needing dates', distinguishing it from siblings like search_property_availability which require dates. It specifies the resource (ATA property catalog) and the specific use case (vague exploration, no dates).

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 states when to use: 'for vague exploration, browsing by type/amenity/view, or when the traveler has no dates yet.' It also implies when not to use by saying 'no availability or pricing check,' though it does not explicitly name alternative tools for those needs.

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 key side effect (sends verification email) and output (handoff ID for polling). Annotations indicate write operation (readOnlyHint=false) and no destructive action; description aligns with annotations and adds context about the email and polling mechanism.

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 most critical information (when to use) and followed by the mechanism. No redundant or unnecessary words.

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 18 parameters and no output schema, the description leaves many details unspecified (e.g., parameter relationships, error scenarios). Annotations partially compensate, but the tool is complex and the description is too brief for complete coverage.

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%, and the description adds no parameter-level details beyond what's in the schema. Many parameters (e.g., adults, roomId, checkIn) are left undocumented. The description does not compensate for the low coverage, making it hard for an agent to understand which parameters matter for different actions.

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?

Description clearly states the tool's purpose: to initiate a traveler verification/approval handoff before booking or payment steps. It uses specific verbs (verify, approve) and distinguishes from sibling tools like create_provisional_booking by specifying it is a prerequisite 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?

Explicitly states when to use (before inventory-holding actions) and implies when not to (after those steps). While alternatives are not named, the context is clear enough for an agent to decide.

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 indicate this is a non-read-only (write) and non-destructive operation. The description adds value by specifying 'durable' (lasting) and limiting use to explicitly stated preferences, which gives the agent clear behavioral constraints. It does not contradict any annotations and adds meaningful context about the memory's persistence and scope.

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 extremely concise—two sentences that precisely convey the tool's purpose and usage constraints. No unnecessary words or redundant information. It earns its place efficiently.

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 has 8 parameters, 5 required, and no output schema, the description covers the essential aspects: what to store (preferences/constraints) and the conditions for use (stable, explicit). It does not detail the return value or update semantics, but the absence of output schema makes this acceptable. The presence of a read sibling (get_traveler_memories) further contextualizes its role.

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 already describes all 8 parameters with clear descriptions (e.g., key enum, value format). The tool description does not add additional parameter-specific semantics beyond the schema, so it relies on the existing high coverage. Baseline of 3 is appropriate as the description offers no extra parameter guidance.

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 ('durable traveler memory') with a specific purpose ('for personalization'). It distinguishes from the sibling tool 'get_traveler_memories' by focusing on writing, and is sufficiently specific to avoid confusion with other write tools like 'create_provisional_booking'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: 'Use only for stable, travel-relevant preferences or constraints explicitly stated by the traveler.' This tells the agent when to use the tool (for explicit, stable memories) but does not explicitly exclude alternative tools or state when not to use it. The guideline is helpful but lacks explicit exclusionary language.

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