Tito MCP by usefulapi

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

With only destructiveHint=true in annotations, the description adds genuinely useful behavior: there is no delete path (undo is done by editing quantity or end_at), plus the underlying endpoint POST /:account/:event/discount_codes. It does not explain what object is returned or what happens on duplicate codes, so it stays 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?

Three short sentences, front-loaded with the action and the semantic distinction that matters (percent vs flat), then the edit-to-undo note. No filler and nothing 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 13-parameter creation tool with no output schema and only a destructiveHint annotation, the description covers the essential calling semantics and the reversal path. It omits what the call returns and any note on error/duplicate handling, but that is a minor gap given full schema coverage.

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 13 parameters, including the type enum and value format. The description restates the type/value semantics and adds only the 'in the event currency' detail, which is a marginal gain over the schema 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?

States a concrete verb and resource ('Create a discount code') and scopes it ('for an event'), so an agent can tell it apart from tito_list_discount_codes, tito_get_discount_code, and tito_update_discount_code 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?

It points to tito_update_discount_code as the undo path, which usefully frames the create/edit lifecycle, but there is no explicit when-to-use or when-not-to-use guidance and no statement of prerequisites (e.g. account slug resolution, permissions).

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 only supply destructiveHint=true, but the description adds substantial behavioral context beyond them: the ticket counts against the release's capacity and can only be undone by voiding it in the Tito dashboard, i.e. it is not removable via API. It also discloses the underlying endpoint (POST /:account/:event/tickets), reinforcing that this is a real write operation.

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 short sentences, front-loaded with the purpose and followed by the capacity/irreversibility warning. 'Tito creates a manual registration for it' slightly restates the opening sentence and the raw endpoint line is of marginal value, but there is no real bloat.

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 mutation tool with thin annotations and no output schema, the description covers the key risk (capacity consumption, void-only undo). It does not say what the response contains or how to locate the created ticket later in order to void it, which is a modest gap given there is no output schema to fall back on.

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% across all 11 parameters, with release_id and account_slug already documented including slug/numeric-id forms and the TITO_ACCOUNT fallback. The description adds no parameter-level 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 ('Issue a ticket for a release') and immediately scopes it as issuance without a checkout, with concrete examples (speaker, sponsor, comp). This distinguishes it cleanly from siblings like tito_create_discount_code, tito_update_ticket, and the various list/get tools.

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 clear context for when this tool applies ('without a checkout — e.g. a speaker, sponsor or comp ticket'), which is exactly the scenario an agent needs. It does not, however, state exclusions or name an alternative path for normal checkout-based issuance, so it stops short of full when/when-not guidance.

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 still adds value by disclosing return content ('how many times it has been used') — notable because there is no output schema — and by naming the underlying API 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 with the purpose front-loaded and the identifier constraint immediately after; the trailing API endpoint reference is mildly redundant but compact and helps agents mapping to the Tito 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?

For a read-only single-resource fetch, the description covers what it does, what identifies the resource, and one piece of return content, which compensates for the absent output schema. It is slightly thin on ordering/response shape and auth prerequisites that the schema only hints at.

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 fully documents event_slug, account_slug and discount_code_id on its own. The description only echoes 'numeric id' for the lookup key and adds no format or constraint detail beyond the schema, 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 (fetch) and resource (a single discount code) and pins the lookup key to the numeric id, which distinguishes it from the list_discount_codes sibling by the word 'single'. It does not name that 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 'single ... by its numeric id' phrasing – use it when you already know the id rather than wanting a list – but there is no explicit when-to-use, when-not-to-use, or named alternative such as tito_list_discount_codes.

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 safety profile, so the description's remaining burden is modest. It adds useful context by disclosing the payload shape and that releases are embedded in the response, but says nothing about auth requirements, error behavior for unknown slugs, or whether live/test events differ in output.

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, zero filler, and the core action is front-loaded before the field enumeration. The trailing 'Tito: GET /:account/:event' is compact and useful for mapping to 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 naming the fields returned, including the nested releases. Parameters are self-documenting via the schema and annotations cover read-only safety. Minor gap: nothing on failure modes for an invalid slug or on the live/test_mode distinction for callers.

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 fully explained (including the URL-position convention and the TITO_ACCOUNT fallback). The description's 'by slug' adds no syntax or format detail 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?

