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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds only the underlying endpoint (GET /event/{event_id}/), and stays silent on redaction behavior, which is handled in the schema instead.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence front-loads the core purpose and then lists the payload areas, with the endpoint appended. There is no filler, though the endpoint mention is of marginal value to an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully enumerates what comes back, which is the right thing to compensate for. It still omits error/not-found behavior and any hint that some fields may be redacted by default, leaving a small gap for a 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%, including a thorough explanation of include_contact_details and its redaction default, so the schema carries parameter semantics. The description adds no parameter-level detail (e.g., what event_id accepts, or that contact details are gated), 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 ('One event in full') and enumerates the returned content areas (description, booking info, organisation, venue, tags, gallery, seat-view URL), making the scope concrete. It does not explicitly distinguish itself from get_performance or list_events, so it stops short of 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?

Usage is implied rather than stated: a single-event-by-ID fetch is inferable from 'One event in full' and the required event_id. There is no explicit when-to-use guidance, no exclusion of list_events, and no note on behavior when the ID is unknown.

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 readOnly/idempotent/non-destructive, so the bar is low. The description adds real disclosure beyond them: payment methods are returned 'without any provider keys' (a security-relevant guarantee) and the delivery-method endpoint is API-scoped to a transaction. Redaction behavior is present but lives in the schema, not the description.

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 opens with the framing ('What the channel is set up with') and then enumerates the resources in parallel, with endpoint references inline. It is dense and slightly run-on, but every clause carries information and 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?

With no output schema, the description carries the full burden of explaining return values, and it does so by listing each returned resource category plus the condition that gates it. All three optional parameters are accounted for, so an agent has everything needed to call and interpret the 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 the schema already documents all three parameters, including the redaction semantics of include_contact_details. The description's notes on performance_id and transaction_id largely restate the schema, adding only the scoping rationale. 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?

The description names a specific resource bundle — organisation currency, venue plans, payment methods, seat types, delivery methods — with the backing endpoints, so an agent knows exactly what comes back. It doesn't explicitly contrast itself with siblings like get_transaction or get_performance_seating, but the config-level scope is distinctive enough to separate it.

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?

Conditional usage is stated directly: seat types can be scoped to a single performance, and delivery methods are returned only when a transaction_id is supplied. There is no explicit when-not-to-use or named alternative, but the parameter-driven conditions make the invocation context clear.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds useful scope about what the response contains (pricing per band/variant, capacity remaining) but says nothing about auth needs, rate limits, or the redaction behavior described 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, front-loaded with the substantive content (fields returned) before a short endpoint note. The trailing "Uses GET /performance/{performance_id}/." adds little for an agent but costs only one clause.

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 earns its keep by enumerating the key return fields. It is nearly complete for a simple read-by-id tool; the only real omissions are error/not-found behavior and any hint on the `codes` parameter.

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 baseline is 3. The description adds no parameter meaning beyond the schema; notably it does not clarify the opaque `codes` parameter, which the schema itself admits is undocumented.

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?

"One performance with its pricing per price band and variant, capacity and capacity remaining, venue plan id" gives a specific verb+resource and previews the returned payload. The word "one" implicitly separates it from list_performances, but no sibling is named 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?

Usage is only implied: fetching a single performance by id when you already have the id. There is no statement of when to prefer get_performance over list_performances or get_performance_seating, and no prerequisites or exclusions 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 cover the read-only, idempotent, non-destructive profile, so the description earns credit for adding what they cannot: seat lists can be large, seats default off, results are capped by max_seats with the remainder summarised, and a per-group summary always accompanies seat fetches. It still does not discuss authentication or rate limits, but the added operational context is substantive.

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 core purpose and no filler sentences; every clause carries information. The single dense sentence is slightly run-on, which is the only structural weakness.

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 fully carries the burden of describing return values (capacity, capacity remaining, price band, seat type, group) and the default/cap behavior. Nothing an agent needs to invoke and interpret the call 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 coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining the interaction between include_seats and max_seats and the always-present per-group summary, clarifying why the cap exists. The ambiguous `codes` parameter is left unexplained in both places, which keeps this from a 5.

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 ('Seating availability for one performance') and enumerates the returned entities (groups, areas, sections, rows with capacity/capacity remaining). An agent can distinguish this from get_performance, which covers performance metadata rather than seat inventory.

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 explains the two underlying endpoints and the default-off seat behavior, which implies usage, but never says when to call this instead of siblings like get_performance or list_performances, nor any preconditions. Usage is inferable but not 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?

