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?
No annotations are provided, so the description must cover behavioral traits. It explains the tool returns ticket names, prices, sale status, and remaining count. However, it does not disclose error handling (e.g., invalid slug), idempotency, or any required permissions. For a read-only operation, this is minimally adequate but could be more thorough.
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 consists of two concise sentences. The first states the core functionality, and the second explains the prerequisite and return data. No extraneous information is included.
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 one parameter and no output schema or annotations, the description covers purpose, input, and output sufficiently. It omits edge cases like error responses or rate limits, but for a simple read tool, this is acceptable.
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 provides a description for the sole parameter (event_slug: 'Event slug from list_events.'). The description reinforces this by saying 'Pass the event slug from list_events,' adding no new semantic value. With 100% schema coverage, the baseline is 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?
The description clearly states the tool's function: 'Get ticket types and prices for a specific event (Wix Events).' It identifies the resource (event tickets), the action (get), and the domain (Wix Events). This distinguishes it from sibling tools like list_events (which lists events) and reserve_event_tickets (which reserves tickets).
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 a clear prerequisite: 'Pass the event slug from list_events.' This instructs the user to first retrieve the slug using the list_events tool. While it doesn't explicitly state when not to use this tool or offer alternative tools, the context is sufficient for correct usage.
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 action and resource: booking appointments, restaurant reservations, event tickets, searches, etc. No two tools have overlapping purposes; even similar actions like create_booking and request_reservation are for different domains (appointments vs. restaurant tables).
All tools follow a consistent verb_noun pattern using lowercase and underscores (e.g., get_availability, list_events, create_booking). There is no mixing of styles like camelCase or inconsistent verbs.
28 tools is above the typical well-scoped range but each tool serves a clear purpose within the comprehensive neighborhood directory domain. The count feels justified, though slightly heavy.
The tool set covers most major features of a neighborhood directory: places, events, booking, restaurant menus, reviews, forms, etc. Minor gaps exist, such as no create_review or update operations, but core workflows are complete.