Specific verb+resource ('Fetch a single event by slug') with the identifying key named, plus an enumeration of the returned payload (title, dates, location, currency, live/test_mode, releases). This cleanly distinguishes it from the sibling tito_list_events and from tito_get_release/tito_get_ticket, which fetch adjacent resources rather than the event 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?

The 'by slug' phrasing implies when this tool applies, but there is no explicit when-to-use/when-not, and no pointer to alternatives (e.g. use tito_list_events to discover slugs). The one contextual hint — that tito_whoami lists reachable accounts — lives in the schema for account_slug, not in the description.

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 further by disclosing exactly what the payload contains (tickets, receipts, refunds, line items, billing address, payment details), which is meaningful behavioral context beyond the annotations. It does not cover auth scope or rate limits, so it is 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?

Two tightly packed sentences, front-loaded with the action and resource, and the trailing API endpoint reference is a compact aid for mapping to Tito docs. 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?

With no output schema, the description compensates by enumerating the major returned sections, which is enough for an agent to know what it gets back. It omits pagination/expansion options and error behavior, but for a single read-only fetch it is largely 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 the schema already documents event_slug, account_slug (including the TITO_ACCOUNT fallback) and registration_slug. The description restates the registration slug format but adds nothing new about the parameters, 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 registration (order) by slug') and clarifies the identifier format (reg_...), which implicitly contrasts with the list sibling tito_list_registrations. It stops short of naming that sibling explicitly, which is the only thing keeping it from a 5.

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-slug framing implies when to use it versus a list call, but there is no explicit statement of when to prefer this tool, no prerequisites, and no named alternative. Usage is inferable but not spelled out.

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, so the description only needs to add context – and it does, enumerating the returned payload (pricing, capacity, sales counts broken out as full-price/discounted/free/voided, questions, activities). That is meaningful behavioral detail beyond the annotation, though it says nothing about auth scope or rate limits.

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 front-loaded sentences: the purpose and payload come first, the underlying API mapping trails it. The endpoint reference is mildly redundant but useful for cross-referencing docs; nothing else 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?

With no output schema, the description carries the burden of describing the return shape, and it does so by enumerating the payload sections. What is missing is auth/token requirements and confirmation of error behavior when a slug is absent.

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 explains account_slug, event_slug and release_slug with URL-position examples. The description adds only 'by slug', which conveys no format or syntax detail beyond what the schema provides, making the baseline 3 correct.

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 (ticket type)'), scoped by slug, and clarifies the domain meaning of 'release'. The word 'single' implicitly separates it from the sibling tito_list_releases, so an agent can route correctly without opening schemas.

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 'a single release by slug', and the singular-vs-plural contrast with tito_list_releases is inferable, but the description never names the alternative or the condition (need many vs. one) that selects it. No exclusions or prerequisites are stated.

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 safety profile, so the description doesn't need to re-argue that. It adds genuine value beyond annotations by disclosing the expanded response content (attendee, registration, release, answers, tags, amounts paid) and mapping the call to the underlying Tito endpoint. It does not mention not-found/error behavior, which keeps it from 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 sentences, both front-loaded: the operation and payload first, the API mapping second. There is no filler or redundancy, and every clause contributes either scope or return-content 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 usefully compensates by listing the returned sub-objects, and the account_slug fallback is handled in the schema. The only meaningful omission is failure behavior (e.g., unknown slug), which is a minor gap for a simple 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 all three parameters are already documented in the schema with examples (event slug, ti_... ticket slug, account slug fallback). The description adds no format or syntax detail beyond restating that lookup is by slug, 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?

