tito

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

Annotations only provide destructiveHint=true, so the description carries most of the burden. It usefully discloses that creation is effectively reversible via update (quantity/end_at) and gives the underlying API path, but omits auth/permission requirements, error behavior, and what happens on duplicate codes.

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 front-loaded sentences with no filler; the type explanation comes before the undo hint and the raw API path. The 'Tito: POST /:account/:event/discount_codes' line is marginally useful for debugging but is the weakest sentence.

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 13-parameter mutation tool with no output schema, the description covers purpose, type semantics, and the undo path, but says nothing about what is returned (e.g. the created code/id) or the permission/scope needed, which an agent needs before committing a write.

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 adds meaning beyond the schema: it ties value units to the type ('value = percent' vs 'flat amount off per ticket, in the event currency'), and the currency qualifier is not present in the schema text.

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 ('Create a discount code for an event') and immediately clarifies the domain-specific type enum semantics, which is the main ambiguity for a caller. It also names the sibling tool used to reverse the action, so an agent can distinguish this create from the update/delete paths.

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 routes the agent to tito_update_discount_code for undoing changes ('Undo by editing it (e.g. quantity or end_at)'), which is real when-to-use-this-vs-alternative guidance. It falls short of a 5 because it gives no prerequisites (auth/scope) or when-not-to-use conditions.

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?

With only destructiveHint=true in annotations, the description carries substantial extra weight: it warns that this creates a real ticket that consumes release capacity and that the only undo is voiding it in the Tito dashboard. That is exactly the consequence framing an agent needs before invoking an irreversible mutation.

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 tight sentences with the purpose and its non-obvious consequence front-loaded; the trailing API endpoint line is mildly extraneous but cheap and informative. Nothing is padded.

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 create tool with 11 parameters, no output schema, and a nested metadata object, the description covers outcome, side effect on capacity, and reversal path. The remaining gap is what registration/ticket data comes back, which is a minor omission given the schema is fully documented.

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%, including the naming of required release_id and event_slug, so the schema already explains every parameter. The description adds scoping context (issuing from a release) but no field-level syntax or defaults, 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 (issue) and resource (ticket) with the precise distinction that matters: it creates a manual registration without a checkout. That contrast with the normal purchase flow, plus the named use cases (speaker, sponsor, comp), makes it unmistakable against siblings like tito_create_discount_code or tito_get_ticket.

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 clear positive context ('without a checkout — e.g. a speaker, sponsor or comp ticket'), which tells the agent when this tool is appropriate. It stops short of naming alternatives or exclusions (e.g. directing normal paid purchases elsewhere), so it is clear but not fully routing.

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?

The readOnlyHint annotation already declares this a safe read, so the safety profile is covered. The description adds that the response includes usage count, a modest value-add, but says nothing about not-found behavior or auth/permission requirements.

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, front-loaded with the action and the lookup key; the trailing endpoint reference is compact and informative. No redundant or filler content.

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 single-resource fetch with annotations covering safety and a fully documented schema, the description supplies enough for correct invocation. It could mention not-found handling, 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%, so the schema already documents event_slug, account_slug, and discount_code_id with examples. The description only echoes that the id is numeric, adding no new meaning, so the baseline 3 is appropriate.

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?

State a specific verb (fetch), resource (a single discount code), and lookup key (numeric id), plus an extra detail about the returned usage count. This clearly separates it from the sibling tito_list_discount_codes, which is plural and unfiltered.

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?

Phrasing 'Fetch a single discount code by its numeric id' implies this is the lookup-by-id path versus the list sibling, but no when-to-use, prerequisites, or named alternative is stated. Usage is left to inference.

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, so the safety profile is covered. The description adds that releases and event metadata are returned, which is useful context, but says nothing about permissions, pagination, or rate limits 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?

Two sentences, front-loaded with purpose and the field inventory. The trailing 'Tito: GET /:account/:event' endpoint reference is mildly redundant but short and aids mapping to the underlying API.

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 (title, description, dates, time zone, location, currency, live/test_mode, releases), which is what an agent needs. It could note auth requirements for the token, but overall it is complete for this 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?

