Event Escapes

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

Annotations already declare readOnlyHint and idempotentHint. The description adds that it is a navigation aid, optionally pins a hotel, and does not make a reservation. This provides sufficient behavioral 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?

Two sentences with no waste. The core purpose is front-loaded, and each sentence adds essential information. Perfectly 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?

Given the tool's simplicity (URL generation) and full annotation/schema coverage, the description is complete. It explains the landing page experience, optional hotel pinning, and distinguishes from sibling 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?

All parameters have schema descriptions (100% coverage). The description adds extra meaning: hotel_id pins a recommended hotel, check_in/check_out pre-fill dates, and gives explicit guidance on guests (ask user, no default). This significantly aids correct usage.

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 generates a deep link to an event detail page, specifying what the user sees and distinguishing it from build_package_link. The verb 'Generate' and resource 'deep link to the Event Escapes event detail page' are specific and unambiguous.

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 this tool and provides a clear alternative: 'For curated packages, use build_package_link instead.' Also clarifies what it does not do ('This does NOT make a reservation'), guiding correct invocation.

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 indicate readOnly=true and no destruction. Description adds that link navigates to a page where user reviews and books, providing behavioral 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?

Three sentences, no redundancy. Front-loaded with purpose and key constraint (no reservation). Every sentence earns its place.

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

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

Given no output schema, description covers purpose, usage context, and limitations. Lacks specifics about link format but sufficient for typical use.

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. Description adds guidance that slug and package_id come from search_packages results and instructs to ask user before passing guests, adding value 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?

Clear verb 'Generate a deep link' and resource 'PACKAGE detail page'. Specifies target URL path (/packages/{slug}). Distinguishes from sibling build_event_link.

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 use after search_packages and clarifies it does not make a reservation. Provides sequential context but does not name alternative tools for when not to 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, destructiveHint=false, and idempotentHint=true. The description adds value by listing return fields but doesn't provide further behavioral context beyond what annotations convey.

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 deliver purpose and input guidance efficiently, front-loading the most critical information with 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?

No output schema exists, so the description appropriately lists return fields. The parameter explanation covers most inputs, though the currency parameter is omitted. Overall sufficient for a simple read 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?

With 0% schema description coverage, the description explains event_id and slug (and their origin from search_events), but fails to mention the currency parameter, which is optional but has a predefined enum. This partial coverage leaves some ambiguity.

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 retrieves full details for one event, listing specific fields like title, venue, date/time, price range, description, and image gallery. This distinguishes it from sibling tools like search_events, which list multiple events.

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 tells the agent to provide an event_id or slug from search_events results, establishing a clear usage pattern. It does not explicitly mention when not to use it, but the context of retrieving one event is 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 indicate read-only, idempotent behavior. The description adds that it returns raw event inventory (tickets only) and prices are estimates, providing useful behavioral 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?

The description is a single paragraph with front-loaded purpose, covering scope, filters, and a sibling alternative. Every sentence adds value with no redundancy.

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

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

The description covers scope, filters, and price estimates, which is sufficient for a search tool. It could mention pagination or response format, but annotations supply safety info, making it fairly complete.

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

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

Schema description coverage is 0%, so the description must compensate. It lists filterable parameters (sport, city, country, date range) but does not explain each parameter's semantics, format, or constraints beyond what the schema provides.

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

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

The description clearly states the tool searches for upcoming sporting and music events bookable on Event Escapes, lists covered sports, and explicitly distinguishes from the sibling tool search_packages, ensuring no confusion.

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 when to use this tool (for raw events) and when to use search_packages (for curated packages). It could be improved by mentioning what not to use it for, 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, etc. Description adds useful output details: 'Returns activity name, price, duration, image, and whether free cancellation is offered.' No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences. First sentence covers purpose and source. Second sentence covers default behavior and return fields. 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?

Covers purpose, default, and return fields but lacks parameter details and guidance for sibling differentiation. Acceptable for a simple search tool but not complete given 7 parameters and sibling 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 has 7 parameters with 0% description coverage. Description only hints at 'city' and 'date range' (for date_from/date_to), leaving parameters like limit, country, category, and currency unexplained. Does not compensate for lack of 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?

Description clearly states verb 'Find' and resource 'activities, tours, attractions, food experiences, and nightlife' sourced from Hotelbeds. It distinguishes from sibling tools like search_events and search_hotels_near_event by focusing on experiences, but does not explicitly contrast with 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?

Provides default date range behavior ('If no date range provided, defaults to next 7 days') but lacks guidance on when to use this tool versus siblings. No explicit when-to-use or when-not-to-use information.

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 (readOnlyHint, idempotentHint), the description details return fields (nightly price, total cost, distance, transport mode, travel time) and default date logic. This fully discloses behavioral traits and output content.

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 concise sentences. The first states the purpose, the second explains defaults and returns. Every sentence adds value without redundancy.

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

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

Given 8 parameters and no output schema, the description covers purpose, defaults, and return fields but omits the required condition (event_id or slug) and does not specify output structure (e.g., array). Some gaps remain for a fully complete context.

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 coverage, the description adds meaning for check_in and check_out (default behavior) but does not explain other parameters (slug, limit, guests, currency, radius_km) or the required condition (event_id or slug). Coverage is partial.

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 finds hotels near an event venue, specifying proximity modes (walking/short-transit). It distinguishes itself from sibling tools like search_events or search_experiences by focusing on hotel search relative to an event.

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 explains default behavior for check_in/check_out dates when omitted, aiding correct usage. While it does not explicitly compare to siblings, the tool name and context make its intended use clear. No explicit when-not or alternative tool references are given.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds valuable behavioral context: packages are hand-curated, live on dedicated pages, include preview components, and prices are all-inclusive. 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?

The description is two well-structured sentences, front-loaded with the core purpose and content of packages. The second sentence efficiently lists filter options and usage advice. Every sentence adds value with 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?

Given 8 optional parameters, 50% schema coverage, and no output schema, the description adequately covers what packages contain, filtering options, and when to use the tool. It lacks details on output structure (e.g., returned fields) and limit/date behaviors, but the tool's read-only nature reduces the need for extensive behavioral disclosure.

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% with several parameters lacking descriptions (limit, currency, date_to, date_from). The description reinforces filtering options but does not add new semantic details for undocumented parameters. It provides context for category values with usage hints (e.g., 'concerts (1000+ packages)'), but overall adds minimal value 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 verb 'Search' and the specific resource 'hand-curated trip packages bundling event tickets + hotel + experiences'. It explicitly distinguishes from sibling 'search_events' by stating 'For raw event inventory only, use search_events', which meets the standard for specificity and sibling differentiation.

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

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

The description provides clear usage context: 'Use this when the user wants a complete trip recommendation' and explicitly names an alternative tool. However, it does not cover when to use other siblings like 'search_experiences' or 'search_hotels_near_event', leaving some ambiguity for related use cases.

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