Get full details for one event: title, venue, date and time, price range, description, and image gallery. Provide event_id (UUID) or slug from search_events results.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | ||
| currency | No | ||
| event_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, which cover safety and side effects. The description adds value by disclosing what return fields the tool provides, which is not in annotations. It doesn't contradict annotations, and while it doesn't discuss error behavior, the read-only nature and idempotency reduce the need. The added return-content detail goes beyond annotations, so a 4 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 the core action and data scope, immediately followed by identifier instructions. Every word earns its place—no filler, no repetition of the title or annotations. This is an exemplary concise structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing the key return fields (title, venue, date/time, price range, description, image gallery), which sets expectations for the response. It also clarifies the required identifiers. It doesn't cover currency or potential errors, but for a simple read-only lookup with strong annotations, the description is largely complete. A 4 reflects the minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions on properties), so the description carries the burden. It explains event_id and slug, including that they are alternatives (via 'or') and that slug comes from search_events, which is helpful. However, it entirely omits the 'currency' parameter, which is part of the schema with an enum. This partial coverage leaves a clear gap, so a 3 is fair.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get full details for one event' and enumerates the specific fields returned (title, venue, date/time, price range, description, image gallery). This differentiates it from sibling tools like search_events (which lists events) and build_event_link (which builds links). The verb 'get' plus the resource 'full details for one event' make a specific and unambiguous purpose.
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 instructs to provide either event_id (UUID) or slug from search_events results, giving clear context on how to obtain valid inputs. It doesn't explicitly state when not to use this tool or name alternatives, but the guidance 'from search_events results' implies a workflow and distinguishes from searching. This is clear context without formal exclusions, meriting a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource or action: events, packages, experiences, hotels, and link building for events vs packages. The descriptions explicitly cross-reference to prevent confusion, such as 'Use build_package_link instead' and 'use search_packages instead'.
All tool names follow a consistent verb_noun snake_case pattern: build_event_link, build_package_link, get_event_details, search_events, search_experiences, search_hotels_near_event, search_packages. The verbs (build, get, search) are used predictably.
Seven tools is well within the ideal 3-15 range for a domain. Each tool serves a distinct purpose in the event/package discovery and link-generation workflow, with no redundancy or unnecessary additions.
The tool set covers the core workflows: searching events, getting event details, searching hotels and experiences, searching packages, and generating links for both events and packages. A minor gap is the lack of a get_package_details tool to retrieve package details programmatically, but agents can work around it by sending users to the package page.