The description names a specific verb and resource ("Fetch a single ticket by slug") and enumerates the related data returned, so its scope is unambiguous. It implicitly separates itself from the list-style siblings by emphasizing "single ticket by slug", but it never names an alternative, so it stops short of full sibling differentiation.

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 only implied: the agent can infer this is the lookup tool when a ticket slug is already known. There is no explicit statement of when to prefer it over tito_list_tickets or tito_get_registration, and no exclusions or prerequisites are given.

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 safe-read profile is covered. The description usefully discloses the returned fields (capacity, allocation_count, sold_out, date/times, attached releases) and the underlying endpoint, but says nothing about pagination behavior or scope limits.

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 dense sentence with the resource and returned fields front-loaded, plus the endpoint reference. Efficient with no filler, though the em-dash list is packed and could be trimmed slightly.

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 key return fields, and pagination is handled by the schema. Requirements like the optional account_slug fallback are covered in the schema, so the definition is nearly complete for a simple list tool, lacking only deeper return-shape detail.

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_slug, account_slug, page and page_size are all documented in the schema itself. The description adds no parameter-level meaning beyond that, which matches the baseline 3 when structured data does the work.

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 clarifies scope with concrete examples (sessions, workshops, dinners beyond the ticket itself). This distinguishes it from sibling list tools like tito_list_tickets and tito_list_releases, though it doesn't name a sibling explicitly.

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 clause 'beyond the ticket itself' implicitly signals when to reach for this over tito_list_tickets, but there is no explicit when-to-use statement, no prerequisites, and no named alternative. Usage is inferable but not spelled out.

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 value by disclosing the return shape (ticket_id plus response text) and the underlying endpoint, but says nothing about pagination behavior despite the page/page_size 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?

Two tight sentences, front-loaded with the core action and return contents, with the endpoint reference trailing. No wasted words.

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 helpfully names what comes back, and all parameters are documented in the schema. Minor gap: no mention of pagination limits or how to page through large attendee lists.

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 are already documented in the schema. 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 (list) and resource (every attendee's answer to one question) and even enumerates the returned fields (ticket_id, response text). This clearly separates it from the sibling tito_list_questions, which lists questions rather than 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?

The description implies the use case (retrieve answers for a single question) but never states when to use it versus alternatives such as tito_list_questions or tito_list_registrations. The dependency on question_slug is only surfaced in the schema, not in the description.

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 signals a safe read, so the description's job is to add context beyond that. It does: it discloses the identity of the returned items (title, slug, covered releases/activities, visible attendee fields) and names the underlying Tito endpoint, which helps the agent reason about freshness and scope. It stops short of describing pagination behavior despite page/page_size parameters existing.

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 states the resource and its return contents, followed by a terse endpoint reference. No padding or repetition, though the endpoint fragment is arguably optional decoration rather than decision-relevant 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?

With no output schema, the description usefully enumerates what each check-in list contains, covering the return shape. Combined with the schema's descriptions of account resolution (TITO_ACCOUNT, tito_whoami) and pagination, an agent has enough to invoke this correctly; only pagination behavior is left unstated in prose.

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 baseline is 3. The description adds nothing about the parameters — it does not mention pagination, the event_slug requirement, or the optional account_slug/TITO_ACCOUNT fallback, all of which the schema already documents well.

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 check-in lists) and clarifies the domain jargon with a parenthetical gloss ('the door lists used at the venue'). It also names the concrete fields returned, so an agent can distinguish it from sibling list tools like tito_list_tickets or tito_list_registrations 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?