Annotations already declare this a read-only, idempotent, non-destructive call, and the description adds substantive behavior beyond that: payment provider data is never returned, contact fields stay redacted unless include_contact_details is set, barcode codes are gated, and ticket-item/note payloads are paged via sub-resources. That is exactly the extra context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core identification ('One transaction ... by its txn_ id') is front-loaded, and the second sentence carries the conditional-access rules. It is dense — a long mid-sentence enumeration of returned sub-resources — but nearly every clause conveys a field set or a gate, so little 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 correctly assumes the burden of describing the return payload: identity fields, totals, line-item types, coupons, notes and paging sub-endpoints, plus redaction and payment-provider exclusions. An agent can anticipate the shape of the response without a return 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?

With 60% schema description coverage, the schema documents include_barcodes, include_contact_details and transaction_id, but leaves max_notes and max_ticket_items undocumented there. The description compensates by explaining the contact-detail redaction and barcode gates and by signaling that ticket-item and note collections are paged, though it does not explicitly explain the two max_* limits.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('One transaction ... by its txn_ id') and enumerates the returned content: status, reference, totals, customer name, ticket items, coupons, notes. This is clearly distinguishable from siblings like get_visit and get_event because it names the transaction resource and its txn_ identifier.

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 'by its txn_ id' framing and the explicit gates on include_contact_details/include_barcodes, but the description never says when to prefer this tool over a sibling such as get_visit or when a lookup should be avoided. No explicit when-not guidance or named 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 readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered without the description. The description adds that contact details are gated behind include_contact_details and cites the underlying endpoint, but it largely restates what the schema parameter already documents.

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 the return payload, which is the most useful information for an agent. The trailing endpoint reference ('Uses GET /visit/{visit_id}/') is somewhat redundant but doesn't obscure the 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 describes the shape of the returned visit (tickets, transaction, share). An agent has enough to call it correctly, though it does not mention pagination or error behavior for a missing visit.

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 parameters are already fully documented. The description's note that emails appear 'only with include_contact_details' adds only marginal meaning 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?

The description names the exact resource and enumerates the payload contents ('every ticket item, its transaction, and... the share'), which clearly separates it from list_visits and get_transaction. It is specific rather than tautological, though the retrieval verb itself is only implied.

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 required visit_id and the single-visit scope, but there is no explicit statement of when to call this versus get_transaction or list_visits. No prerequisites or exclusions 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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the read-only, safe, repeatable profile is covered. The description adds the underlying endpoint (GET /event/) and field inventory, but the one notable behavioral wrinkle — redaction of emails/phones — is already spelled out in the schema, so the description contributes modest extra context rather than new behavioral disclosure.

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 what the tool returns, then filtering/sorting, then the endpoint. Little waste, though the trailing 'Uses GET /event/' is arguably low-value implementation detail for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description's enumeration of returned fields carries real weight and mostly compensates. With 7 optional parameters, 100% schema coverage, and read-only annotations, the definition is nearly complete; the only gap is routing guidance versus the many list/get siblings.

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 those descriptions are notably detailed (pagination semantics, hasPackage ambiguity, redaction default). The description's filter/sort sentence restates what the schema already documents without adding format, syntax, or interaction details, 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 ('Events on this channel (shows, productions, exhibitions)') and enumerates the fields returned (name, description, run time, venue with address, tags, image) plus filtering and sorting capability. It is clearly distinguishable from get_event by the plural/resource-list framing, but it never names a sibling, so it falls 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?

