Read Eventzilla events, tickets, orders, attendees and users; open or close ticket sales.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 11 tools
Each tool has a clearly distinct scope: retrieving a single entity by ID, listing a specific collection, or toggling sales. The get vs. list distinction is consistently clear across events, attendees, transactions, and users, so an agent can easily select the right tool.
All tools use the same eventzilla_ prefix and snake_case verb_noun pattern, such as eventzilla_get_event, eventzilla_list_event_attendees, and eventzilla_toggle_event_sales. There are no mixed naming conventions.
With 11 tools, the set is well-scoped for an Eventzilla integration focused on querying event data and toggling sales. Each tool covers a distinct resource or action without excessive fragmentation.
The tools cover read access well for events, attendees, transactions, users, ticket types, and categories, plus one sales toggle. However, they lack broader lifecycle operations such as creating/updating events, managing attendees, check-in actions, or refunds, leaving notable gaps for a full Eventzilla workflow.
One attendee by id: name, ticket type, barcode, check-in status, order reference, registration answers. GET /attendees/{attendeeid}.
| Name | Required | Description | Default |
|---|---|---|---|
| attendee_id | Yes | Eventzilla attendee id (the id field in eventzilla_list_event_attendees). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds useful context annotations cannot: the exact fields returned and the underlying endpoint GET /attendees/{attendeeid}, which is valuable given there is no output schema.
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 tight fragments with the resource and returned fields front-loaded and no filler. The trailing endpoint path is slightly redundant with the tool name but still delivers routing 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?
For a single-parameter read tool with no output schema, the description compensates well by listing the returned fields and the endpoint. Only the lack of explicit guidance on failure or unknown-id behavior keeps it from being fully 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 100% and the single attendee_id parameter is documented in the schema, including where to obtain it (the id field in eventzilla_list_event_attendees). The description says 'by id' but adds no format, range, or edge-case meaning beyond the schema, so baseline 3 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?
States a specific verb (get), resource (attendee), the identifying key (id), and enumerates exactly what is returned: name, ticket type, barcode, check-in status, order reference, registration answers. This clearly separates it from the sibling eventzilla_list_event_attendees, which returns many attendees.
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 singular 'one attendee by id' implies the single-record use case versus the list sibling, and the id is implicitly sourced from the list tool, but the description never explicitly states when to use this instead of eventzilla_list_event_attendees or what to do if the attendee is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One event by id: title, description, dates, time zone, venue, status, tickets sold/total, URL, categories. GET /events/{eventid}.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | Eventzilla event id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds real value with the returned field inventory (title, dates, venue, tickets sold/total, etc.) and the backing endpoint GET /events/{eventid}, which matters since there is no output schema.
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 tight sentences: purpose and return content first, endpoint second. No filler, and the most decision-relevant information is 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?
For a one-param get with rich annotations, the description is largely sufficient, especially as the returned-field list compensates for the absent output schema. Minor gaps remain (not-found/error behavior, auth requirements), but nothing critical is missing.
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 100%, so event_id is already documented in the schema. The description only restates 'by id' and adds no format, range, or acquisition guidance beyond the structured field; baseline 3 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?
States a specific verb and resource ('One event by id') and enumerates the returned fields, making it clearly the single-event counterpart to the eventzilla_list_events sibling. An agent can tell what it fetches without opening the schema.
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 'by id' phrasing implies you call it when you already have an event id, but there is no explicit when-to-use guidance and no mention of the list/search alternatives for when an id is unknown. Usage is only inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One transaction (order) by checkout id or order reference number: amount, ticket count, status, event date. Read-only. GET /transactions/{identifier}.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | Checkout id or order reference number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the 'Read-only' sentence is largely redundant. The description does add useful value with the returned field set (amount, ticket count, status, event date) and the underlying GET endpoint, partially compensating for the absent output schema.
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?
Front-loaded with the resource and key fields in one compact sentence, followed by brief supporting fragments. No padding, though the 'Read-only' clause duplicates the annotation.
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 single-parameter read tool with no output schema, the description supplies the returned fields an agent needs to interpret results, and the annotations carry the safety profile. Adequate, with only the missing sibling routing as a real gap.
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 100%, and the identifier's accepted forms (checkout id vs order reference number) are already documented in the schema. The description restates this without adding format, syntax, or validation detail beyond the 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 a specific verb and resource ('One transaction (order) by checkout id or order reference number') and enumerates the returned fields. It implicitly distinguishes itself from the sibling eventzilla_list_event_transactions by emphasizing a single record, though it never names that alternative.
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 single-record-by-identifier framing implies the lookup use case, but there is no explicit when-to-use guidance, no statement of when to prefer the list variant, and no prerequisites. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One organizer or sub-organizer by user id. GET /users/{userid}.
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes | Eventzilla user id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the REST endpoint mapping, which is mildly useful context, but says nothing about return payload, error cases, or permissions for a mutation-free read.
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 terse fragments with no filler, and the core scope (one organizer by id) is front-loaded before the endpoint. Slightly telegraphic, but nothing wasted.
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 single-parameter read tool with no output schema and annotations covering the safety profile, the description supplies enough to invoke correctly. It could note what distinguishes an organizer from a sub-organizer, but nothing essential is missing.
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 100% with the single user_id parameter documented as 'Eventzilla user id.' The description's 'by user id' merely restates the schema rather than adding format or constraint detail, so the baseline 3 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?
States a specific verb and resource (retrieve one organizer/sub-organizer) scoped by user id, and names the underlying endpoint GET /users/{userid}. It is clear what the tool does, though it does not explicitly contrast itself with siblings like eventzilla_list_users.
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 phrase 'One organizer... by user id' implies this is the single-record lookup versus the list variant, but no explicit when-to-use, prerequisites, or named alternative (e.g. list_users) is given. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the event categories (names to use as the category filter in eventzilla_list_events). GET /categories.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety and open-world profile is covered. The description adds only the underlying 'GET /categories' endpoint, and says nothing about return cardinality, ordering, or stability of category values. Modest added value on top of 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 compact clauses with no filler: purpose first, then the downstream usage, then the endpoint. Every element earns its place and nothing is buried.
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 trivial read-only lookup with full annotation coverage and no output schema, the description covers what it is and why an agent should call it. It could go slightly further by sketching the return shape (e.g., category names vs. ids) since no output schema exists, but the gap is minor.
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 tool takes zero parameters (empty object schema, 0 required), so there is nothing for the description to disambiguate; the baseline for a no-param tool applies. The description instead adds value by clarifying the semantics of the output values' intended use.
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 a specific verb+resource ('List the event categories') and immediately clarifies the purpose of the returned data: names to use as the category filter. This distinguishes it from every sibling, which all operate on events, attendees, users, or transactions rather than lookup enumerations.
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?
It explicitly routes the agent: the returned names are the values to pass into eventzilla_list_events' category filter, which is a genuine when-to-use signal tying it to a sibling. It does not, however, state any exclusions or prerequisites (e.g., whether a prior auth or event lookup is needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the attendees (registrations) of one event: name, ticket type, barcode, check-in status, order reference and answers to registration questions. The API returns the whole list in one reply (no paging). GET /events/{eventid}/attendees.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | Eventzilla event id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this read-only and non-destructive, so the bar is lower; the description adds genuine context by stating the API returns the whole list in one reply with no paging, which tells the agent not to expect pagination tokens. It also discloses the concrete return fields and the underlying endpoint.
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 tight sentences: the scope and returned fields lead, followed by the no-paging behavior and the endpoint. No filler or repetition of the title.
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 enumerating the returned fields and clarifying that no paging is involved, which is enough for an agent to call and interpret it. Only the relationship to the single-attendee and transaction siblings is left unaddressed.
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% for the single event_id parameter, so the schema already defines it as a positive integer Eventzilla event id. The description only implies that event_id selects the event and adds no format or lookup guidance beyond the 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?
Specific verb (List) plus resource (attendees/registrations) scoped to one event, and it enumerates the returned fields (name, ticket type, barcode, check-in status, order reference, question answers). This cleanly separates it from the singular sibling eventzilla_get_attendee.
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?
Usage is implied by 'of one event' and the required event_id, but the description never states when to prefer this over eventzilla_get_attendee or eventzilla_list_event_transactions, nor any prerequisite such as access to the event. Adequate but with a clear routing gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the events in the Eventzilla account: id, title, dates and times, venue, status, tickets sold and total, categories and the public URL. Use the id (and dateid) in the other tools. Filter by status and category name. GET /events.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Records per page, 1-100 (default 20). | |
| offset | No | Records to skip (default 0). Pass the previous reply's next_offset. | |
| status | No | Only events with this status. | |
| category | No | Only events in this category name (see eventzilla_list_categories). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the endpoint (GET /events) and the downstream-id hint, but says nothing about pagination behavior, ordering, or result limits beyond what the schema documents. Adding modestly on top of annotations merits a 3.
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 tight sentences plus an endpoint stamp. The returned-field list is front-loaded, the usage hint and filter hint follow, and no sentence is 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?
With no output schema, enumerating the returned fields is genuinely valuable and mostly covers the gap; annotations cover the safety profile. Paging semantics (next_offset, ordering) live only in the schema, so one small piece of context is left to the structured fields rather than the 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 description coverage is 100% and every parameter (limit, offset, status, category) is already documented in the schema. The description only restates the status/category filtering, adding no syntax, defaults, or format detail beyond the structured fields, so the baseline 3 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?
States a specific verb and resource ('List the events in the Eventzilla account') and enumerates exactly which fields come back (id, title, dates, venue, status, tickets sold, categories, public URL). That scope cleanly separates it from sibling readers like eventzilla_get_event or eventzilla_list_event_attendees.
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?
Gives real context: call it to obtain the id/dateid that other tools need, and to filter by status and category (with a pointer to eventzilla_list_categories for valid category names). It stops short of explicit when-not guidance or naming an alternative for single-event lookups, so it is clear context rather than full routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the orders (transactions) of one event: order reference, checkout id, date, amount, number of tickets and status. Read-only. GET /events/{eventid}/transactions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Records per page, 1-100 (default 20). | |
| offset | No | Records to skip (default 0). Pass the previous reply's next_offset. | |
| event_id | Yes | Eventzilla event id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, and the description's 'Read-only' simply repeats that. It adds the REST endpoint path, which is mild context, but says nothing about result volume, refunds/excluded statuses, or rate limits beyond the safety profile the annotations already supply.
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 substantive content is one front-loaded sentence with zero padding. The trailing 'Read-only. GET /events/{eventid}/transactions.' fragments are short but partly redundant with the annotations already shown to the agent.
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 usefully names the returned fields (order reference, checkout id, date, amount, ticket count, status), and pagination is fully covered by the schema. It omits sorting behavior and any note on which order statuses are included, so it is close to but not fully 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 100%: limit, offset (including the 'pass next_offset' pattern) and event_id are all documented in the schema itself. The description adds no parameter-level meaning, so the baseline of 3 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?
States a specific verb (List) plus resource (orders/transactions) scoped to 'one event', and enumerates the returned fields, so it is clearly distinct from eventzilla_get_transaction and eventzilla_list_event_attendees in substance. It never names a sibling explicitly, so it falls just short of the top mark.
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?
Usage is implied by the one-event scope: use this to enumerate an event's orders. There is no explicit when-to-use/when-not guidance and no pointer to the singular eventzilla_get_transaction for a single order, so an agent must infer the boundary itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the ticket types of one event: id, title, price, quantity, sales window and limits, plus its donation ticket options (donation_options). GET /events/{eventid}/tickets.
| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes | Eventzilla event id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered without the description repeating it. The description adds value beyond structured fields by enumerating what each ticket type contains (id, title, price, quantity, sales window/limits) and flagging the donation_options sub-structure, which matters because no output schema exists. It omits auth/rate-limit context, keeping it short of a 5.
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?
A single front-loaded sentence covering scope and return contents, followed by the endpoint. No filler, no redundancy with the title, and the most important information (what is listed, for which event) comes first.
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 carries the return-shape burden and does so by listing the fields each ticket type exposes, including donation_options. For a one-parameter read tool with annotations already covering safety, this is nearly complete; only pagination or empty-result behavior is unaddressed.
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% and there is only one parameter, whose description already defines it as the Eventzilla event id. The description confirms the mapping by naming the endpoint path /events/{eventid}/tickets but adds no extra semantics such as format, sourcing, or defaults, so baseline 3 is right.
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 a specific verb (List) and resource (ticket types) and scopes it to 'one event', which cleanly separates it from sibling list tools like eventzilla_list_events or eventzilla_list_event_attendees. The returned fields and the concrete endpoint make the operation 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?
The description implies the use case (enumerate the ticket options of a single event) and the required scoping by event, but gives no explicit when/when-not guidance or reference to related tools such as eventzilla_get_event or eventzilla_toggle_event_sales. A listing tool operating on one event is fairly self-evident, so implied usage is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the account's organizer and sub-organizer users: name, company, contact details, time zone, user type. GET /users.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Records per page, 1-100 (default 20). | |
| offset | No | Records to skip (default 0). Pass the previous reply's next_offset. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that this is a GET /users call returning a defined set of user fields, but says nothing about pagination behavior or result ordering beyond what the schema implies.
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?
A single compact sentence with the resource and returned fields front-loaded; the trailing 'GET /users' is mildly redundant but harmless. No wasted clauses.
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 read-only list tool with annotations covering safety, a fully described schema, and no output schema, the description is nearly sufficient — it discloses the field set returned. Only the pagination/alternative-tool guidance is missing.
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 100% with two fully documented parameters (limit 1-100 default 20, offset with next_offset chaining), so the schema carries the load. The description adds no parameter meaning beyond the endpoint reference.
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 a specific verb and resource ('List the account's organizer and sub-organizer users') and even enumerates the returned fields (name, company, contact details, time zone, user type), which pins down scope precisely. It does not explicitly distinguish itself from the singular sibling eventzilla_get_user, so it falls short of the 5 bar.
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 gives no when-to-use guidance, no exclusions, and never mentions the alternative eventzilla_get_user for fetching a single user. The use case (listing all account users) is only implied by the word 'List'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE: publish (status true) or unpublish (status false) ticket sales of one event. Unpublishing stops attendees from buying tickets on the event page; publishing starts public sales again. Existing orders are not touched and no money moves through this tool. Idempotent. POST /events/togglesales.
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | true = publish/open sales, false = unpublish/close sales. | |
| event_id | Yes | Eventzilla event id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations supply the safety profile (destructive, idempotent, open-world), and the description adds real blast-radius detail: existing orders are untouched, no money moves, and the effect on the public event page. Missing auth/permission requirements and any hint at the response, so not a 5. 'Idempotent' merely repeats idempotentHint.
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?
Four tight sentences, mutation mode front-loaded, no filler. The endpoint path (POST /events/togglesales) is the only marginally expendable element.
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 two-parameter toggle with full schema coverage and annotations, the description covers what changes, what is unaffected, and reversibility. It omits the return payload (no output schema exists) and any permission/credential context, which leaves a small gap.
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 baseline is 3, but the description goes beyond the schema's terse value mapping by explaining the observable consequence of each flag (sales stop vs. sales resume). It does not describe event_id semantics, which the schema already covers.
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 a specific verb pair (publish/unpublish) plus the exact resource and scope ('ticket sales of one event'), and prefixes it with 'WRITE:' so mutating intent is unambiguous. Siblings are all read/get/list tools, so this one is immediately distinguishable.
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 explains the two modes: unpublishing stops attendees from buying on the event page, publishing starts public sales again, giving clear when-to-use context for each status value. It does not name exclusions or alternatives, though no sibling performs anything comparable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage Eventbrite events, ticket classes, venues and discounts; read attendees, orders and reports.
Read Evenium events, guests, contacts and hotels; register guests and update contacts and statuses.
Event ticketing: create and publish events, read orders, attendees and sales analytics.
Read AddEvent calendars, events, RSVPs and subscribers; create and update calendars and events.
Add one secure layer between your agents and this server.