Usage is implied by the 'list' verb and the event-scoped resource, and the parenthetical hints at the real-world scenario (venue door lists). However, there is no explicit when-to-use guidance, no statement of prerequisites, and no pointer to alternative tools for related data such as tito_list_releases or tito_list_activities.

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 is a safe read, so the bar is lower. The description adds value by enumerating the returned fields, but discloses nothing about pagination behavior, rate limits, or how the validity window is represented; with annotations carrying the safety profile this is adequate but thin.

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 naming the resource and its returned fields, followed by a terse endpoint reference. Nothing is padded, though the endpoint line is marginal value for an agent that only needs to call 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 compensates by listing the fields returned, and the schema fully covers the inputs. It omits any note on pagination semantics across pages, which is a minor gap for a list endpoint.

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 in the schema. The description adds no syntax, default, or range 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 an event's discount codes') and enumerates the returned fields (code, type, value, quantity, quantity_used, validity window, releases), which distinguishes it from the singular tito_get_discount_code. It stops short of explicitly naming the sibling it is not, so it is clear but not fully differentiated.

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?

There is no when-to-use guidance, no condition selecting this over tito_get_discount_code, and no prerequisites beyond the endpoint reference. The 'Tito: GET /:account/:event/discount_codes' line documents the upstream call but tells the agent nothing about when to reach for this tool.

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 real value beyond that by enumerating the returned fields (slug, title, dates, location, currency, live/test_mode, public URL), which matters since no output schema exists. It stops short of mentioning pagination behavior or auth scoping, though the schema's account_slug parameter does carry the auth detail.

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 core action and scope before the return-field list and API references. Every clause carries information an agent can use; there is 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, zero-required-param list tool with no output schema, the description covers scope selection, the returned field set, and the backing endpoints. Pagination is only covered by the schema, and no mention is made of result limits, so it is nearly 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%, so all four parameters are already self-documenting, making 3 the baseline. The description only restates the scope enum values and maps them to API paths, adding path-level detail but no syntax or format meaning 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?