Schema description coverage is 100%, so both event_slug and account_slug are already well documented with examples and the TITO_ACCOUNT fallback. The description only restates 'by slug' and adds no format or fallback detail beyond the schema, 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 ('Fetch a single event by slug') and enumerates the returned fields, so an agent can tell it apart from the sibling list tool tito_list_events. The scope (one event, keyed by slug) is 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?

Usage is implied by 'single event by slug' versus the list-oriented siblings, but the description never states when to prefer this over tito_list_events or tito_get_release, nor any prerequisites. Adequate but leaves routing to inference.

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?

readOnlyHint=true already establishes the safe-read profile, so the description is not carrying that burden. It adds meaningful behavioral context by naming the exact payload contents (tickets, receipts, refunds, line items, billing address, payment details) and the underlying GET endpoint, telling the agent this is a rich single-object fetch with no side effects.

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 that front-load the operation and its return contents. The trailing API-endpoint mapping is marginally redundant given the tool name and schema, but it is short and aids cross-referencing with the upstream API.

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 registration payload contents, and readOnlyHint covers safety. For a simple 3-parameter read tool this is essentially complete, though it omits any note on error cases (e.g. unknown slug) or auth scoping beyond the schema.

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 all three parameters are already documented in the schema, including slug formats and the optional account_slug fallback. The description restates the slug example ('reg_...') but adds no syntax or semantics 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 and resource ('Fetch a single registration (order) by slug') and enumerates the returned sub-resources (tickets, receipts, refunds, line items, billing address, payment details). This clearly separates it from the sibling tito_list_registrations, which returns many.

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 'single registration by slug' versus the list sibling, and the required slug format signals when it applies. However, there is no explicit when-to-use/when-not guidance or named alternative, so routing is left to inference.

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, so the safety profile is covered. The description goes beyond that by disclosing the response contents (pricing, capacity, sales counts broken down by type, questions, activities), which is valuable since no output schema exists. It stops short of error/auth/pagination behavior, so not 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?

Front-loaded with the action and resource, followed by a compact enumeration of returned data and the endpoint mapping. It is dense but earns most of its words; the endpoint suffix is marginally redundant.

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 tool with no output schema, the description usefully covers the return payload and the parameters are fully documented in the schema. It is nearly complete, missing only failure/empty-slug behavior, which is minor at this complexity.

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 account_slug, event_slug and release_slug are fully documented in the schema itself. The description only reinforces 'by slug' and restates the endpoint path; it adds no meaning or format detail beyond 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 ('Fetch') and resource ('a single release'), and clarifies the domain term by equating a release with a 'ticket type'. The singular framing plus the mapped endpoint distinguishes it from the sibling tito_list_releases without opening a 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?

Usage is implied by 'by slug' and the singular scope versus the sibling list tool, but the description never explicitly states when to prefer this over tito_list_releases or what to do if the slug is unknown. It provides context but no alternatives or exclusions.

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, so the safety profile is covered. The description adds genuine value beyond that by disclosing the response contents (attendee, registration, release, answers, tags, amounts paid) and the underlying API call, which tells the agent how heavy the fetch is. It stops short of noting error behavior for missing/unauthorized tickets.

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 dense sentences, front-loaded with the primary action and scope, then the endpoint reference. No filler, 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?

With no output schema, the description usefully compensates by naming the data returned, and the schema fully covers the optional account_slug fallback. Slightly incomplete on error/permission behavior, but sufficient for an agent to call it correctly.

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 all three parameters are already documented in the schema, including the account_slug fallback to TITO_ACCOUNT and the ti_... slug format. The description's 'by slug (ti_...)' merely echoes 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 ('Fetch') and resource ('a single ticket by slug'), and enumerates the expanded associations returned (attendee, registration, release, answers, tags, amounts paid), which clearly separates it from the sibling tito_list_tickets. The API endpoint mapping (GET /:account/:event/tickets/:ticket_slug) reinforces the exact scope.

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?

