voyager-commerce

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

No annotations provided, so description carries full burden. Adds endpoint-specific behavioral context (venue-specific connection handling). Missing: idempotencyKey behavior explanation, whether adding existing product increments quantity or replaces, and failure modes.

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 efficient sentences. First establishes purpose immediately; second provides critical parameter guidance. No filler or redundant exposition beyond the venueId repetition from schema.

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?

Minimal viable completion for a 7-parameter mutation tool. With 100% schema coverage, basic needs are met. However, lacks workflow context (prerequisite create_cart relationship), output behavior, and idempotency contract explanation expected when annotations are 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 100%, establishing baseline 3. Description duplicates the venueId parameter guidance already present in schema ('Omit when...') without adding syntax examples, format constraints, or semantic clarification for idempotencyKey, date, or timeSlot parameters.

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?

Clear specific verb ('Add') and resource ('product to the shopping cart'). Distinguishes from sibling create_cart (which creates the cart container) and remove_from_cart/remove_from_cart (which remove items).

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

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

Provides explicit guidance on venueId parameter omission ('when connected to a venue-specific endpoint'). Lacks explicit contrast with update_cart (when to add vs update quantity) and doesn't explicitly state prerequisite create_cart call, though implied by cartId requirement.

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 no annotations provided, the description carries full behavioral disclosure burden but only states the basic action. It mentions an idempotencyKey parameter but fails to explain idempotency behavior, error conditions for invalid codes, or whether this overwrites existing promotions.

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 with zero waste: first establishes purpose, second provides critical parameter guidance. No redundant information or lengthy prose.

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 basic invocation but insufficient for a financial mutation operation: missing output expectations, error handling for invalid/expired codes, stackability with existing discounts, and idempotency behavior explanation given the presence of an idempotencyKey parameter.

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 100% schema coverage (baseline 3), the description adds valuable usage context for venueId ('Omit when connected to a venue-specific endpoint') that explains conditional parameter omission logic not evident in the schema alone.

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 the specific action ('Apply'), resource ('promotional code'), target ('cart'), and outcome ('discount'), clearly distinguishing this from sibling tools like add_to_cart or get_cart that handle items rather than discounts.

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

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

Provides explicit parameter-level guidance ('Omit venueId when connected to a venue-specific endpoint'), but lacks broader workflow guidance such as when to apply promo codes relative to checkout initiation or prerequisites like cart existence.

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 are absent, so description carries full burden. 'Real-time' adds valuable behavioral context (fresh vs cached data), but lacks disclosure on idempotency, rate limits, or what 'unavailable' responses look like.

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 with zero waste. Purpose is front-loaded, followed by specific parameter guidance. Appropriate length for the complexity.

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

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

Adequate for triggering the tool, but with no output schema and no annotations, it omits what the availability result contains (boolean, inventory count, time slots?) and how it relates to the add_to_cart flow.

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% with detailed parameter descriptions. Description adds minimal semantic value beyond schema, merely restating the venueId omission rule already present in the parameter 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?

Clear verb 'Check' with specific resource 'availability' and scope 'real-time'/'specific date'. Distinguishes from cart/order management siblings by focusing on inventory verification before purchase.

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

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

Provides specific instruction for venueId parameter ('Omit when connected to a venue-specific endpoint'), but lacks guidance on when to use versus 'get_pricing' or relationship to booking flow.

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?

No annotations provided, so description carries full burden. Fails to disclose critical creation behaviors: whether it supersedes existing carts, what it returns, idempotency guarantees (despite having idempotencyKey parameter), or side effects on session state.

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, zero waste. First sentence establishes purpose; second provides specific parameter constraint. Appropriately front-loaded with no filler.

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

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

Adequate for a 5-parameter creation tool with complete schema coverage, but gaps remain regarding output behavior (no output schema present) and cart lifecycle management. Minimum viable for a resource creation operation.

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

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

Schema coverage is 100%, establishing baseline 3. Description adds 'for this session' context linking to sessionId, but the venueId omission rule duplicates schema description. No additional semantics provided for currency, customerId, or idempotencyKey implications.

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?

Excellent specific verb ('Create') + resource ('shopping cart') + scope ('for this session'). Clearly distinguishes from siblings like get_cart (read), update_cart (modify), and add_to_cart (add items to existing cart).

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

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