The description gives a specific verb (List) and resource (an account's events) and enumerates the three scope variants, so its role is unambiguous. It does not explicitly differentiate itself from the sibling tito_get_event, which is the only remaining gap.

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 states that 'upcoming' is the default and names the other two scope options, which implies when each is used. However, it never says when to pick this tool over tito_get_event, nor gives any prerequisite or exclusion guidance.

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, so the bar is lower. Beyond that, the description discloses the shape of the returned data (slug, field_type, required flag, answers_count) and the underlying endpoint, which is meaningful behavioral context with no output schema present.

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 sentences that front-load the purpose and then the follow-up action. Every clause earns its place, though the trailing raw endpoint string 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?

With no output schema, the description compensates by naming the returned fields, and the read-only nature is covered by annotations. It does not mention pagination behavior, but the page/page_size parameters in the schema largely fill that 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%, so event_slug, account_slug, page and page_size are already fully documented in the schema, establishing a baseline of 3. The description reinforces that a question's slug is the key used to fetch answers but adds no syntax or format 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 ('List the custom questions an event asks attendees') and even enumerates the returned fields (slug, field_type, required flag, answers_count). It is clearly distinguishable from sibling list tools like tito_list_answers or tito_list_tickets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent to the follow-up tool: 'Use a question's slug with tito_list_answers,' which establishes the workflow context. It does not, however, state exclusions or when this tool should be preferred over alternatives such as tito_list_answers directly.

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 reinforces this and adds substantive value by disclosing the shape of each returned record (amount, created_at, manual status, linked registration). It does not describe pagination behavior, but that is 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 with zero padding: the returned-fields summary comes first, followed by the read-only constraint and the underlying endpoint. Everything is front-loaded and every clause 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 no output schema, describing the fields returned is exactly what the description should supply, and pagination plus slugs are fully covered by the schema. Minor gap: it doesn't mention paging defaults or result ordering, which an agent might want when iterating.

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 four well-documented parameters (event_slug, account_slug, page, page_size), so the schema carries the semantic load. The description adds no parameter-level detail, making the baseline 3 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?

States a specific verb and resource ('List the refunds recorded for an event') and enumerates the returned fields (amount, created_at, manual flag, registration), which is more than a restatement of the name. No sibling tool handles refunds, so the scope is unambiguous among the listed tools.

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 context for when the tool applies (retrieving refunds for an event) and adds a useful negative boundary: 'this server never issues refunds.' It stops short of naming an alternative for issuing refunds or stating prerequisites, so it isn't a full when/when-not pair.

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 covering the safety profile, the description still adds real behavior: newest-first default ordering, implicit exclusion of cancelled registrations, and which buyer/order fields come back. It doesn't discuss pagination limits or response size beyond what the schema's 'view' note already says.

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 resource and ordering, then filters, then the default exclusion rule, then the upstream endpoint. Dense but every clause carries information; nothing is padded or restated from the schema.

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 12-parameter read tool with no output schema, the description usefully enumerates the returned fields and states default ordering and filtering so the agent knows what it gets. Pagination and the extended-view tradeoff live only in the schema, but those are covered there.

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 baseline is 3, but the description adds meaning the schema does not: the exact characteristics searchable via free text (email, name, slug, reference, company, discount code) and the non-obvious default that cancelled orders are hidden unless 'states' is set.

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') plus ordering ('newest first') and the returned field set, which clearly separates it from siblings like tito_list_refunds and tito_list_tickets. An agent can identify the tool 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 default filter behavior (cancelled excluded unless 'states' includes 'cancelled') and the available filter axes (free text, state, created/updated time), which tells the agent when this tool fits. It stops short of explicitly naming an alternative tool or when *not* to use it.

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 covering the safety profile, the description still adds substantive context by naming the returned fields (price, quantity, tickets_count sold, sold_out/off_sale/secret flags, sale window, share_url) despite no output schema existing. This is valuable disclosure of what the call yields, though pagination behavior is unmentioned.

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?

One compact sentence front-loads the purpose, enumerates the payload, and appends the underlying API mapping with zero filler. Every clause 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?

For a read-only list tool with no output schema, the description covers purpose, returned fields, and the API endpoint, while annotations cover the safety profile and the schema covers parameters. Nothing an agent needs to invoke it correctly is missing, bar a minor note on pagination.

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 page, page_size, event_slug and account_slug are already fully documented in the schema. The description adds no format or usage 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?

Specific verb (List) plus resource (an event's releases) and an explicit gloss that releases are Tito's ticket types, which is the exact term an agent might search for. It also maps cleanly against siblings like tito_get_release (single) and tito_list_tickets (a different resource).

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 makes the scope clear (all releases for one event), which implies when to use it versus tito_get_release, but it never states that alternative or any exclusion. 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.

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

Beyond the readOnlyHint annotation, the description discloses the default sort ('newest first'), the fields returned, and the non-obvious default exclusion of void tickets — none of which are in the annotations. It omits pagination/auth behavior, but the SQL-shaped void rule is genuinely useful context.

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 dense sentences, front-loaded with the resource and scope, then filtering, then the void rule, then the endpoint. Every sentence earns its place; the long filter list is compact but slightly run-on.

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-only list tool with no output schema, the description covers what is returned, the default ordering, and the default void exclusion. Defaults like page_size (100) and view (short) live in the schema, so their absence from the description is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description lifts this above baseline by surfacing one cross-parameter rule (void excluded unless 'states' includes 'void') and summarizing the filter families the parameters cover.

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 tickets — one per attendee') plus the scope and the fields returned, which cleanly separates it from the singular siblings tito_get_ticket and tito_list_registrations.

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 concrete filtering context (free text, state, type, release, activity, time) and a real selection rule — void tickets are excluded unless 'states' includes 'void'. It stops short of naming an alternative tool or an explicit when-not condition.

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 only declare destructiveHint=true, so the description's clarification that this is a partial PATCH and that unspecified fields are left untouched is genuinely additive — it tells the agent unlisted fields will not be cleared. The retirement hint via end_at is another useful behavioral fact. Authorization/prerequisite details and any consequence of changing code text on already-issued tickets are not covered.

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 short sentences, front-loaded with the mutation scope, then the merge semantics, then the retirement recipe and endpoint. Nothing is redundant 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?

For a 14-parameter mutation tool with no output schema, the description supplies the two things the schema cannot: partial-update behavior and a retirement workflow. It omits auth/prerequisite context and what a successful or failed update returns, but the rich schema carries the rest.

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 one of the 14 parameters is already documented with type, bounds, and meaning. The description narrates a few field names (code, value, quantity, validity window, releases) but adds no format, constraint, or interaction detail beyond the schema, which is the correct baseline-3 outcome.

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) and resource (an existing discount code) and enumerates the editable surface — code, value, quantity, validity window, attached releases — so an agent knows exactly what this tool mutates. It is distinguishable from tito_create_discount_code and tito_get_discount_code by the word 'existing', though it never names those siblings explicitly.

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?

"Only the fields you pass are sent" establishes partial-update semantics, and "To retire a code without deleting it, set end_at to now" gives a concrete workflow for a common intent. No explicit when-not or alternative-tool routing is offered, 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 carry only destructiveHint=true, and the description adds two behaviors not in structured data: sparse/PATCH semantics ('only the fields you pass are sent') and the no-email side effect. It does not explain the destructive aspect the annotation flags (that the tags array replaces existing tags), which is the one notable 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 tight sentences front-load the purpose and the two behavioral caveats, followed by the underlying PATCH route. The trailing 'Tito: PATCH /:account/:event/tickets/:ticket_slug' is marginally redundant but useful grounding and costs one line.

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, nested-object mutation with no output schema, the description covers the essentials: partial-update semantics, side effects, and the endpoint being wrapped. It stops short of describing what a successful call returns or warning that tag replacement is the destructive operation, but nothing critical to invoking it correctly is absent.

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, including the tags-replacement caveat and the account_slug/TITO_ACCOUNT fallback. The description's field list is a restatement of parameter names, adding little beyond the schema; 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 ('Correct a ticket's attendee details') and enumerates the mutable field families (name, email, company, phone, tags, metadata). It also proactively rules out a nearby behavior ('unlike a reassignment, which this server does not do'), so an agent can separate it from ticket-creation and other siblings without opening schemas.

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 gives clear operating context: only supplied fields are sent (partial update), and no notification email is triggered. It doesn't name a competing sibling tool to prefer in a specific scenario, but the exclusions it does state remove the main ambiguity an agent would have.

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 cover the safety profile (readOnlyHint=true), but the description adds genuine behavioral context beyond them: the live/test mode concept and the non-obvious constraint that a token only sees tickets and registrations of its own mode. That scope limitation is the kind of thing that changes how an agent interprets every subsequent call. It stops short of 5 only because it doesn't describe error/auth-failure behavior.

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 compact sentences, front-loaded with the core action and the highest-value instruction ("call this first"). The parenthetical about token mode earns its place by explaining a real scoping constraint rather than padding.

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?

There is no output schema, so the description carries the return-value burden — and it does: it names what comes back (account slugs, lookup mode). For a zero-param, read-only discovery tool with annotations covering safety, nothing needed 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?

The tool takes zero parameters, so per the rubric the baseline is 4. Nothing in the description is needed to explain inputs, and it correctly documents that the tool is parameterless by implication.

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 combo — confirm the token, enumerate reachable account slugs, and report the lookup mode — which no sibling tool does. It also maps to the underlying endpoint (GET /hello), so an agent can distinguish it from all the list_* and get_* siblings at a glance.

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", giving a concrete prerequisite/ordering rule rather than an implied one. Since this is a discovery tool with no real alternative, naming the ordering constraint is exactly the guidance an agent needs.

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