Implied usage is clear from 'single ticket by slug' versus the list sibling, but the description never explicitly states when to use this over tito_list_tickets or tito_get_registration, nor any prerequisites. 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.

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuine context beyond that by naming the fields returned (capacity, allocation_count, sold_out, date/times, attached releases), which matters because no output schema exists. It stops short of documenting pagination behavior or auth requirements outside the params.

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 the resource, its returned fields, and the upstream endpoint with zero padding. The trailing 'Tito: GET /:account/:event/activities' is mildly redundant but reinforces the identifier and is brief.

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 enumerates the payload fields an agent will receive, and annotations cover read-only safety. What is missing is minor: no pagination note despite page/page_size params, and no auth/permission 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?

Schema description coverage is 100% with 4 well-documented parameters, so the schema carries the burden and baseline 3 applies. The description only implicitly signals the event_slug scope via 'an event's activities' and adds nothing about page/page_size or account_slug.

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 (an event's activities), and defines what an 'activity' is — sessions, workshops or dinners beyond the ticket itself — which cleanly separates it from siblings like tito_list_tickets and tito_list_releases. An agent can identify the tool's job 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 clarifying phrase 'beyond the ticket itself' implies when this tool is relevant versus ticketing siblings, but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage is left to inference from the purpose statement.

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 cover the safety profile (readOnlyHint=true), and the description adds what annotations do not: the returned fields (ticket_id, response text) and the underlying endpoint. It omits pagination/auth behavior, but page and page_size are already documented in the 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 sentences, both earning their place: the first states the payload, the second anchors the underlying API call. Front-loaded with the verb and resource, no 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?

For a read-only, five-parameter listing tool with no output schema, the description supplies the return shape and the endpoint while the schema handles all parameter detail, so an agent has enough to invoke it correctly. Pagination behavior is the only unstated aspect.

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 all five parameters (page, page_size, event_slug, account_slug, question_slug) are already explained in the schema. The description adds no syntax or format detail beyond that, matching the baseline for schema-heavy definitions.

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 (answers to a question) and scope ('one question'), and even names the payload shape (ticket_id and response text). It is distinguishable from every sibling, none of which touch question answers.

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 rather than stated: the tool needs a question_slug, which the schema ties back to tito_list_questions, implying a list-questions-then-list-answers workflow. There is no explicit when/when-not or alternative routing in the description itself.

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?

readOnlyHint=true already declares the safe read profile, so the description's added value lies in disclosing the return shape (title, slug, covered releases/activities, attendee fields) and the underlying API call. It does not mention pagination behavior despite page/page_size params, a minor gap.

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 tightly written sentence plus the API endpoint reference; every clause carries information (scope, field contents, endpoint). Front-loaded with the resource and purpose, zero 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?

For a read-only, non-nested list tool with full schema coverage and a readOnly annotation, the description is nearly complete, and by naming the returned fields it compensates for the absent output schema. Only pagination 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 description coverage is 100%, so all four parameters (page, page_size, event_slug, account_slug) are already documented with defaults and formats in the schema. The description adds no parameter-level detail beyond the endpoint path, 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 (List) and resource (event's check-in lists), clarifies what a check-in list is ('door lists used at the venue'), and enumerates the returned fields (title, slug, covered releases/activities, shown attendee fields). No sibling tool covers check-in lists, so it is unambiguously 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?

The description establishes the domain context (door lists at the venue) but gives no explicit when-to-use guidance, prerequisites, or alternatives. Usage is implied by the list semantics rather than stated, which is the minimum viable level.

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, so the safety profile is covered; the description adds the GET endpoint and the shape of what comes back. It does not disclose pagination behavior, ordering, or anything about large result sets beyond what the schema's page/page_size fields imply.

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 sentence front-loads the action and resource, then lists return fields, with the endpoint appended. No filler or 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?

With no output schema, the description usefully enumerates the returned fields, which is the main gap it needs to fill. It stops short of describing pagination semantics or result ordering, but for a read-only list tool with fully documented parameters this is nearly 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%, so every parameter already has documented semantics (page numbering, page_size range and default, slug formats, TITO_ACCOUNT fallback). The description adds no parameter-level detail, 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 and resource ('List an event's discount codes') and enumerates the fields returned (code, type, value, quantity, quantity_used, validity window, releases), which clearly separates it from the singular tito_get_discount_code and the mutating tito_create/update_discount_code siblings. The endpoint mapping reinforces exactly what resource is touched.

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 'an event's discount codes' implies the usage context (you must have an event), but there is no explicit when-to-use versus when-to-use-get_discount_code guidance, no exclusion conditions, and no pointer to alternatives. Usage must be inferred.

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?

readOnlyHint=true already declares the safety profile, but the description adds real value by disclosing the returned fields (slug, title, dates, location, currency, live/test_mode, public URL) and the underlying GET endpoints, which matters because no output schema exists. Pagination and rate-limit behavior are left to the 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 with the scope/default front-loaded and zero filler. The trailing 'Tito: GET /:account/events...' endpoint list is marginally useful for debugging but does not directly help the agent choose or invoke the tool.

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 enumerates the return fields, and the annotation covers safety. Pagination defaults are handled by the schema. Only minor gaps remain: no note on result-set size or how account_slug interacts with TITO_ACCOUNT.

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 the schema already documents all four parameters (page, page_size, scope, account_slug). The description's mention of the three scopes merely restates the enum and adds no syntax or format detail beyond what the schema provides; 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 and resource ('List an account's events') and enumerates the three scope variants, so the agent knows exactly what it returns and how scope changes it. It stops short of explicitly contrasting with tito_get_event or the other list tools, so it is clear but not sibling-differentiating at the top level.

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?

'upcoming (default), past or archived' implies which scope to pick but that is also documented in the enum, so it adds little beyond the schema. It gives no guidance on when to use this tool versus tito_get_event or the other list_* siblings.

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?

readOnlyHint=true already declares the safe-read profile, so the description's added value is the return shape (slug, field_type, required flag, answers_count) which helps the agent decide whether to call it. It doesn't mention pagination behavior despite page/page_size params, which is the only gap.

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 tightly written sentences plus the endpoint citation; the core purpose is front-loaded and the actionable follow-up (use slug with tito_list_answers) is placed immediately after. No 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?

No output schema exists, but the description compensates by naming the fields returned. With annotations covering safety and the schema covering parameters, an agent has enough to call this correctly; only pagination 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 description coverage is 100%, so the schema already documents event_slug, account_slug, page and page_size. The description adds no syntax or format detail beyond that, 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 custom questions an event asks attendees') and disambiguates from the sibling tito_list_answers by scoping to question definitions. The parenthetical examples of question types make the resource concrete.

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 routes the agent forward: 'Use a question's slug with tito_list_answers.' This gives a clear follow-up path, though it doesn't state when to prefer this over other listing tools or prerequisites beyond the implied token/account.

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, so the safety bar is partly cleared, but the description adds a meaningful boundary beyond the annotation: 'this server never issues refunds.' That is a real capability constraint an agent needs, not a restatement. It stops short of pagination behavior, though the schema covers page/page_size.

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-loads the core purpose, follows with the read-only boundary, and closes with the upstream endpoint. Three compact clauses with no filler, each carrying distinct 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?

With no output schema, the description compensates by enumerating the returned fields, and the read-only plus endpoint notes round out the picture an agent needs to call this correctly. Nothing material is left unspecified for a simple read list 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?

Schema description coverage is 100% and all four parameters are documented in the schema, so the baseline of 3 applies. The description adds no parameter-level detail (e.g. account_slug fallback or paging semantics) beyond what the schema already states.

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 (refunds) scoped to an event, and enumerates the returned fields (amount, created_at, manual flag, registration). An agent can distinguish this from sibling list tools like tito_list_registrations or tito_list_activities without opening a 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?

Usage is implied by the 'recorded for an event' scoping, and there is no competing refund tool among siblings, so no alternative needs routing. However, it never states when an agent should reach for this versus adjacent list endpoints, nor any prerequisite conditions, so the guidance is only implicit.

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?

readOnlyHint=true already establishes this as a safe read. The description adds genuinely useful behavior beyond the annotation: newest-first default ordering, the default exclusion of cancelled registrations, and the note that the 'extended' view is slow and large. It does not cover pagination limits or rate limiting, keeping it out of 5 territory.

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, front-loaded with purpose and return payload before filters and the REST endpoint hint. Dense but every clause carries information; the trailing 'Tito: GET /:account/:event/registrations.' is minor filler but the rest 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?

With 12 parameters, no output schema, and a read-only annotation, the description does well by enumerating returned fields and disclosing default ordering and the cancelled-exclusion rule. It leaves pagination defaults and the full response shape to the schema, which is acceptable given there is no output schema, but a short note on paging would make it 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 coverage is 100%, so every parameter already has a description covering enums, formats, and Tito query mapping. The description echoes the filter semantics (free-text fields, state filtering) but adds no syntax or constraint information the schema lacks, 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 and resource (list an event's registrations — Tito's orders) and enumerates what is returned (buyer name/email, reference, total, state, flags, discount code, ticket quantities), plus ordering. An agent can distinguish it from tito_get_registration (single record) and the other tito_list_* siblings 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?

Explains the filtering dimensions (free text, state, created/updated time) and the key default behavior that cancelled registrations are excluded unless 'cancelled' is in states. It does not explicitly name alternatives such as tito_get_registration or tito_list_refunds, so it stops short of full when/when-not routing.

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?

readOnlyHint=true already covers the safety profile, but the description adds real value by enumerating the returned fields (price, quantity, tickets_count sold, sold_out/off_sale/secret flags, sale window, share_url) in the absence of an output schema. It does not discuss pagination behavior or rate limits, which keeps 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?

Two tightly packed sentences: the resource and its returned shape first, the underlying API endpoint last. No filler and nothing important buried at the end.

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's field enumeration is what tells an agent what a release object contains, and pagination/account scoping are handled by the schema. It stops just short of explaining return ordering or pagination limits, so it is complete but not exhaustive.

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 all four parameters (event_slug, account_slug, page, page_size) are documented in the schema itself. The description adds no parameter-level syntax, defaults, or constraints beyond what the schema provides, 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) and resource (releases / ticket types), and explicitly disambiguates Tito's terminology by equating 'releases' with 'ticket types'. The returned field list further pins down what a release record is, distinguishing it from siblings like tito_list_tickets and tito_get_release.

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 listing context ('List an event's releases'), and the API mapping hints at the scope, but it never states when to prefer this over tito_get_release for a single release or tito_list_tickets. No explicit exclusions or alternatives are named.

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?

With readOnlyHint=true already declaring a safe read, the description adds genuine behavioral context: the default exclusion of void tickets, the newest-first default ordering, and the returned field set. What it doesn't cover (pagination semantics under 'extended', rate limits) is partly handled by schema notes on view/page_size.

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, front-loaded with the resource and cardinality, then filters, then the one non-obvious default. Slightly dense in the middle (a long comma list that mirrors the schema), but nothing is 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 15-parameter read tool with no output schema, the description usefully enumerates returned fields and the void-exclusion default. It leaves the required vs optional distinction and account_slug fallback to the schema, which documents them, so the result is adequate though not exhaustive.

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 the schema already documents all 15 parameters with syntax and Tito-specific keys. The description echoes the filter categories and the void-exclusion interaction with 'states' — mildly useful but largely redundant against the schema baseline of 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?

States a specific verb+resource (list an event's tickets), the cardinality (one per attendee), default ordering (newest first), and enumerates the fields returned. An agent can distinguish this from tito_get_ticket (single) and tito_list_registrations (different resource) 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?

It names the filterable dimensions (free text, state, type, release, activity, created/updated time) and gives a concrete default behavior — void tickets are excluded unless 'void' appears in states — which is a real when/when-not condition. It stops short of naming sibling alternatives for adjacent tasks (e.g., fetching one ticket).

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 declare destructiveHint=true, so the safety profile is already covered. The description adds genuinely non-redundant behavior: partial merge semantics and the non-obvious retire-via-end_at trick. It omits permission requirements and reversibility, keeping it at a 4.

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 reference, front-loaded with the mutation semantics and the retire tip. No filler or restatement 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?

For a 14-parameter mutation with no output schema, the description covers the essentials: what changes, merge behavior, and a key edge case. Minor gaps remain around auth/account scoping (account_slug is only explained in the schema) and error behavior, but nothing an agent needs to invoke it 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 every parameter is already documented with type, format and examples (e.g. decimal string value, ISO 8601 datetimes). The description only groups fields conceptually ('validity window', 'attached releases') and adds no syntax or constraint 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 ('Change'), resource ('an existing discount code'), and enumerates the mutable surface (code, value, quantity, validity window, attached releases), plus the underlying PATCH endpoint. An agent can immediately tell this apart from the create/get/list siblings.

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 a clear partial-update rule ('Only the fields you pass are sent') and a concrete operational recipe for the common retire case ('set end_at to now'). It does not name alternatives or explicit when-not-to-use conditions, so it stops short of a 5.

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 provide only destructiveHint=true, so the description usefully adds PATCH partial-update semantics and the fact that no email is sent to anyone. The destructive behavior implied by the annotation (tags replace existing values) is only documented in the parameter schema, not the description, which is a minor gap.

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 dense sentences, front-loaded with the purpose and fields, followed by the two most important behavioral caveats (partial update, no email). Nothing is wasted and the API endpoint is appended as compact reference.

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 10-parameter mutation tool with no output schema, the description covers what it changes, how partial updates behave, and the notification side effect. It stops short of describing the response payload, error behavior, or permission requirements, which an agent might still want.

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 the schema already documents all ten parameters, including the important note that tags replace existing tags. The description's field list (name, email, company, phone, tags, metadata) mirrors the schema without adding formats, constraints, or edge-case behavior, so it earns only the baseline.

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 states a specific verb ('Correct') and resource ('a ticket's attendee details') and enumerates the affected fields (name, email, company, phone, tags, metadata), so an agent knows exactly what the tool mutates. It distinguishes itself from reassignment semantics, though it does not explicitly differentiate itself from sibling tools like tito_get_ticket or tito_create_ticket.

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 makes the usage context clear: this is for correcting attendee details, it is a partial update ('Only the fields you pass are sent'), and it does not trigger notifications. The 'unlike a reassignment, which this server does not do' clause scopes what this tool is not for, but no sibling tool is named as an alternative.

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, so the safety profile is covered. The description adds genuinely useful behavior the annotations don't: the live/test lookup mode and the fact that a token only sees tickets and registrations of its own mode. It stops short of describing the response shape or error behavior on an invalid token.

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 plus a short endpoint tag, all front-loaded, with the 'call this first' directive and mode caveat earning their place. No 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?

No output schema exists, but the description enumerates the key return values (account slugs, lookup mode) and the mode semantics an agent needs to interpret them. Nothing required to call it correctly 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?

Zero parameters, so per the rubric the baseline is 4. The description correctly conveys that no input is needed and instead describes what the call yields.

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 ('confirm', 'list') and resource (API token, account slugs it can reach, lookup mode). Clearly distinguishable from every sibling, which all operate on tickets, events, registrations, or discount codes rather than the token itself.

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 says 'Call this first to discover account_slug', which tells the agent both the ordering and the reason for invoking it. Also notes the mode constraint that scopes what data the token can see.

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