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

With no annotations, the description carries the behavioral burden and does so fairly well: it discloses the endpoint, the auth requirement (Bearer PERSONAL_OAUTH_TOKEN), and four specific 400 error codes. It does not explicitly state that nothing is persisted, though 'hypothetical' strongly implies it.

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 purpose and then uses labeled sections (ENDPOINT, PARAMETERS, ERRORS, AUTHENTICATION) that are easy to scan. Slightly verbose in restating parameters, but every block carries actionable 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?

No output schema exists, and the description stops at 'calculate hypothetical fees' without describing the returned fee breakdown; the errors and auth sections partially compensate. Given the tool's modest complexity and fully documented inputs, this is nearly complete but leaves the response shape implicit.

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% but the schema descriptions are terse ('Sales channel', 'Payment type'), so the description adds real semantic value by enumerating allowed values (payment_type: eventbrite/authnet/paypal; channel: web/atd; scope types) and the base_price 'CURRENCY,amount_in_cents' format. It stops short of documenting the scope identifier format.

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 ('Calculate hypothetical fees for ticket pricing') and further narrows it to Eventbrite fees based on scope, which cleanly separates it from data-retrieval siblings like list_fee_rates. The word 'hypothetical' also signals this is a non-mutating estimate.

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 'hypothetical fees' and the enumerated scope types (organization/event/ticket_class/assortment_plan), so an agent can infer this is a pre-pricing estimate. However, it never explicitly says when to use this versus list_fee_rates or other pricing-adjacent tools, nor any prerequisites or exclusions.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the series-parent side effect (canceling a parent cancels all occurrences), the order-state precondition, the 400 error codes, the boolean return, and the required Bearer OAuth token. The one notable gap is whether a cancellation is reversible.

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?

Labeled sections (REQUIREMENTS, SERIES PARENT EVENTS, RESPONSE, ERRORS, AUTHENTICATION) make it skimmable and the critical 'Cancel an Event' purpose is front-loaded. Minor redundancy: 'Returns boolean indicating success or failure' is restated by the RESPONSE block.

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

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

For a single-parameter mutation with no output schema and no annotations, the description covers preconditions, cascading series behavior, error modes, and auth. Only the reversibility/idempotency question remains unanswered, which is a modest 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% for the single event_id parameter, so the schema already documents it fully; the description only conveys it indirectly via the endpoint path. Baseline 3 applies when the schema does the heavy lifting.

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 ('Cancel an Event') and pins the API endpoint, which is unambiguous on its own. However, it does not distinguish itself from the sibling delete_event, leaving an agent to infer whether cancel and delete differ.

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 'CANCEL REQUIREMENTS' and 'POSSIBLE ERRORS' sections imply the preconditions for use (no pending/completed orders), which is useful context. But there is no explicit statement of when to choose cancel_event over delete_event or unpublish_event, so routing guidance is only implied.

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 no annotations, the description carries the full burden and does well: it enumerates the copied elements (payment options, payout method, refund policy, tax settings), lists concrete 400 error codes with meanings, notes auth via Bearer token, and states the return is the new Event object. It omits what is NOT copied (attendees, orders, ticket sales) and the initial state of the copy, which for a duplication tool is a 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?

Front-loaded first sentence, then clearly labeled sections (ENDPOINT, COPIED ELEMENTS, ERRORS, AUTHENTICATION). Slightly verbose with the raw endpoint path, but every block is scannable and useful; nothing is pure 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 mutating tool with no annotations and no output schema, the description covers origin, effect, error modes, auth, and return shape. It is only short of describing what is left behind by the copy, which would help an agent predict side effects.

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. However the error section adds real constraint semantics for the optional start/end parameters (end must be 1 minute to 365 days after start; start between now and 10 years out) that the schema does not express, so it earns above 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 specific verb and resource ('Copy an Event, creating duplicate with new Event ID') and distinguishes itself from the many event-mutating siblings (create_event, update_event, delete_event). The first sentence alone tells an agent exactly what the tool produces.

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 semantics of 'copy' versus 'create', but the description never states when to prefer this over create_event or update_event, nor what preconditions apply to the source event (e.g. must be unpublished). Adequate but inferential.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the HTTP endpoint, required bearer auth, a return shape (question array), and 400/403 error meanings, but it does not describe mutation side effects, reversibility, or permission/package requirements beyond the listed errors.

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

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

The description is front-loaded with the core action and then structured into endpoint, errors, and auth blocks. The extra sections are relevant, though the auth/error listing makes it longer than a minimal purpose statement.

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

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

For a create tool with a nested question object, no output schema, and no annotations, the description covers endpoint, auth, errors, and return type. However, it omits the expected shape of the nested question object and any package/permission details beyond the raw error codes.

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_id and the question object. The description repeats event_id in the endpoint path and adds no syntax or structural detail about the question object beyond what the schema provides.

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

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

The description states a specific verb and resource: "Create a custom question for an Event." This distinguishes it from default-question siblings at a high level, but it does not explicitly name or contrast with create_default_question or explain the custom-vs-default selection.

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 endpoint, errors, and authentication, but no when-to-use guidance, prerequisites, or alternatives. An agent must infer that this is for event-specific custom questions rather than default questions.

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?

No annotations, so the description carries the full burden. It does disclose authentication requirements (Bearer token) and two specific error codes (INSUFFICIENT_PACKAGE, NOT_ALLOWED), which adds useful operational context. However, it doesn't disclose mutation side effects, reversibility, or idempotency 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?

Front-loaded purpose sentence is good, but the ENDPOINT and ERRORS blocks are somewhat verbose and mix API reference details with tool description. The purpose statement is minimal and doesn't elaborate further.

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 a nested object parameter and no annotations or output schema, the description is adequate but incomplete: auth and errors are covered, but side effects and the nested question schema are not. The ENDPOINT line helps locate it in the API surface.

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 params (event_id, question) are documented in the schema. The description adds the endpoint path 'POST /events/{event_id}/canned_questions/' which clarifies the event_id usage, but provides no details on the nested question object structure. 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?

Clear verb+resource: 'Create a default Question for an Event.' Distinguishes from siblings like create_custom_question and update_default_question by naming the 'default' question type. However, it does not explain the distinction between a 'default' vs 'custom' question to help the agent choose.

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?

No guidance on when to use this vs create_custom_question or list_default_questions. The 'ERRORS' section lists failure modes but doesn't tell the agent when this tool is the right choice.

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 no annotations the description carries the full burden and largely succeeds: it discloses the Bearer PERSONAL_OAUTH_TOKEN requirement, character restrictions per code type, numeric ranges, and default semantics (empty date = immediately, empty end_date = event end_date, 0 = unlimited). It does not describe the creation side effects or response payload, which is a modest 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?

Front-loaded with the one-line purpose, then cleanly partitioned under ENDPOINT, DISCOUNT TYPES, DISCOUNT SCOPE, FIELDS and AUTHENTICATION headings. It is long, but the length is justified by a 12-parameter mutation; some field text restates schema descriptions with little added value.

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

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

For a 12-param mutation with no annotations and no output schema, the description supplies the endpoint, auth, type/scope combinatorics and field defaults that an agent needs to call it correctly. The main omission is any statement of what the call returns (e.g., created discount ID) and confirmation of non-reversible creation, which would complete the picture.

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?

Although schema coverage is 100% (baseline 3), the description adds substantial meaning the schema lacks: numeric ranges for amount_off (0.01-99999.99) and percent_off (1.00-100.00), the 2-decimal/event-currency constraint, the '0 = unlimited' and 'empty = all/immediately' defaults, and the interaction rules that decide scope from which of event_id/ticket_class_ids/ticket_group_id are supplied.

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

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