The description says what can be filtered and sorted, which implies when the tool is useful (browsing/filtering events by venue or packages). However it gives no explicit when-to-use guidance against list_performances or get_event, and no exclusions or prerequisites, leaving usage 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 readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds real behavioral context beyond that: results are paged, and products/add-ons are silently omitted without a transaction_id (a non-obvious scoping quirk that would otherwise look like an empty result). It stops short of covering auth needs or rate limits, so 4 rather than 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, front-loaded with the primary resource and its contents before the conditional transaction branch. The parenthetical endpoint citations add useful anchoring, though the second sentence is dense enough that it takes a second pass to parse.

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 9-parameter read-only listing tool with no output schema, the description covers the essentials: what comes back, how the two modes differ, the paging model, and the transaction scoping constraint. Missing only edge-case behavior (e.g. empty results, ordering), 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 description coverage is 100%, so the baseline is 3. The description still adds meaning the schema does not: the schema marks zero required parameters, while the description tells the agent it must supply event_id or performance_id, and it explains the transaction_id dependency that governs whether products/add-ons appear at all.

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 ('Packages ... for one event ... or one performance'), enumerates what the records contain (bundles priced per performance, capacity remaining, total price), and cites the exact endpoints (GET /package/, GET /performance/{id}/package/, GET /product/, GET /add-on/). No sibling tool covers packages or add-ons, so the agent can separate it from list_events/get_transaction 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 states the selection rule plainly ('Give event_id or performance_id') and explains the transaction branch conditionally: products and add-ons are only fetched when transaction_id is supplied, because the API scopes them to a transaction. That is clear when-to-use guidance, though it never names an alternative sibling tool or a when-not-to-use case.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: the endpoint bypasses Pydantic validation so the response shape is documented but unvalidated, and it notes the redaction default for contact details. No statement about pagination semantics beyond what the schema says, but the validation caveat is real added value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the resource and returned fields, then filters, then the implementation caveat. Three dense sentences, each carrying information. The 'Uses GET /performance/' tail is marginally redundant but not wasteful.

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 correctly compensates by enumerating the return fields. All 13 parameters are documented in the schema. What remains thin is how pagination and max_results interact at the tool boundary, though the schema parameters cover it individually.

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 would be 3, but the description adds meaning the schema does not: it explains that price_id values are what a reservation requires, tying the pricing output to a sibling workflow. Filter parameters are summarized rather than repeated, which is the right level.

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+resource ('Performances (dated showings)'), enumerates the returned fields (start/end, time zone, capacity, pricing per price band and variant), and lists the filter axes. An agent can distinguish this list endpoint from get_performance or list_events 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 states what can be filtered by (event, venue, date range, tags, days of week), which implies when the tool is applicable, but never gives explicit when-to-use/when-not guidance or names a preferred alternative such as get_performance for a single showing. Usage is inferred rather than directed.

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 readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds the underlying endpoint (GET /visit/) and the shape of the result set, which is useful, but says nothing about pagination semantics, volume, or rate limits beyond what the schema already states.

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, no filler, with the resource and result shape front-loaded before the filtering detail. Slightly dense packing of filter information into one sentence but still readable and appropriately sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does describe the composite structure returned, which is the main thing an agent needs. It stops short of documenting pagination/continuation behavior (next_page) that matters for a list endpoint, leaving a small gap.

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

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

Schema description coverage is 100%, so every parameter is already documented at the schema level, including defaults, ranges and the redaction behavior of include_contact_details. The description's mention of the buffer and time filter merely restates those parameters, adding no format or edge-case 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 and goes further by enumerating the returned composition (event, performance, ticket items, transaction with reference/lead booker/status). This clearly separates it from get_visit (single visit) and the list_events/list_performances 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?

The description explains what can be filtered (upcoming/past plus a buffer window) but never says when to choose this tool over get_visit or the other list_* siblings, nor any prerequisite or context of use. Usage has to be inferred from the name.

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