Provides specific parameter guidance ('Omit venueId when connected to a venue-specific endpoint'), but lacks explicit when-to-use guidance relative to siblings (e.g., whether to check get_cart first) or prerequisites for cart creation.

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 no annotations provided, the description carries the full burden of behavioral disclosure but fails to explain what the search returns (full records vs. IDs vs. names), pagination behavior, rate limits, or whether results are cached. It only states the search domain without describing behavioral traits like search fuzziness or availability checking logic.

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 single sentence is efficiently structured with the action front-loaded and specific venue type examples included to constrain scope without verbosity. No words are wasted, though the brevity comes at the cost of behavioral detail that would require additional sentences.

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

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

Given the simple search semantics and comprehensive input schema, the description is minimally adequate, but gaps remain regarding the output structure and behavioral characteristics. Without an output schema, the description should ideally indicate what venue information is returned (e.g., IDs, names, capacities) to enable effective chaining to 'get_venue_details'.

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

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

The schema has 100% coverage with well-documented parameters, establishing a baseline of 3. The description adds minimal semantic value beyond the schema, though 'near a location' loosely contextualizes the relationship between the 'location' and 'radiusMiles' parameters. It does not explain parameter interactions (e.g., how 'date' filters availability) or provide syntax examples beyond what the schema offers.

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 provides a clear verb ('Search') and specific resource examples ('venues, theme parks, zoos, museums, and attractions'), establishing the scope effectively. However, it does not explicitly differentiate from the sibling tool 'search_experiences', leaving ambiguity about whether this tool finds physical locations while the sibling finds events/activities.

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?

While the phrase 'near a location' implies geographic search capability, the description provides no explicit guidance on when to use this tool versus alternatives like 'search_experiences' or 'get_venue_details'. There are no exclusions, prerequisites, or workflow positioning hints provided.

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 no annotations provided, the description carries the full disclosure burden. It implies read-only nature via 'Get' and adds valuable endpoint-specific context for venueId, but omits error handling (e.g., invalid cartId), return payload details, or confirmation of idempotency.

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. First states purpose; second provides parameter guidance. Zero waste. Front-loaded structure puts the action before the condition.

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?

Appropriate for low complexity (2 simple params, 100% schema coverage, no nesting). However, with no output schema and no annotations, 'current state' is vague regarding what data (items, pricing, totals?) is returned.

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%, establishing baseline 3. The description repeats the venueId omission guidance verbatim from the schema ('Omit when connected to a venue-specific endpoint'), adding no new semantic information beyond what the parameter descriptions already provide.

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?

Specific verb 'Get' + resource 'shopping cart' + scope 'current state' clearly defines the retrieval operation. The verb distinguishes appropriately from sibling mutation tools like create_cart, add_to_cart, and update_cart.

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

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

Provides explicit instruction 'Omit venueId when connected to a venue-specific endpoint,' which clarifies conditional parameter usage based on connection context. Lacks explicit sibling comparison (e.g., 'use this instead of create_cart when retrieving existing').

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?

Zero annotations provided, so description carries full burden. 'Secure' implies HTTPS but description omits critical behavioral traits: whether the URL expires, if cart gets locked/reserved, required authentication, or what the return value structure is.

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 with zero waste. Front-loaded with core purpose ('Generate...'), followed by specific constraint. Every word earns its place.

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

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

Insufficient for a checkout operation with no output schema and no annotations. Missing: URL expiration details, cart modification behavior, distinction from initiate_checkout, and return format 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 has 100% coverage so baseline is 3. Description duplicates the venueId schema guidance but importantly adds context about 'venue-specific endpoint' connection logic, providing slight value beyond the structured 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 specific action (Generate) and resource (secure checkout URL) clearly. Names the target (cart). However, fails to differentiate from sibling tool 'initiate_checkout' which likely overlaps in functionality.

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

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

Provides specific parameter guidance ('Omit venueId when connected to a venue-specific endpoint') but lacks explicit when-to-use guidance versus the similar 'initiate_checkout' sibling, and doesn't clarify prerequisites like cart state requirements.

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?

No annotations provided, so description carries full burden. Mentions 'authenticated' (disclosing auth requirement) and 'active' (indicating filtered results), but omits output structure details, pagination behavior, or empty-state handling.

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 focused sentences with zero redundancy. Front-loaded with the action and resource, followed immediately by the critical usage constraint regarding venueId.

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 2-parameter read operation with full schema coverage. Covers the essential domain context (venue-specific endpoints, authentication). Could be improved with output format hints or differentiation from similar entitlement-listing siblings.

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%, establishing baseline 3. The description repeats the venueId constraint already present in the schema description without adding syntax examples or cross-parameter dependencies. The 'active' qualifier in the first sentence loosely maps to the activeOnly parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verb 'Get' and enumerates three distinct resource types (tickets, passes, entitlements), clearly distinguishing this from sibling tools like get_cart (shopping session) or get_orders (purchase history). The 'authenticated customer' qualifier establishes the security context.

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

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