States a specific verb+resource ('Create a new Discount') and immediately disambiguates from siblings get_discount/update_discount/list_discounts/delete_discount by detailing the discount taxonomy (public/coded/access/hold) and scope rules. An agent can tell exactly what this tool produces without opening the schema.

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

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

The DISCOUNT TYPES and DISCOUNT SCOPE sections effectively tell the agent how to combine event_id, ticket_class_ids and ticket_group_id for each intent, and the AUTHENTICATION block names the required token. It stops short of explicit 'use this instead of X' routing, but the deployment guidance is rich.

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?

No annotations are present, so the description carries the full burden and does so well: it lists 13 specific 400 error codes documenting mutual-exclusion rules (listed/invite_only, listed/password, summary/description, online_event/venue_id), timezone consistency, no-venue and no-organizer failures, and states the required Bearer auth header.

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 purpose, then endpoint, then series mechanics, then parameters grouped by required/optional, then errors. The parameter enumeration partially duplicates the 100%-covered schema, but the error catalog and series explanation earn their space.

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 30-parameter mutation tool with no annotations and no output schema, the definition covers auth, defaults, deprecations, mutually exclusive combinations, supported locales, and failure modes. An agent has everything needed to construct a valid call.

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 adds real value by grouping required vs. optional, flagging description as DEPRECATED, noting summary's 140-character limit and HTML stripping, and surfacing interoperability constraints between parameters rather than restating types.

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 ('Create a new Event') with the endpoint, and goes further to explain the series-parent vs. occurrence distinction. That distinction reliably separates it from siblings like create_event_schedule and update_event.

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 recurring-event work: create the event with is_series=True as the series parent, then add occurrences via the Event Schedule API. It does not address when to prefer copy_event or how this differs from other creation paths, but the guidance for the complex case is strong.

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 no annotations, the description carries the full burden and does substantial work: it discloses the auth requirement (Bearer PERSONAL_OAUTH_TOKEN) and enumerates specific 400/403 failure modes (DTSTART_MISSING, RECURRENCE_RULE_DATES_NOT_IN_UTC, EXCEEDS_MAX_OCCURRENCES, NOT_AUTHORIZED). It omits idempotency, side effects on the parent, and 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?

Front-loads the one-line purpose and organizes the rest into labeled sections (endpoint, parameters, errors, auth), which is easy to scan. The PARAMETERS section largely duplicates the 100%-covered schema, so it earns its place only partially.

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 no annotations and no output schema, the description covers endpoint, auth, prerequisites, and error conditions, which is close to what an agent needs. It does not describe the return value or the effect on the parent event's existing schedule.

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 schema already documents all three parameters, making 3 the baseline. The description restates occurrence_duration and recurrence_rule and adds only 'with DTSTART' as marginal extra meaning over 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 ('Create an event schedule for series parent') and clarifies it adds occurrences according to a recurrence pattern. Clearly distinguishable from sibling event tools, though it doesn't explicitly name the closest alternative (e.g. update_event).

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?

Provides a key prerequisite ('Requires series parent event') and scopes the operation to series parents, which implies when it applies. However, it gives no explicit when-to-use vs when-not guidance or comparison to sibling tools like update_event or create_event.

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 no annotations present, the description carries the full burden and does it well: it discloses the max-of-100 constraint, the 1000 ticket-rule limit, the exact 400/403/404 error codes, and the required Bearer auth scheme. It falls short of describing the response shape or how capacity_total and quantity_total relate, but the operational constraints are unusually thorough.

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

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

The purpose sentence is front-loaded, followed by cleanly labeled ENDPOINT, ERRORS, and AUTHENTICATION blocks. The verbatim error dump is slightly heavy, but each block maps to information an agent actually needs before calling.

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 creation tool with no annotations and no output schema, the description supplies auth, endpoint, quota limits, and failure modes. The main gap is the absence of any indication of what a successful response contains, which the agent has to discover empirically.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters, and the description adds essentially no additional parameter-level meaning. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Create a new Inventory Tier for an Event') and pins the endpoint, so an agent knows exactly what operation this performs. It does not explicitly contrast itself with the sibling create_multiple_inventory_tiers, but the singular phrasing makes the distinction inferable.

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?

No statement of when to prefer this tool over its obvious alternative, create_multiple_inventory_tiers, or over update_inventory_tier. The 100-tier cap gives a hint about batching, but the agent must infer the single-vs-bulk routing decision on its own.

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 no annotations, the description carries the full burden and does well: it declares the required auth scope (event management permissions), the 100-tier per-event limit, the same-event constraint, and the 400/401/403/404 error semantics. It stops short of covering idempotency or rate limiting.

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

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

Front-loads the core action and endpoint, but the markdown scaffolding (four headers, a field list duplicating the schema, four error codes) makes it longer than necessary. Meaningful content is diluted by restatement.

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 no output schema and no annotations, the description supplies the essentials an agent needs: auth, hard limits, and failure modes. Only the response shape and pagination/batching behavior remain unaddressed.

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

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

Schema description coverage is 100%, so the baseline is 3. The field list (name, quantity, price, sales_start/end, min/max quantity) largely restates what the schema already exposes, adding only the note that name is required, so it does not materially extend parameter understanding.

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 (create) and resource (multiple inventory tiers) plus the endpoint and the bulk scope, which distinguishes it from the singular create_inventory_tier and update_multiple_inventory_tiers siblings. An agent can identify the operation 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?

Four explicit use cases (bulk setup, import, complex configs, reducing API calls) give clear context for when to reach for this tool. It does not, however, name the alternative (create_inventory_tier for a single tier) or state when not to use the bulk endpoint.

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 no annotations provided, the description carries the full burden. It discloses authentication requirements, the 403 error condition, and an important behavioral constraint that repeated creation is not allowed, but it does not describe the return behavior in 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?

The description is front-loaded with the core action, then concisely adds endpoint, constraints, errors, and authentication in clearly separated lines. Every sentence earns its place with no wasted language.

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

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

Given two required parameters and no output schema, the description covers endpoint, authentication, a critical usage constraint, and the main error case. It could optionally state what the tool returns, but it is otherwise complete for correct invocation.

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 both parameters are already documented in the input schema. The description implies source copying but adds no syntax or format detail beyond what the schema provides, making the baseline of 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?

The description gives a specific verb and resource ('Create Seat Map') and specifies the creation method ('by copying existing') and target scope ('for reserved seating event'). It clearly distinguishes the operation from sibling tools like list_seat_maps.

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 a key precondition: the event must be new reserved seating, and it warns that once created, it cannot be created again. This covers when and when-not to use the tool, though it does not name a specific alternative sibling 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?

No annotations are provided, so the description carries the full burden, and it partially discharges this by disclosing the endpoint, the 400 error codes (MISSING, INVALID), and the required Bearer token auth. It does not say what a successful response returns, whether creates are idempotent, or whether existing overrides are overwritten. With no annotations, this is a meaningful but incomplete 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?

The description is organized into labeled sections (ENDPOINT, PARAMETERS, ERRORS, AUTHENTICATION) with the purpose front-loaded. It is efficiently sized for a five-parameter mutation tool, though the schema restatement in PARAMETERS is somewhat redundant.

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

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

For a mutation tool with no annotations and no output schema, the description covers auth and error codes well, but it does not describe the return value or the shape of the required 'strings' array elements. An agent still lacks enough to construct the payload confidently.

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 restates each parameter and adds one genuinely useful note ('locale... uses event locale or default'), which exceeds the schema for that field, but it does not explain the structure of the required 'strings' objects.

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

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

