Get ticket types and prices for a specific event (Wix Events). Pass the event slug from list_events. Returns ticket names, prices, sale status, and how many are left.
| Name | Required | Description | Default |
|---|---|---|---|
| event_slug | Yes | Event slug from list_events. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses that the tool is a read operation ('Get') and explicitly lists return values. Lacks details on authentication or rate limits, but for a simple query tool, this is adequate.
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 with no superfluous information. Every word serves a purpose: stating the action, source, and return data.
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 fully covers what it does, how to use it, and what it returns. No 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?
The only parameter 'event_slug' has 100% schema coverage with a description matching the tool's description. The description reiterates the schema, adding no new semantic value 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 retrieves ticket types and prices for a specific event, explicitly listing returned fields (names, prices, sale status, quantity left). It distinguishes from sibling tools like 'reserve_event_tickets' and 'rsvp_event' by focusing on data retrieval.
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 a clear prerequisite: pass the event slug from 'list_events'. This guides the user on required preparation. However, it does not explicitly state when not to use this tool (e.g., for purchasing tickets), but the context is clear given siblings.
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 domain (booking, store checkout, events, restaurant, etc.) with clear descriptions. No two tools have overlapping purposes; even similar actions like create_booking, create_checkout, and reserve_event_tickets are differentiated by their specific contexts.
All tools follow a consistent verb_noun pattern with underscores (e.g., get_availability, list_blog_posts, reserve_event_tickets). There is no mixing of conventions like camelCase, and verbs are predictable (get, list, create, search, submit, etc.).
With 28 tools, the count is slightly on the high side but justified by the broad scope covering a neighborhood directory with multiple features (places, events, movies, menus, bookings, forms, etc.). Each tool serves a clear purpose, though a few could be consolidated.
The tool surface is comprehensive for the server's purpose, covering search, details, bookings, events, movies, menus, blogs, FAQs, forms, and more. Minor gaps exist (e.g., no tool to cancel bookings or update reviews), but core workflows are well-covered.