Provides specific parameter guidance ('Omit venueId when connected to a venue-specific endpoint'), but lacks explicit comparison to siblings. Does not clarify when to use this versus get_orders or get_membership for viewing customer assets.

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 no annotations provided, the description carries the full disclosure burden. It correctly notes the 'authenticated customer' requirement and indicates the return data (status and benefits), but omits details about error handling (e.g., what happens if customer has no membership), caching, or rate limiting.

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 efficient sentences with zero waste. The first sentence front-loads the purpose, and the second provides specific parameter guidance. Every word earns its place.

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

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

Adequate for a simple single-parameter tool. It conceptually explains the return value (membership status/benefits) despite lacking an output schema. Could be improved by defining what 'membership' encompasses (loyalty tiers, points, subscription status) to distinguish from entitlements.

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%, with the venueId parameter fully documented. The description repeats the venueId guidance already present in the schema description rather than adding new semantic context (such as example endpoint formats or validation rules). Baseline score applies.

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 provides a specific verb ('Get') and clear resource ('authenticated customer's membership status and benefits'). It distinguishes from siblings like get_entitlements (specific access rights) and get_orders (purchase history) by focusing specifically on membership tier/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?

The description includes explicit parameter guidance ('Omit venueId when connected to a venue-specific endpoint'), which helps with invocation. However, it lacks guidance on when to use this versus similar tools like get_entitlements or how it fits in the booking workflow.

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?

Mentions 'authenticated customer' implying auth requirements, but with no annotations provided, the description carries the full burden of behavioral disclosure. Missing: pagination behavior (beyond limit), sort order of history, what fields/data structure returns, and error conditions.

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 with zero waste: first establishes purpose, second provides critical parameter guidance. Front-loaded and appropriately sized for the tool's complexity.

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

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

With 100% schema coverage and only 3 simple parameters, the description adequately covers inputs. However, lacking an output schema, the description omits what the order history contains (fields, nesting, format), which is necessary context for a retrieval tool.

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

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

Schema has 100% coverage establishing a baseline of 3. The description adds valuable contextual guidance for venueId ('Omit when connected to a venue-specific endpoint') that clarifies the relationship between the parameter and endpoint context, exceeding the schema's basic 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?

Clear verb-object structure ('Get authenticated customer's order history') with specific scope ('at a venue'). The term 'history' effectively distinguishes this from sibling get_order_status (single order status check) and get_cart (current session). However, it doesn't explicitly contrast with these alternatives.

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

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

Provides specific parameter guidance ('Omit venueId when connected to a venue-specific endpoint') that helps with invocation. However, lacks guidance on when to use this versus get_order_status or get_cart, or prerequisites like authentication requirements.

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 no annotations provided, the description carries full disclosure burden. It explains the venue-specific endpoint behavior but omits other critical behavioral details like what status values to expect, whether the check is real-time, caching behavior, or error conditions.

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?

Extremely efficient two-sentence structure. First sentence establishes purpose, second provides specific usage constraint. Zero wasted words, properly 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?

Adequate for a simple two-parameter tool with 100% schema coverage. Covers the primary usage quirk (venueId omission). However, given lack of annotations and output schema, it could benefit from clarifying how this differs from the plural 'get_orders' sibling.

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 schema already documents both parameters. The description reinforces the venueId omission rule already present in the schema description without adding significant new semantic context like format examples or conditional requirements.

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 specific verb (check) and resource (order status) clearly. However, it fails to distinguish from sibling tool 'get_orders' (plural), which likely retrieves multiple orders versus checking status of a specific one.

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

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

Provides specific guidance on venueId parameter usage ('Omit venueId when connected to a venue-specific endpoint'), but lacks explicit comparison to alternative tools like 'get_orders' or guidance on when to check status versus initiate checkout.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'dynamic pricing' and 'discounts' implying calculated, variable output, but fails to disclose safety properties (idempotent? cached?), rate limits, or authentication requirements expected for a pricing API.

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 tightly constructed sentences with zero redundancy. The first sentence establishes purpose and return value; the second provides a critical constraint. Information is appropriately 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 7 parameters with full schema coverage but no output schema, the description partially compensates by mentioning 'guest type breakdown' (hinting at return structure). However, it omits expected response format details (currency, total vs. per-person pricing structure) and prerequisite workflow steps that would aid agent selection.

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%, establishing a baseline of 3. The description repeats the venueId constraint already present in the schema without adding new semantic context (e.g., date format expectations, promoCode validation rules). No additional parameter guidance is provided beyond the 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 states the tool 'Get[s] dynamic pricing for a product' with specific details about what is returned ('guest type breakdown and discounts'), matching the high schema coverage. It implicitly distinguishes from siblings like check_availability and get_cart by focusing on pre-cart product pricing, though it could be more explicit about workflow sequencing.

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

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

Provides specific guidance on venueId parameter usage ('Omit venueId when connected to a venue-specific endpoint'), but lacks broader workflow context. It does not explicitly state when to use this vs. check_availability or that it should be called after search_experiences (though the schema notes productId comes from search_experiences).

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?

No annotations provided, so description carries full disclosure burden. Mentions return categories (location, type, attributes) but omits mutation safety, rate limits, auth requirements, or cache behavior. Indicates read-only nature implicitly via 'Get' but lacks explicit behavioral traits.

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 efficient sentences with no filler. First defines purpose and return payload, second provides parameter guidance. Every word earns its place; appropriately 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?

Adequate for a single-parameter tool with no output schema, covering the parameter behavior and basic return structure. However, notable gap in distinguishing from sibling venue tools (get_venue_info) given the crowded namespace.

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 has 100% description coverage for the single tenantId parameter. Description repeats the schema's guidance about omitting tenantId for venue-specific endpoints without adding new semantic context such as valid UUID formats or relationship to discover_venues.

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 specific verb (Get) and resource (venue details) with concrete field examples (location, type, attributes). However, fails to differentiate from sibling tools get_venue_info and get_venue_hours, which is critical given the similar naming.

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

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

Provides implementation instruction about tenantId omission when connected to 'venue-specific endpoint' but lacks guidance on when to choose this tool versus alternatives like get_venue_info or discover_venues. No explicit when-not-to-use or prerequisites.

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?

No annotations are provided, so the description carries the full disclosure burden. It successfully explains the endpoint-specific behavior regarding tenantId omission, but does not describe the return format (since no output schema exists), error conditions, or whether hours include special/holiday schedules.

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 with zero waste. The first establishes purpose; the second provides critical parameter guidance. Every word earns its place and the structure is appropriately 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 the simple 2-parameter input schema with 100% coverage and lack of output schema, the description is minimally adequate. It covers the primary use case and the tenantId caveat, but could improve by hinting at the return structure (e.g., opening/closing times) since no output schema exists to document 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?

With 100% schema description coverage, the baseline is 3. The description frames the operation as retrieving 'operating hours' (adding semantic context), but largely paraphrases the schema rather than adding syntax details or format examples beyond what the schema already documents.

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), resource (venue operating hours), and constraint (specific date). However, it does not explicitly differentiate from sibling tools like get_venue_details or get_venue_info, which also retrieve venue information.

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

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

Provides specific parameter-level guidance ('Omit tenantId when connected to a venue-specific endpoint'), but lacks explicit tool-level guidance on when to use this versus alternatives like get_venue_details or check_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?

No annotations provided, so description carries full burden. It discloses the tenantId omission behavior and implies read-only nature via 'Get', but lacks details on error handling (e.g., invalid venue ID), caching, or rate limits that would fully compensate for missing 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?

Extremely efficient two-sentence structure. First sentence establishes purpose and return value categories; second sentence provides critical parameter usage guidance. Zero redundancy, front-loaded 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?

Appropriately complete for a simple read operation with 100% schema coverage. Describes return data categories (compensating for missing output schema) and covers the primary behavioral quirk (tenantId omission). Could improve by addressing error states or sibling relationships.

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 has 100% description coverage, establishing baseline 3. The description repeats the tenantId omission rule already present in schema and implies the inclusion flags control scope, but adds no syntax details or format specifications beyond 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 specific action (Get) and resource (venue information) with clear scope (hours, policies, FAQ). However, it lacks explicit differentiation from siblings 'get_venue_details' and 'get_venue_hours', though the content list provides implicit distinction.

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

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

Provides specific guidance on when to omit the tenantId parameter (venue-specific endpoints), but fails to address when to use this tool versus siblings like get_venue_details or get_venue_hours, leaving selection criteria partially 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what the tool returns (URL or payment flow) and notes the dependency on operator config, but fails to disclose side effects (e.g., whether this creates a checkout session, reserves inventory, or has idempotency requirements) critical for a financial operation.

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 core action and return value, followed by a specific parameter constraint. Every word earns its place with no redundancy or 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?

Given this is a 7-parameter checkout tool with no output schema and no annotations, the description is minimally sufficient but incomplete. It explains the return type generally but omits crucial details about the checkout lifecycle, error conditions, or the nature of the 'platform payment flow'.

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% description coverage, establishing a baseline of 3. The description repeats the `venueId` usage constraint already present in the schema but adds no additional semantic context for other parameters like `platform` (valid values) or `idempotencyKey` (purpose beyond the name).

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 the tool initiates checkout and returns either a checkout URL or platform payment flow based on operator configuration. This specific return behavior distinguishes it from the sibling `get_checkout_url`, though it could more explicitly clarify the distinction between initiating vs. retrieving a checkout.

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 specific guidance on when to omit the `venueId` parameter (when connected to a venue-specific endpoint), which is helpful. However, it lacks broader workflow context, such as when to use this versus `get_checkout_url` or prerequisites like requiring a created cart.

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?

No annotations are provided, so the description carries full behavioral disclosure burden. While 'Remove' implies mutation/deletion, the description lacks critical details: it doesn't disclose whether the operation is reversible, what it returns (updated cart vs. boolean), potential errors (item not found), or authorization 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?

Two sentences with zero waste: front-loaded with the core action, followed immediately by critical endpoint-specific parameter guidance. No redundant or generic text.

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 3-parameter mutation tool with complete schema documentation, but gaps remain concerning output behavior (no output schema provided), error handling, and side effects of the deletion operation that would help an agent invoke and respond to 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?

Input schema has 100% description coverage (cartId, venueId, lineItemId all documented). The description text duplicates the venueId constraint already present in the schema but adds no new semantic details about parameter formats, valid values, or relationships between parameters (e.g., that lineItemId must exist within the specified cartId).

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 ('Remove') with clear resource ('an item from the cart'), directly mapping to the tool name. It distinguishes from siblings like add_to_cart (opposite action), get_cart (read vs. write), and update_cart (partial modification vs. removal).

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

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

Provides specific operational guidance for the venueId parameter ('Omit when connected to a venue-specific endpoint'), but lacks explicit guidance on when to choose this tool over siblings like update_cart (e.g., when deletion is preferred over quantity adjustment) or prerequisites 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?

No annotations provided, so description carries full disclosure burden. It documents the conditional venueId requirement well, but omits behavioral details like empty query handling, result ranking logic, or pagination behavior (despite having a limit parameter).

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 efficient sentences with zero waste. Purpose is front-loaded in the first sentence; the second sentence provides essential parameter guidance. No redundant or filler content.

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 rich schema coverage (100%) and no output schema, the description adequately covers the search intent. However, it could improve by hinting at return values (e.g., 'returns matching experiences') or connecting to the purchase flow suggested by sibling cart/checkout tools.

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% with clear descriptions for all 6 parameters. The description mentions 'natural language' and the venueId omission rule, but both are already present in the schema descriptions verbatim. With high schema coverage, baseline 3 is appropriate as the description adds no new parameter semantics.

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 verb (search), resources (tickets, experiences, products), scope (at a venue), and method (natural language). It effectively distinguishes from siblings like discover_venues (which finds venues, not inventory) and check_availability (which verifies specific 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?

Provides explicit guidance on venueId parameter omission ('Omit venueId when connected to a venue-specific endpoint'). However, lacks explicit differentiation from siblings like check_availability or guidance on when to search vs. go directly to cart operations.

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 zero annotations, the description carries full behavioral disclosure burden but fails to explain side effects (e.g., price recalculation), error conditions (invalid lineItemId), return values, or whether the operation is atomic. Only states the input intent, not the execution 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?

Two sentences with zero waste. Front-loaded with the action ('Update the quantity'), followed immediately by the critical venueId constraint. Every word earns its place.

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

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

Adequate for a simple CRUD-like operation with robust schema documentation, but insufficient for the cart workflow complexity implied by 15+ sibling tools. Missing output expectations and inter-tool orchestration guidance that would help an agent navigate the checkout flow.

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%, meeting baseline expectations. Description duplicates the venueId constraint already present in the schema property description without adding syntax details, validation rules, or clarifying the unusual default UUID for lineItemId.

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?

Clear verb-resource pair ('Update the quantity' + 'in the cart') defines the core operation. Accurately scopes the tool to modifying existing line items, implicitly distinguishing from add_to_cart. However, it doesn't clarify the overlap with remove_from_cart (which quantity=0 achieves per schema) or when to prefer the dedicated removal 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?

Provides one specific constraint ('Omit venueId when connected to a venue-specific endpoint'), but lacks broader guidance on when to use this versus add_to_cart or the dedicated remove_from_cart sibling. No mention of prerequisites like cart existence or line item validity.

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