The description states a specific verb and resource ('Create Text Overrides') and clarifies the scoping dimension ('Organization, Venue, or Event'), which is enough to distinguish it from the read counterpart get_text_overrides. However, it does not explicitly name or contrast with that sibling the way a fully differentiated definition would.

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 explicit when-to-use or when-not-to-use guidance, nor any mention of the alternative get_text_overrides for retrieving overrides. The only usage signal is implicit: the tool creates overrides scoped to an organization, venue, or event.

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 no annotations, the description carries the full burden and delivers auth requirements (Bearer token) plus a detailed error catalog (FREE_AND_COST, DONATION_AND_FREE, COST_GREATER_THAN_FEE, etc.) that reveals real behavioral constraints. It does not disclose idempotency, rate limits, or side effects, so it is thorough but not complete.

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 purpose and organized into labeled sections, which helps scanning. However it repeats the full parameter list already in the schema, adds a very long error catalog, and contradicts the schema by marking name and quantity_total as optional when the schema marks them required.

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 19-parameter mutation with no annotations and no output schema, the description supplies the type taxonomy, required-field behavior, tier/add-on flow, and failure modes an agent needs. It falls short only on response shape and edge behaviors like idempotency.

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 schema baseline is 3, but the description adds beyond it: type-specific semantics for quantity_total (null/0 behavior per free/paid/donation/tiered), the meaning of each ticket type, and even fields absent from the schema (sales_end_relative, sales_start_after, sorting, sales_channels). Minor inconsistency: it lists cost as string 'USD,4500' while the schema types it as a number in minor units.

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

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

States a specific verb+resource ('Create a new Ticket Class') and backs it with the endpoint (POST /events/{event_id}/ticket_classes/) and a definition of what a ticket class represents. The create verb plus the surrounding create/update/get/list sibling names make the operation unambiguous.

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

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

Provides clear conditional guidance: inventory_tier_id is required for tiered events after May 7 2020, and it spells out the add-on creation sequence (create tier with count_against_event_capacity=false, then supply inventory_tier_id). It never names alternatives like update_ticket_class explicitly, but the preconditions are strong.

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?

No annotations are provided, so the description carries the full burden. It notes the POST endpoint and bearer token auth requirement, which is useful. However, it does not disclose whether creation is idempotent, what happens on duplicate names, what the response contains (venue ID?), or side effects on the organization.

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

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

The description is organized with clear sections (purpose, endpoint, venue fields, authentication) and is front-loaded with the main action. It is somewhat verbose in listing all fields but remains scannable.

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 creation tool with no annotations and no output schema, the description covers the endpoint, required auth, and fields. However, it lacks a critical detail: what the response returns (e.g., the new venue's ID with which to later call get_venue or update_venue). Without an output schema, that gap matters.

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 parameters. The description lists venue fields including address sub-fields (address_1, city, region, postal_code, country), which adds some meaning beyond the schema's generic "Address object". Baseline 3 is appropriate since the schema does the heavy lifting, with slight extra value from the address detail.

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

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

The description states a specific verb+resource ("Create new Venue") and scopes it under an Organization, distinguishing it from siblings like list_venues, get_venue, and update_venue. It is clear what the tool does, though it could better differentiate from create_event/create_organization.

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?

No guidance on when to use this tool vs alternatives. It does not mention prerequisites beyond authentication, nor when a caller should prefer create_venue over other creation tools or how it relates to update_venue for modifying existing venues.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses the required Bearer token auth and the exact HTTP endpoint, which an agent cannot derive from the schema alone. However, it omits mutation-relevant behavior: what happens on duplicate endpoint_url, what the created object returns, or any 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?

Front-loaded with the action and endpoint, and the auth block is scannable. However, the sentence 'Webhook represents webhook associated with Organization' is tautological filler that adds nothing an agent can act 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?

The description supplies auth and endpoint context, which is valuable for a tool with no annotations and no output schema. It is still thin for a mutation tool: no note on the return payload, duplicate handling, or validation constraints on the actions array.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters including which are required. The description only references organization_id and adds no semantics for actions, event_id, or endpoint_url, so 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?

States a specific verb and resource ('Create a Webhook') and scopes it to an Organization ID, distinguishing it from the sibling read/create variants like list_webhooks and delete_webhook. It stops short of explicitly naming those siblings as alternatives, but the operation is unambiguous.

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

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

The description says nothing about when to create a webhook versus other options, nor any prerequisites (e.g., whether the organization must already have webhook capacity, or how this relates to delete_webhook/update variants). The only guidance is the auth requirement.

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 no annotations provided, the description carries the full behavioral burden and does real work: it discloses the auth requirement (Bearer PERSONAL_OAUTH_TOKEN) and concrete 403 NOT_AUTHORIZED and 404 NOT_FOUND failure modes, which an agent cannot get from the schema. It stops short of stating irreversibility or what the success response contains, which for a destructive verb is the one notable omission.

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 labeled sections (ENDPOINT, ERRORS, AUTHENTICATION) are front-loaded after the purpose sentence and make the critical facts scannable. The ALL-CAPS labels add slight visual overhead but every block carries distinct information, so nothing is wasted.

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

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

For a two-param destructive tool with no output schema and no annotations, the description supplies auth, error semantics, and the exact endpoint, which is enough for correct invocation. It would be fully complete with a note on reversibility/confirmation and the success return shape.

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% for both required params (event_id, question_id), and both are already documented in the schema. The endpoint line corroborates the path-parameter semantics but adds no format, constraint, or lookup detail beyond what the schema provides, 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 (Delete) and resource (custom Question), and the ENDPOINT line pins the exact scope to /events/{event_id}/questions/{question_id}/, which distinguishes it from the sibling delete_default_question by resource path. It never names that sibling or contrasts the two explicitly, so sibling differentiation is inferential rather than stated.

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 prerequisites beyond auth, and no mention of alternatives such as delete_default_question or how to first identify the question_id. The agent must infer usage entirely from the verb and endpoint.

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 no annotations, the description carries the full burden and discloses important behavior: the operation is a soft delete (deactivates rather than permanently removes), it requires a Bearer token, and it returns 404 if the event doesn't exist. It does not state what happens if the question itself is missing or whether the question remains retrievable, leaving some gaps.

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

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

The description is front-loaded with the core purpose, then structured into endpoint, behavior note, errors, and authentication. Every line adds useful operational detail with no redundant 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 two-parameter delete tool with no output schema or annotations, the description covers the endpoint, soft-delete behavior, error case, and authentication requirement. It is nearly complete, though the omission of handling for a missing question (vs. missing event) and any response details leaves a minor 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 both parameters are fully documented in the schema. The description adds no syntax, format, or meaning beyond what the schema already provides.

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

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

The description states a specific verb (Delete) and resource (Default Question) and clarifies the operation is a deactivation of a canned question. This distinguishes it from sibling tools like delete_custom_question and update_default_question.

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 name and the note that it deactivates a canned question, but there is no explicit when-to-use guidance, prerequisites, or named alternatives (e.g., update_default_question). An agent must infer the appropriate context.

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 no annotations, the description carries the full burden and does well: it discloses irreversibility ('Cannot be restored after deletion'), the usage precondition, the specific 400 error code an agent may receive, and the required bearer-token auth. It stops short of describing downstream effects (e.g., whether ticket classes referencing the discount are affected).

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

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

Front-loaded with the action, then cleanly sectioned into endpoint, constraint, errors, and auth. Each block carries information the agent needs; the formatting costs a few extra lines but no sentence is wasted.

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

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

For a destructive one-parameter tool with no annotations and no output schema, the description covers precondition, irreversibility, failure mode, and auth requirements. Only the post-deletion side effects on related resources are left unstated.

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 there is a single documented parameter, so the baseline is 3. The description only references discount_id implicitly via the endpoint path, adding no format or sourcing 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 ('Delete a Discount') and pins it to the exact endpoint DELETE /discounts/{discount_id}/, leaving no ambiguity about what gets acted on. It is trivially distinguishable from the get/create/update/list discount siblings.

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

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

Gives an explicit precondition and implicit when-not rule: 'Only unused discounts can be deleted,' reinforced by the DISCOUNT_CANNOT_BE_DELETED error. It does not name an alternative path for discounts that are in use (e.g., update_discount to deactivate), so the routing guidance is clear but not complete.

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?

No annotations are provided, so the description carries the full burden and does so thoroughly. It discloses destructive irreversibility, authentication requirements, return value, possible errors, and series-wide deletion 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?

The description is front-loaded with a warning and uses headings for structure, which helps scanning. However, the same deletion requirements and series constraints are repeated across multiple sections, making it longer than necessary.

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 destructive deletion tool with no output schema and only one input parameter, the description covers return shape, possible errors, authentication, preconditions, and series-parent consequences. An agent has enough information to invoke it safely and interpret results.

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

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

Schema description coverage is 100% and the single required event_id parameter is already documented in the schema. The description adds no extra syntax, format, or semantic detail beyond what the schema provides, 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 ('Delete an Event') with clear scope, but does not name or distinguish sibling alternatives such as cancel_event or unpublish_event. An agent can identify the action, though not why it would choose this over related 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?

Provides explicit preconditions for when deletion is permitted, including no pending/completed orders and valid series occurrence states. It does not compare alternatives or explicitly say when not to use this tool versus cancel_event, but the conditional context is 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?

With no annotations, the description carries the full behavioral burden and does so excellently: it lists the exact endpoint, authentication requirement, and detailed error conditions (HAS_ATTENDEES, IS_STARTED_AFTER, LAST_TICKET, HAS_SEAT_ASSIGNMENTS, NOT_AUTHORIZED, NOT_FOUND) that reveal critical prerequisites and restrictions. This is far beyond what a simple delete description usually provides.

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

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

The description is front-loaded with the core action and structured with clear headers for endpoint, errors, and authentication. The endpoint line is slightly redundant, but the bulleted error list is efficient and information-dense.

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 delete tool with no output schema, the description covers authentication and specific failure conditions well. It does not explicitly state irreversibility or success behavior, but these are largely implied by the operation itself and the absence of an output schema.

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

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

Schema description coverage is 100% for both required parameters, so the schema already documents them. The description adds no additional meaning about parameter format or constraints, 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?

The description states a specific verb ("Delete") and resource ("Inventory Tier"), making the operation unambiguous. It does not explicitly differentiate itself from sibling tools like update_inventory_tier or get_inventory_tier, but the verb alone is sufficient for an agent to distinguish 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?

No guidance is provided on when to use this tool versus alternatives, such as when to delete versus archive or update a tier. The error conditions hint at constraints, but they describe failure modes rather than usage guidelines.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the authentication requirement, which is useful, but says nothing about whether deletion is permanent/destructive, whether it requires ownership, or what error occurs if the ID is invalid. For a destructive operation with zero annotation coverage, this is a significant 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?

The description is front-loaded with the action, then endpoint and auth in clearly labeled sections. It is brief and free of filler, though the ALL-CAPS section headers are slightly heavy for a one-line 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?

For a simple single-parameter destructive tool with no output schema, the definition covers what the call does and how to authenticate, but omits critical context about irreversibility and permission requirements. Adequate but with clear gaps.

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

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

Schema coverage is 100% and only one parameter exists, so the schema already documents webhook_id. The endpoint path syntax reinforces that a single ID identifies the resource, adding minor value. A baseline 4 is appropriate given complete schema coverage and a single required param.

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?

Clear verb+resource ('Delete a Webhook by ID') and it specifies the endpoint. It distinguishes itself from create_webhook, list_webhooks, and update_webhook-style siblings by naming the delete action, though it doesn't explicitly point to alternatives or prerequisites.

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?

No when-to-use guidance, no conditions or warnings (e.g., irreversibility), and no reference to related tools like create_webhook or list_webhooks. The agent must infer usage entirely from the name and endpoint.

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?

No annotations provided, so the description carries the burden. It discloses what content is returned (endpoints, parameters, validation rules, error codes, data structures) and the size (6933 lines), which is meaningful context. However, it doesn't state the return format (single string blob? markdown?), whether it's paginated/truncated, or that it is read-only.

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 core purpose, and the parenthetical size note earns its place by hinting at payload volume.

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 zero-param, no-output-schema tool, the description covers what is returned, but omits format and potential token/size handling implications of a 6933-line return, which an agent consuming this content would need to know.

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

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

Zero parameters, so baseline is 4. The description correctly implies no parameters are needed since the full blueprint is always returned.

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 ('Returns') and resource ('Eventbrite API Blueprint documentation'), and quantifies the scope (6933 lines). It's clearly distinguishable from all sibling tools, which are concrete CRUD operations on Eventbrite entities, not documentation retrieval.

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?

No explicit when-to-use guidance or mention of alternatives. For a documentation-retrieval tool against a large API surface, an agent would benefit from knowing this is the reference source to consult before calling other tools, but the description offers no routing.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the private-visibility constraint, the OAuth bearer requirement, the one-attendee-per-ticket semantics, and non-obvious value conditions (barcodes null when printable tickets are off or delivery method mismatches). It stops short of documenting error behavior 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?

The first two sentences are well front-loaded and state the core operation. The remainder is a very long field/expansion reference dump; it substitutes for a missing output schema, but it is not tightly scoped for selection-time reading and buries the key constraints (privacy, auth) in the middle of the text.

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?

Because no output schema exists, the extensive field, cost, profile, address, and barcode documentation meaningfully fills that gap, and auth is specified. One gap: 'AVAILABLE EXPANSIONS' are listed but the input schema exposes no expand parameter, leaving the agent unsure how to request them.

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?

Both parameters are fully documented in the schema (100% coverage), so the baseline is 3. The description adds the endpoint path structure showing how event_id and attendee_id nest, but no extra syntax or format guidance for the parameters themselves.

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

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

States a specific verb and resource ('Retrieve an Attendee by Attendee ID') and even pins the exact endpoint, so the operation is unambiguous. The 'by Attendee ID' phrasing implicitly separates it from the bulk list_attendees sibling, though no sibling is named explicitly, which keeps it 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 only implied: the agent must already know an attendee_id to call this, and the privacy note ('only available to User and Order owner') gives a precondition. There is no explicit when-to-use vs. list_attendees guidance and no exclusions, so this is minimum-viable rather than clear routing 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?

No annotations are present, so the description carries the full burden: it discloses the HTTP method and endpoint (GET /reports/attendees/), a specific list of 400 errors, and the required authentication header, which are rich behavioral details not available elsewhere.

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

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

The description is well-structured with labeled sections (endpoint, errors, auth) and front-loads the core purpose. It is efficient, though the 'Same parameters as sales report' line could be replaced with direct parameter guidance to reduce cross-referencing.

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 should ideally explain return values, which it does not. However, it provides endpoint, error codes, and auth requirements that are essential for correct invocation, making it reasonably complete for a report-retrieval 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 five parameters (event_ids required, plus end_date, timezone, start_date, event_status). The description adds no parameter-specific meaning beyond pointing to another tool for shared parameters, so 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 states a specific verb (Retrieve) and resource (Attendee Report) plus the primary lookup key (Event ID or status). It distinguishes itself from sibling get_sales_report by name and by explicitly referencing it, though the audience/subject is not clarified beyond the title.

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 usage via 'by Event ID or status' and points to get_sales_report for shared parameters, but does not state when to use this tool over get_sales_report or list_attendees, nor any prerequisites beyond the auth token requirement.

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 no annotations, the description carries the full burden and does a solid job: it discloses the HTTP method (GET, i.e. read-only), the exact endpoint, the required bearer token, and the 403/404 failure modes. It stops short of describing the response shape or any rate/permission nuance beyond NOT_AUTHORIZED.

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 purpose, then cleanly sectioned into ENDPOINT, ERRORS, and AUTHENTICATION blocks that are easy to scan. Slightly boilerplate-heavy for a one-parameter read, but no sentence is wasted.

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

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

For a simple single-parameter GET with no output schema or annotations, the description supplies the endpoint, auth scheme, and error behavior, which is enough for an agent to call it correctly. The only gap is a description of the returned tier value, which is a minor omission.

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

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

Schema description coverage is 100% and the single event_id parameter is already documented as required in the schema. The description adds no format or syntax detail beyond what the structured field provides, 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 (Retrieve) and resource (capacity tier for an event), and explicitly distinguishes itself from the tiered-inventory sibling: 'Capacity tier for GA holds against event capacity (not tiered inventory).' An agent can separate this from get_inventory_tier without opening either schema.

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

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

The parenthetical scoping note tells the agent this applies to GA capacity rather than tiered inventory, which implicitly routes it away from get_inventory_tier. However, it never explicitly states when to prefer one over the other or any prerequisite conditions beyond the auth requirement.

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?

No annotations are provided, so the description carries the full burden. It does usefully disclose the HTTP endpoint and the required Bearer token authentication, which the schema does not. However, it says nothing about error behavior (missing ID), the shape of the returned category, or pagination/side effects, leaving real gaps for a tool with zero annotation coverage.

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 operation, then scoped with endpoint, domain definition, and auth in labeled blocks. Every block earns its place; the category definition is arguably extra but aids disambiguation from get_subcategory.

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

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

For a one-parameter read with no output schema, the description supplies the endpoint, auth requirement, and entity meaning, which is enough to invoke it correctly. The remaining gap is its relationship to get_subcategory and list_categories, which the sibling list makes relevant.

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 single parameter has 100% schema description coverage, so the baseline is 3. The description only restates that lookup is by ID and adds no format, constraint, or sourcing guidance beyond the schema.

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

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

States a specific verb and resource ('Get a category by ID') and adds a definition of what a category is (vertical: Music, Endurance), which helps distinguish it from the similarly-named get_subcategory and list_categories. It stops short of explicitly contrasting itself with those 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 'by ID' phrasing implies a direct-lookup use case, but there is no statement of when to use this versus list_categories (discovery) or get_subcategory (child entity). Usage is inferable but not guided.

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 no annotations, the description carries the full burden and mostly succeeds: it discloses the required Eventbrite API token, the REST endpoint, and the 401/403 failure modes. It omits any rate-limit or scoping caveats, but for a read-only identity call the auth and error disclosure is solid.

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?

Content is front-loaded with purpose before endpoint/auth/use-case/response detail, and every block is scannable. The repeated 'Get Current User' heading plus a Use Cases list with some near-duplicate bullets (check email, check permissions) adds mild padding that keeps it from a 5.

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 listing response fields (id, name, email, emails, image_id) in the description is exactly the right compensation, and error codes round it out. An agent has everything needed to call this correctly.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; per the rubric this is the baseline 4. The description correctly implies no inputs are needed.

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 — returns information about the currently authenticated user, explicitly qualified as 'the user whose API token is being used.' This distinguishes it from the sibling get_user, which takes an identifier rather than resolving the caller.

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?

Provides an explicit Use Cases list (verify token validity, fetch own ID for other calls, check permissions), which tells the agent when this tool is appropriate. It does not, however, name the alternative (get_user) or state when NOT to use this tool, so it stops short of the 5 benchmark.

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 no annotations, the description carries the full burden and does reasonably well: it discloses the HTTP endpoint, the 404/NOT_FOUND failure mode, and the bearer-token authentication requirement. It omits pagination, rate limits, and what the returned object contains, but the error and auth disclosure is real 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?

Labeled sections (description, ENDPOINT, ERRORS, AUTHENTICATION) make it skimmable and the core purpose is front-loaded. Nothing is padded, though the section headers add slight overhead for a two-parameter read 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?

Auth and the 404 path are covered, which suits a simple read, but with no output schema the description never indicates what a retrieved Custom Question contains. For a fetch tool whose return shape is undefined elsewhere, that is a noticeable 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 both parameters are already documented in the schema, and the description adds no format, path, or validation detail beyond them. Baseline 3 applies when the schema does the heavy lifting.

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 ('Retrieve') and resource ('Custom Question') scoped by ID, and the endpoint line confirms the exact operation. It does not differentiate itself from the sibling get_default_question, so an agent must infer the custom/default distinction from the name alone.

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 statement of when to use this tool versus list_custom_questions or get_default_question. The 'by ID' phrasing implies it fetches a known entity, but no alternatives or preconditions are named.

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

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

With no annotations, the description carries the full burden and does so reasonably: it discloses the auth requirement (Bearer PERSONAL_OAUTH_TOKEN), the HTTP endpoint, and the 404/NOT_FOUND failure mode. The one notable gap is that the 404 is scoped only to 'Event doesn't exist' — it says nothing about a missing question_id.

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 purpose followed by short labeled blocks (ENDPOINT, ERRORS, AUTHENTICATION). Every line is scannable and none 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?

There is no output schema, so the description is the only place to learn the return shape, yet it says nothing about what the retrieved question object contains. Errors and auth are covered, but the return-value gap is meaningful for a retrieval tool.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the 'email' example for question_id. The description 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?

The description states a specific verb and resource — 'Retrieve a Default Question by ID' — and the endpoint line confirms the target. It distinguishes itself from the create/update/delete/list default-question siblings, though it never explicitly contrasts with get_custom_question, leaving the 'default vs custom' distinction to inference.

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: it retrieves one question given an ID, so an agent can infer it is the single-item lookup counterpart to list_default_questions. There is no explicit when-to-use, no mention of when to prefer get_custom_question, and no prerequisite guidance beyond the auth note.

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?

No annotations are provided, so the description carries the full burden. It discloses authentication requirements (Bearer token) and expands on discount types and fields, which is useful. However, it doesn't state read-only nature, error behavior (e.g., 404 for missing ID), or response format. For a retrieval tool with no annotations, this is a significant 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?

The description is bloated with extensive field lists, discount type explanations, and expansions that are tangential to the core retrieval action. The purpose statement is front-loaded, but the bulk is unnecessary for guiding invocation. Every sentence does not earn 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 simple retrieval tool with one parameter and no output schema, the description is overkill on field details but under-specifies crucial behavioral aspects like read-only status, error handling, and response structure. With no annotations, it should compensate more effectively for the missing structured metadata.

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

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

Schema coverage is 100% for the single required parameter (discount_id), so the schema documents it fully. The description repeats 'Discount ID (required)' but adds no syntax or format details beyond the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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 clear verb (Retrieve) and resource (Discount by ID) and provides the exact endpoint. It distinguishes the resource from siblings like list_discounts and update_discount, though it doesn't explicitly name them. The core purpose is unmistakable.

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?

No guidance on when to use this tool versus list_discounts, create_discount, or update_discount. An agent is left to infer that this is for fetching a single known discount. No when-not-to-use or alternative routing is provided.

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?

No annotations are provided, so the description carries the full burden. It discloses the HTTP method and endpoint (GET /events/{event_id}/display_settings/) and the required authentication (Authorization: Bearer PERSONAL_OAUTH_TOKEN), which is genuinely useful behavioral context. However, it says nothing about error behavior, rate limiting, or what a missing event_id yields. Adequate but not rich.

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 purpose in one sentence, then uses short labeled sections (ENDPOINT, AUTHENTICATION). No filler. Slightly unconventional for a tool description, but every line carries 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?

For a simple one-parameter read tool with no output schema and no annotations, the description is roughly complete: it identifies the resource, endpoint, and auth. It omits any hint of what the response contains (e.g., name, color, layout fields) and any usage context relative to 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 there is a single required parameter already documented in the schema, so the baseline is 3. The description adds the endpoint path template which reinforces the param meaning, but does not add semantics 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 (Retrieve) and resource (Display Settings for an Event), and clearly scopes them to how the Event appears on the Event Listing page. This distinguishes it from sibling update_display_settings and from other get_* entity 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 implies a read operation for display settings but does not explicitly state when to use this tool versus update_display_settings or other event-related getters. Usage is inferable from the naming and the resource definition, but no explicit when/when-not guidance is 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?

No annotations are provided, so the description must carry the behavioral burden, and it does a lot: it documents the full field set, distinguishes public vs private fields (private only available to the authenticated user), and flags the deprecation/behavioral quirk where the summary occupies the description field. It also specifies the auth requirement. Missing rate limits and an explicit statement on pagination/error behavior keeps it from 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?

The core operation is front-loaded in one good sentence, but the bulk of the description is a very long field dump and expansion list that dwarfs the actual guidance. For a single-parameter retrieval tool this is bloated and the important behavioral note is buried mid-document.

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 must describe return values, and it enumerates the event object fields, marks public vs private, and lists all expansions with names and meanings. It also covers auth. It is essentially complete for calling the tool correctly, though the deprecation note could be clearer and error/rate behaviors are 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 coverage is 100% for the single eventId parameter, so the baseline is 3. The description adds no parameter syntax or format detail beyond reiterating 'by Event ID', and the ?expand= list, while useful, is really a return-value modifier rather than a parameter explanation.

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

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

States a specific verb and resource: 'Retrieve an Event by Event ID.' The endpoint line GET /events/{event_id}/ pins down the exact operation, and the distinction from siblings such as get_event_description and list_events is implicit in the ID-based retrieval plus the note about fetching the full HTML description separately.

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 one important routing decision—that get_event returns the summary in the description field and a separate call is needed for the full HTML description (implying get_event_description). But it offers no guidance on when to use this versus get_event_series, get_organization, or list_events, and gives no conditions or exclusions.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly: it documents the HTTP endpoint, the exact permission required (event.details:read), specific error codes with meanings, and the authentication scheme (Bearer PERSONAL_OAUTH_TOKEN). This is rich behavioral context well beyond what structured fields supply.

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

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

Front-loaded with the core purpose, then organized into labeled sections (ENDPOINT, PERMISSIONS, ERRORS, AUTHENTICATION) that make scanning efficient. Slightly verbose with its multi-section format, but every section is useful for correct invocation.

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

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

Given a single simple parameter, no output schema, and no annotations, the description is complete: it covers purpose, endpoint, return format, permissions, errors, and auth. An agent has everything needed to call it correctly.

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

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

Schema coverage is 100% (event_id is documented as 'Event ID (required)'), so the baseline is 3. The description adds the endpoint path showing event_id is a path parameter, but no additional syntax or constraints beyond that.

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

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

States a specific verb and resource: 'Retrieve full HTML description for an Event.' Clearly distinguishes from siblings like get_event, get_structured_content, and get_text_overrides by naming the exact sub-resource (description) and return format (HTML).

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?

Mentions it 'Works with events created using New or Classic Create,' implying a compatibility condition, but offers no explicit when-to-use-vs-alternatives guidance. An agent must infer that this is the tool for fetching description content as opposed to metadata (get_event) or structured content (get_structured_content).

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 no annotations, the description carries the full burden, and it does add real behavior: the HTTP verb/endpoint (GET /series/{id}/) implies a non-mutating read, and it explicitly states the required Authorization: Bearer PERSONAL_OAUTH_TOKEN header. However it says nothing about what happens on a missing/invalid ID, permission scope beyond the header, 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?

The purpose sentence is front-loaded and the ENDPOINT / AUTHENTICATION blocks are easy to scan. The labeled blocks are slightly formulaic but every line carries information, with 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 single-parameter read endpoint with a fully described schema, the definition supplies the missing operational context an agent needs: the endpoint path and the exact auth header. It is not exhaustive about errors or the returned payload, but no output schema exists and the tool is simple.

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 there is only one required parameter, so the schema already documents event_series_id fully. The description adds only the phrase 'by ID' and no format or example beyond that, which is the expected 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 specific verb and resource ('Retrieve parent Event Series by ID') and even defines the resource ('repeating Event with multiple dates'). It does not explicitly contrast with the nearest sibling (list_events_by_series), 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?

There is no when-to-use guidance and no mention of alternatives such as list_events_by_series or get_event. The only inference available is that you must already hold an Event Series ID, which is implied by the schema 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?

No annotations are provided, so the description carries the safety burden. It discloses the authentication requirement (Bearer token), which is useful, but does not state read-only nature explicitly or describe failure modes (e.g., 404 on unknown ID).

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?

Well-structured with clear sections (description, endpoint, auth) and front-loaded purpose. Slightly verbose with headers but no wasted sentences.

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 simple single-param read tool with no output schema, the description covers purpose, endpoint, and auth. It omits return value details, but the absence of an output schema means this is a minor 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 the schema already documents the single format_id parameter. The description adds no additional syntax or format detail beyond what the schema provides, making 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 ('Retrieve') and resource ('a Format by ID'), and clarifies what a Format is ('event type, e.g., seminar, workshop, concert'), which distinguishes it from sibling tools like get_venue or get_category.

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 naming the endpoint and required ID, but the description offers no explicit when-to-use guidance or mention of the sibling 'list_formats' as an alternative for enumeration.

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 no annotations, the description carries the full burden and does disclose the endpoint (GET, implying a safe read), the required authentication scheme (Bearer PERSONAL_OAUTH_TOKEN), and concrete error conditions (403 NOT_AUTHORIZED, 404 NOT_FOUND with the specific missing-entity cause). This is well beyond what the schema provides; only the response shape and any rate-limit behavior are unstated.

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 purpose, then organized into labeled ENDPOINT/ERRORS/AUTHENTICATION blocks. Every block carries actionable information for an agent, though the formatting is more verbose than necessary for a two-parameter lookup.

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 simple GET-by-ID tool with full parameter coverage, the description supplies endpoint, auth, and error semantics. Because there is no output schema and no annotation coverage, it could have described the returned tier fields, which leaves a modest gap.

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

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

Schema coverage is 100%, so both required parameters (event_id, inventory_tier_id) are already documented in the schema. The description adds no format, type, or sourcing guidance beyond restating the ID-based lookup, 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 states a specific verb (Retrieve), resource (Inventory Tier), and scoping qualifier (by ID for an Event), and even explains what the resource is ('controls capacity across multiple tickets. Supports GA holds'). An agent can distinguish it from list_inventory_tiers, create_inventory_tier, and update_inventory_tier 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?

Implied usage is clear from 'by ID' (a point lookup for a known inventory tier), but the description never states when to use this versus list_inventory_tiers or how to obtain the required IDs. No explicit alternatives or prerequisites are named.

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

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

With no annotations, the description carries the full behavioral burden; it does add useful context by disclosing the HTTP endpoint and the required Bearer authentication. However, it says nothing about what is returned (image bytes vs. URL/metadata), error behavior, or cache/rate characteristics, which matters for a retrieval tool with no output schema.

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

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

Front-loaded with the core action, then organized under ENDPOINT, PARAMETERS, and AUTHENTICATION headers. Slightly over-structured for a three-parameter get, but no sentence 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?

Auth requirement and endpoint are covered, which is valuable given no annotations. But for a retrieval tool with no output schema, the description never says what the caller receives back or how media is identified beyond the ID — a meaningful gap for an agent deciding how to use the result.

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 media_id, width, and height. The description's PARAMETERS block merely restates the schema text ("Thumbnail width/height") and adds no new meaning such as units, defaults, or aspect-ratio behavior. 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+resource ("Retrieve Media by ID") and clarifies what Media represents (an image for an Event listing), which helps an agent understand the resource. It does not, however, differentiate itself from the closely-named siblings upload_media and get_media_upload, so the boundary between retrieval and upload flows is left implicit.

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 guidance on when to use this tool versus siblings such as get_media_upload or upload_media. The agent must infer from the name alone that this retrieves already-uploaded media rather than inspecting an upload session.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the HTTP method and endpoint, authentication requirements, a detailed response field list with status values, and relevant error codes, giving an agent strong operational 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?

The description is front-loaded with the core purpose and then organized into useful sections for endpoint, authentication, use cases, response fields, and errors. It is longer than minimal, but most sections earn their place because there is no output 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?

With no output schema and no annotations, the description compensates by documenting authentication, the endpoint, response fields, status values, and error codes. An agent has enough information to invoke the tool and interpret common outcomes.

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 single upload_token parameter is already documented in the schema. The description mentions upload_token only indirectly in the response fields and error codes, adding little meaning beyond the schema's own explanation.

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

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

The description states a specific verb and resource: returns information about a media upload, including upload status and processing state, and gives the exact endpoint GET /media/upload/. It is clear what the tool does, but it does not explicitly differentiate itself from sibling tools such as get_media or upload_media.

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 Use Cases section gives clear contexts for calling the tool: checking upload status after initiating a media upload, verifying processing completion, getting a media ID, and monitoring progress. It does not explicitly name alternatives or state when not to use 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?

With no annotations, the description carries the full burden and does so well: it discloses the access-control constraint ('private - only available to User and Order owner'), the required Bearer authentication, and a concrete error behavior (ORDER_EXPIRED at 400). It omits rate limits and pagination behavior, but the behavioral coverage is notably richer than a bare read tool.

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?

Purpose and endpoint are front-loaded, then well-delimited sections follow. The lengthy field and expansion documentation is heavy but earns its place because there is no output schema to convey return shape; still, the volume is higher than strictly needed.

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 return fields, cost breakdown, and available expansions, plus auth and error conditions. An agent has everything needed to call and interpret this endpoint correctly.

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

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

Schema description coverage is 100% for the single order_id parameter, so the schema already documents it fully. The description adds no format or syntax detail beyond 'by Order ID', 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?

The opening line states a specific verb and resource scoped by identifier ('Retrieve an Order by Order ID'), which an agent can immediately distinguish from the list_orders sibling. The scope constraint is front-loaded and unambiguous.

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

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

It implicitly tells the agent this is the single-order-by-ID path and adds a routing hint ('Use Attendee object for attendee information'), but never explicitly contrasts itself with list_orders or state when-not to use it. 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?

With no annotations, the description carries the full burden and does reasonably well: it discloses the HTTP endpoint and the required Authorization Bearer token. It doesn't explicitly confirm read-only/no-side-effects, but "Get" plus the endpoint makes that unambiguous.

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 one-line purpose, then labeled sections. The field enumeration is a bit long for a trivial get, but it earns its place because no output schema exists.

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?

Since there is no output schema, enumerating ORGANIZATION FIELDS (id, name, image_id, vertical) usefully tells the agent what comes back, and the auth requirement is stated. A note on error behavior for an invalid ID is the only real omission.

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?

There is a single parameter and schema description coverage is 100%, so the schema already documents organization_id. The description adds nothing beyond the name/type that the schema provides, 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?

Description states a specific verb+resource ("Get an Organization by ID") and the endpoint, making the single-object fetch clear. It implicitly distinguishes itself from the sibling list_organizations via "by ID," though it never names that 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?

Usage is only implied: an agent infers it should call this when it holds an organization_id. There is no explicit when-to-use/when-not guidance and no pointer to list_organizations as the 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?

With no annotations, the description carries the full burden, and it does meaningful work: the GET endpoint implies a non-destructive read, and it discloses the auth requirement (Bearer PERSONAL_OAUTH_TOKEN) plus concrete 400 error codes. It still omits pagination, rate limits, and response shape, so it is not fully transparent.

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 purpose, then cleanly sectioned into ENDPOINT, PARAMETERS, ERRORS, and AUTHENTICATION. The structure is easy to scan; the only cost is mild redundancy between the parameter block and the schema it restates.

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 tool with no output schema and no annotations, the description supplies endpoint, full parameter semantics, error codes, and auth - everything needed to make a correct call. It stops short of describing the report payload returned, which is the one remaining gap.

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

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

Schema coverage is 100% but carries no enums (0 enums reported), so the description's enumeration of legal values for event_status (all/live/ended), filter_by, group_by, date_facet, and the timezone default adds real meaning beyond the schema. The extra parameters it documents (filter_by, group_by, period, date_facet) are not even in the input schema, which is useful but leaves their exact interaction unexplained.

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

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

States a specific verb and resource ('Retrieve a sales Report') and scopes it by Event ID or status, which is clear. It does not, however, explicitly distinguish itself from the sibling get_attendee_report, so the agent must infer the sales-vs-attendee distinction on its own.

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 or when-not-to-use guidance, no prerequisites, and no mention of the alternative report tool. The parameter list implies a filtered lookup, but the description never tells the agent under what circumstances this tool is the right choice.

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?

No annotations are provided, so the description carries the full burden. It discloses the prerequisite (must publish first), the authentication requirement (Bearer token), error conditions (NOT_AUTHORIZED, ARGUMENTS_ERROR), and the general response structure. This is rich context beyond what the schema provides. It could be improved by stating whether this is a read-only operation (implied but not explicit) and rate limit info, but overall it is quite thorough for a read tool.

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

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

The description is well-structured with clear sections (ENDPOINT, PURPOSE, RESPONSE, ERRORS, AUTHENTICATION) and front-loaded key information. It is slightly verbose with some repetition (e.g., 'latest published' appears twice), but every sentence adds useful value.

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

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

For a read tool with no output schema, the description compensates by listing the response fields (page_version_number, modules, widgets) and error cases. It covers authentication and prerequisites. However, without an output schema, it could provide more detail on the structure of modules/widgets or pagination, but 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 both parameters (event_id required, purpose with default). The description adds the meaning of the purpose values (listing vs digital_content) and reinforces the event_id requirement. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb and resource: 'Retrieve latest published structured content for event.' The 'purpose' parameter values (listing vs digital_content) clarify what kind of content is returned, and the relationship to set_structured_content is implied via 'Must publish version first (publish=true in set).' This distinguishes it from most siblings like get_event_description.

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 prerequisite (publish version first) and the two purposes for using this tool. However, it does not explicitly state when to use this vs alternatives like get_event_description, which likely returns a different form of event 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?

With no annotations, the description carries the full burden, and it does disclose the concrete endpoint (GET /subcategories/{subcategory_id}/) and the required Authorization: Bearer header — genuinely useful context. It stops short of describing failure modes (e.g., unknown ID) or the response payload.

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 labeled blocks, front-loaded with the purpose and then the endpoint and auth. Every line carries information; nothing is padded.

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

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

For a single-parameter read tool with no output schema, the definition covers purpose, endpoint, and authentication. The remaining gap — return value structure and error behavior — is minor given the tool's simplicity.

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 a single parameter already documented as 'Subcategory ID (required)'. The description adds no format, source, or lookup information 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 gives a specific verb ('Retrieve') and resource ('a Subcategory by ID'), making the operation unambiguous. It does not explicitly differentiate itself from the sibling list_subcategories, but the 'by ID' framing implicitly separates the single-fetch case.

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 statement of when to use this tool versus alternatives such as list_subcategories, nor any prerequisites beyond the auth note. Usage must be inferred entirely from the parameter name.

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?

No annotations are provided, so the description carries the full burden. It discloses authentication requirements and potential error codes (MISSING, INVALID), which is helpful. But it omits whether the operation is read-only (implied by 'Retrieve' but not stated), pagination behavior, or what happens if no overrides exist.

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

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

The description is structured with clear sections (endpoint, parameters, errors, authentication) and is front-loaded with the primary purpose. It is efficient and avoids unnecessary verbosity, though the parameter list duplicates schema 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?

Given the tool's relative simplicity (5 parameters, 1 required, no output schema), the description covers authentication, error codes, and basic parameters. However, for a retrieval tool with no annotations, it lacks details on return format, pagination, and the exact structure of returned overrides, leaving some gaps.

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 parameters. The description lists parameters with examples (e.g., locale en_US, text codes like tickets_not_yet_on_sale), adding some illustrative value but no syntax or format details 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 states a specific verb and resource ('Retrieve Text Overrides') and adds useful context ('Customize strings shown during ticket sales per event'). However, it doesn't distinguish this tool from the sibling 'create_text_overrides', leaving the read-vs-write boundary implicit.

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?

No explicit guidance is given on when to use this tool versus alternatives. The description mentions customization during ticket sales but doesn't explain when to retrieve overrides or how to select between this and create_text_overrides.

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?

No annotations, so the description carries the full burden and does well: it enumerates the settings returned (confirmation message, instructions, refund requests, attendee updates, survey info), lists concrete error codes (400 FIELD_INVALID, 403 NOT_AUTHORIZED, 404 NOT_FOUND), and states the auth requirement (Bearer PERSONAL_OAUTH_TOKEN). It stops short of describing response shape or pagination, but for a single-resource GET this is substantial.

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 one-line purpose, then structured blocks (ENDPOINT, settings list, ERRORS, AUTHENTICATION). Some header labels are verbose but each line is informative; 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 1-param read tool with no output schema, the description supplies endpoint, returned setting categories, error codes, and auth — enough for an agent to invoke it correctly. Return value structure is the only notable omission.

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?

Only one parameter exists and the schema documents it at 100% coverage ('Event ID (required)'). The description adds no format or constraint 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?

States a specific verb (Retrieve) and resource (Ticket Buyer Settings) scoped by Event, and pins the exact endpoint GET /events/{event_id}/ticket_buyer_settings/. Sibling update_ticket_buyer_settings is clearly distinguished by the read verb.

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 read-only endpoint and the settings enumeration, but no explicit when-to-use or when-not-to-use guidance is given relative to siblings like update_ticket_buyer_settings or get_event.

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?

No annotations exist, so the description carries the full burden, and it does substantial work: it states the auth requirement (Bearer PERSONAL_OAUTH_TOKEN), splits fields into public vs organization-member-only visibility, and lists a 400 error. It omits rate limits and confirms nothing about side effects, but the auth and field-visibility disclosures are solid for a read tool.

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 purpose is correctly front-loaded and the description is organized under clear headers (endpoint, types, fields, expansions, errors, auth). However the two long field inventories make it very verbose for a simple by-ID lookup; much of that content is reference data rather than essential selection guidance.

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, documenting the returned Ticket Class fields is genuinely necessary and the description does so thoroughly, plus auth, expansions, and an error case. The main gap is that the listed AUTO_HIDE_NOT_SET 400 error looks like a mutation error and is likely irrelevant to a GET, slightly muddying completeness.

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

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

Schema coverage is 100% and the two path parameters are self-documenting, so baseline would be 3. The description goes further by documenting an expansion query parameter (?expand=event|image) that is absent from the schema entirely, adding real meaning beyond the structured fields.

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 opening sentence gives a specific verb (Retrieve) and resource (Ticket Class) scoped by ID, so an agent knows this is a single-object lookup rather than the list_ticket_classes variant. It does not explicitly name the sibling alternatives, but the by-ID scoping is enough to distinguish 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?

There is no explicit when-to-use vs alternatives (e.g. list_ticket_classes), but the description does route optional usage through the 'AVAILABLE EXPANSIONS: Use ?expand=...' section, which tells the agent how to enrich the response. That is implicit guidance rather than a stated selection rule.

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?

No annotations are provided, so the description carries the full burden. It does add useful operational context — the exact endpoint and the required Authorization: Bearer PERSONAL_OAUTH_TOKEN header — but says nothing about rate limits, response shape, or what happens if the token is missing or expired.

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?

Short and front-loaded, with labeled sections that make the endpoint and auth requirements scannable. The opening line and 'Returns current user details' are largely redundant restatements, a minor waste.

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 no-param read tool with no output schema and no annotations, the description supplies endpoint and auth, which is the most important missing piece. It still omits what fields the user object contains and how it differs from get_current_user, leaving the agent under-informed for selection.

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 there is nothing for the description to disambiguate and the schema is trivially complete. Baseline for a no-parameter tool.

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 clear verb and resource ('Get authenticated user information') and pins the exact endpoint GET /users/me/. However, it does nothing to separate itself from the sibling get_current_user, which appears to cover the same 'who am I' resource — the agent gets no basis for choosing between them.

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 statement of when to use this tool, when not to, or which sibling to prefer. Given that get_current_user is a near-identical sibling, the absence of routing guidance is a real gap rather than a stylistic one.

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?

No annotations are provided, so the description carries the burden, and it does deliver the key behavioral fact: the call requires an Authorization: Bearer PERSONAL_OAUTH_TOKEN header. It also confirms this is a pure read (Retrieve) and enumerates the returned fields, though it says nothing about 404/precondition 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?

Front-loaded with the one-line purpose, then clearly labeled ENDPOINT, VENUE FIELDS, and AUTHENTICATION sections. The field list is longer than strictly necessary but earns its place as a stand-in for the absent output schema; no filler sentences.

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 and no annotations, the description usefully supplies the return shape (id, name, address, age_restriction, capacity, latitude, longitude), a domain note that venues are grouped by Organization, and the auth requirement. It is nearly sufficient; only error/not-found behavior and the exact ID format are missing.

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

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

Schema description coverage is already 100% for the single venue_id parameter, so the schema fully documents the input's format expectation. The description adds no extra semantics about the identifier (e.g., whether it is the numeric ID or a slug) beyond restating the field list of the entity, which is response data, not parameter guidance. Baseline 3 when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Retrieve a Venue by ID') plus the exact endpoint GET /venues/{venue_id}/, so the agent knows precisely what this does and that it is a single-resource fetch rather than a list.

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 by the name and the 'by ID' phrasing; there is no explicit statement of when to prefer this over list_venues or what happens when the ID is unknown. A capable agent can infer the singleton-vs-list split, but nothing in the text routes it.

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