eventbrite

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

Annotations supply only destructiveHint=true, so the description carries most of the burden, and it does add real value by enumerating the copied configuration. However, it omits important behavioral facts: whether the new event starts as a draft or published, whether permissions/scopes are required, and why a copy is flagged destructive. The page's POST /events/{event_id}/copy/ reference is a useful pointer but not behavioral detail.

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

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

Two sentences, front-loaded with the core action and scope, with the endpoint appended for orientation. Dense but each clause earns its place; the only mild redundancy is the parenthetical list echoing what the title already implies.

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 should tell the agent what comes back, and it only says 'a new ID' without specifying the response shape or how to fetch/publish the resulting event. For a mutation tool with a single annotation this leaves a meaningful 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 all six parameters including formats and the UTC pattern. The description only gestures at name and dates ('optionally with a new name and dates') and says nothing about summary or timezone, so it adds little beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('Duplicate an event') and enumerates exactly what is carried over (tickets, payment options, refund policy, tax settings), so an agent can separate it from eventbrite_create_event without opening the schema. The 'into a new event with a new ID' clause makes the outcome unambiguous.

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

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

Usage is only implied: the agent can infer 'use this instead of create_event when you want an existing event's configuration reused', but the description never says so explicitly, nor does it name create_event as the alternative. The optional name/dates note is context, not 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?

With only destructiveHint=true in the annotations, the description must carry the behavioral burden. It does not explain the implications of creating a discount (e.g., that it is a write operation, that it may affect sales, or whether it can be deleted), nor does it mention any side effects or permission requirements. The destructive hint is present but the description adds little to clarify the risk or reversibility.

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 concise and front-loaded, packing three sentences with distinct information: the three discount types, the scoping rules, and the API endpoint. Every sentence earns its place, though the final API endpoint line may be more technical detail than needed for an AI agent.

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

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

For a creation tool with 11 parameters, a required-field set, and no output schema, the description covers the core type/scope semantics but omits important behavioral details like permission requirements, error handling, or what happens on success (e.g., returned ID). Given the lack of annotations beyond destructiveHint, more context on safety and side effects would be expected.

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 high-level scope semantics for event_id and ticket_group_id, which is slightly more than the schema's individual parameter descriptions, but it does not clarify the constraints between parameters (e.g., ticket_class_ids only with event_id, or mutual exclusivity of amount_off and percent_off) beyond what the schema already states.

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

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

The description names the specific verb (create) and the three resource variants it produces (promo code, public discount, access code), mapping each to the enum value of the 'type' parameter. It distinguishes itself from the sibling eventbrite_update_discount and eventbrite_list_discounts by explicitly being the creation tool for all three discount kinds.

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 provides clear context for the scoping logic: event_id (+ticket_class_ids) for one event, ticket_group_id for a group, neither for organization-wide. However, it does not explicitly state when to use this tool versus eventbrite_update_discount, nor does it mention any prerequisites such as previously listing events or ticket classes.

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

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

Annotations only supply destructiveHint=true and a title, so the description carries most of the behavioral burden — it does this well by disclosing the DRAFT state, invisibility until publish, and the ticket prerequisite. It omits any mention of return value (the created event's ID) or whether the operation is idempotent, keeping it short of a 5.

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

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

Two front-loaded sentences plus the endpoint reference, with zero filler. State, prerequisite, and API path are delivered in order of importance.

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 20-parameter creation tool with no output schema, the description covers the critical state semantics and workflow sequencing. It could note what the call returns (the new event ID needed for subsequent calls), but nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100% and every one of the 20 parameters is documented in the schema itself, including mutual exclusions (invite_only vs listed, online_event vs venue_id). The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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

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

States a specific verb+resource ('Create a new event') and scopes it precisely as a DRAFT, explicitly contrasting with the publish step. An agent can distinguish this from eventbrite_publish_event and eventbrite_update_event without opening any 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?

Gives clear workflow context: the event is not visible/on sale until eventbrite_publish_event, and tickets must be added via eventbrite_create_ticket_class before publishing. It names the related tools but does not explicitly compare against eventbrite_copy_event or state when a draft is preferable over other creation paths.

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

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

Annotations declare destructiveHint=true, and the description does not contradict that. It adds the endpoint and paid/free requirements, but does not explain side effects, auth needs, or what the destructive hint means for a create operation. With annotation coverage present, this is moderately useful.

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 fragments, front-loaded with the core action and the two main configuration paths. No wasted words.

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

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

Given 16 parameters and a destructive mutation context, the description is very brief; it does not mention the output/return or many optional parameters. The 100% schema coverage compensates substantially, but an agent lacks behavioral context beyond the annotations.

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 16 parameters. The description reinforces cost formatting and the free/cost pairing, but adds no syntax or constraints beyond the schema.

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

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

Specific verb 'Add' plus resource 'ticket type' to an event; clearly a creation tool distinct from sibling update/list tools. No ambiguity for 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?

Provides conditional setup for paid (`cost` + `capacity`) and free (`free=true` + `capacity`) tickets, which directly guides invocation. It does not mention alternatives like update_ticket_class or when not to use, so not a 5.

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

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

Annotations supply destructiveHint=true, so the mutating nature is already flagged; the description adds the concrete POST /organizations/{organization_id}/venues/ route, which discloses that the operation is org-scoped and path-parameterized. However, it says nothing about permission requirements, whether the creation is idempotent, or behavior on duplicate names. Adds modest value over annotations, no contradiction.

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

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

One sentence plus a terse endpoint reference, front-loaded on the create action. Nothing is wasted, though the endpoint fragment is somewhat redundant with the one-line summary rather than adding new 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 14-parameter create tool with full schema coverage and no output schema, the description does not need to re-document fields or return shape. It covers the essential framing (new venue under an org, usable as venue_id) and the backing route. It could have noted the required organization_id/name pairing or that the created venue ID is what gets reused, but the essentials are present.

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

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

Schema description coverage is 100% across all 14 properties, so the schema already documents every field including the organization_id caveat. The description only restates organization scoping implicitly through the URL template and adds no syntax or format guidance beyond it. 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 ('Save a new venue under an organization') plus the downstream purpose ('to use as an event's venue_id') and the exact API route. That is enough to separate it from list_venues or create_event without opening a schema. It stops short of explicitly contrasting with a sibling (e.g. organizer vs organization scoping), so 4 rather than 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 phrase 'to use as an event's venue_id' hints that this is a prerequisite step before event creation, but there is no explicit when-to-use, when-not-to-use, or prerequisite statement. No mention of needing an existing organization_id first, or of the create-then-list workflow. Implied context only.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value by disclosing what the response contains (check-in state, barcodes[].status, answers, cost breakdown) and the underlying REST endpoint, which goes beyond the annotation.

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 verb and resource, then the notable return fields. No filler or redundancy.

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

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

With no output schema, the description usefully previews the returned fields, and readOnlyHint covers the safety aspect. It is largely complete for a simple two-required-parameter lookup, though it could note that the attendee must belong to the given event.

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

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

Schema description coverage is 100%, so event_id, attendee_id, and expand are already documented in the schema. The description adds only the endpoint template, which weakly reinforces that both IDs are path parameters. 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 gives a specific verb and resource ('Fetch one attendee of an event') and enumerates the notable payload contents. It implicitly distinguishes itself from list_attendees via 'one attendee', but does not explicitly name or route against its 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?

Usage is implied by 'one attendee' versus the sibling list tools, but there is no explicit when-to-use, when-not-to-use, or alternative tool callout. An agent can infer the scenario but receives no 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?

readOnlyHint=true already tells the agent this is a safe read. The description adds that it is a GET reporting endpoint over one or more events and that results are bucketed/groupable, but says nothing about pagination, rate limits, data freshness, or response size — moderate added value given annotations carry the safety profile.

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

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

A single front-loaded sentence conveys the resource, the metrics, and the grouping/bucketing behavior. The trailing 'Eventbrite: GET /reports/attendees/' is low-value implementation trivia 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?

With 8 fully documented parameters, a required event_ids array, and no output schema, the description gives enough to call the tool correctly and hints at the shape of the result (counts per bucket). Only the lack of output-format detail and alternative routing keeps it below 5.

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

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

Schema description coverage is 100%, so all 8 parameters (including the three enums) are already documented in the schema. The description's mention of time buckets and optional grouping lightly contextualizes date_facet and group_by but adds no format or syntax 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+resource (attendee report) and enumerates the metrics returned (attendees and orders per time bucket, optionally grouped), which distinguishes it from generic list tools. It does not explicitly distinguish itself from the close sibling eventbrite_get_sales_report, 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, no exclusions, and no pointer to alternatives such as eventbrite_get_sales_report or eventbrite_list_attendees. Usage is only implied by the report semantics.

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

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

Annotations declare readOnlyHint=true and the description reinforces this by mapping to the read-only GET endpoint, so the safety profile is consistent and clear. It also discloses the concrete return fields (capacity_total, capacity_sold, capacity_pending, quantity_total, capacity holds), which is real behavioral value beyond the annotations, though there are no notes on auth scope, rate limits or error conditions.

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 short, front-loaded sentences: what is fetched first, the underlying endpoint second. Nothing is wasted, though the raw REST path adds marginal value for an agent that calls the tool rather than the HTTP endpoint.

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 enumeration of returned capacity fields does meaningful work in telling the agent what to expect. For a single-parameter read-only lookup whose safety profile is already covered by annotations, this is close to 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% for the single parameter (event_id is documented in-schema), so the baseline is 3. The description adds no format or constraint detail beyond what the schema already provides, and does not need to for a single ID field.

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

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

States a specific verb (Fetch) and resource (the event capacity tier), and enumerates the returned quantities, so the agent knows exactly what data comes back. It does not explicitly differentiate itself from nearby siblings such as eventbrite_list_inventory_tiers or eventbrite_get_event, 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 statement of when to use this tool versus alternatives, and no prerequisites or conditions are given. Usage can only be inferred from the phrase 'event capacity tier' and the required event_id.

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

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

The readOnlyHint annotation already declares this a safe read operation, so the description's main added value is disclosing the returned field set and the expand option. It says nothing about auth scopes, rate limits, or behavior with a nonexistent event_id, which would be the sort of extra context that raises this above baseline.

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, front-loaded sentences with no filler: purpose and return fields first, the expand hint second, the underlying endpoint last. Every sentence earns its place.

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

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

With no output schema, the description usefully enumerates the shape of the response, compensating for that gap. Only minor omissions remain (pagination is irrelevant for a single fetch, and error behavior is unstated), so it is nearly complete for a 2-parameter read tool.

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

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

Schema coverage is 100% and both parameters are documented there, so the schema carries the load. The description's expand example ('venue,ticket_classes') roughly duplicates the example already in the schema description, adding little new meaning; 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 ('Fetch one event') and enumerates the returned fields (name, summary, start/end, status, capacity, venue_id, listing settings), which separates it from list_events. It does not explicitly name the nearest siblings (e.g. get_event_description, get_capacity) that return overlapping data, so the differentiation is only 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?

The only guidance is 'Use expand=venue,ticket_classes for more', which tells the agent how to get richer output but not when this tool is preferable to list_events, get_event_description, or get_capacity. No exclusions or prerequisites are given, so usage 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description usefully adds that the return is fully rendered HTML including summary and page modules, which is behavior beyond the annotation, but it says nothing about auth requirements, pagination, or fallback when an event has no description.

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

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

Two short sentences, front-loaded with the action and content scope, with no padding. The trailing REST endpoint mapping is mildly redundant but serves developer traceability.

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 with no output schema, the description adequately conveys what is returned ('fully rendered HTML description... summary plus the page modules'). Only edge cases such as missing or empty descriptions are 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% for the single event_id parameter, so the schema fully documents it. The description adds no format or sourcing 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?

The description names a specific verb ('Fetch') and resource ('fully rendered HTML description of an event') and clarifies the content scope ('summary plus the page modules'). It does not explicitly contrast with the sibling eventbrite_get_event, so an agent must infer the distinction between the event record and its rendered 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?

There is no explicit statement of when to use this tool versus eventbrite_get_event or when not to use it. Usage is only weakly implied by the content-type clause; no prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds non-obvious value by clarifying that the result is scoped to whoever owns the token and that the call is cheap enough to use as a credential probe; it stops short of stating rate limits or error behavior.

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

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

Three short sentences, front-loaded with the resource, then the recommended use, then the API mapping. No sentence is padding and nothing is buried.

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

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

For a zero-parameter read tool with no output schema, the description supplies everything an agent needs: what it returns, that it is token-scoped, and that it is safe/cheap to call. Annotations handle the read-only guarantee.

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 no parameters, so the baseline is 4. The description correctly implies no input is needed and instead describes the output shape (name, emails), which is the useful information here.

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

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

States a specific verb (Fetch) and resource (the Eventbrite user the token belongs to), and names the returned fields (name, emails). It is the only identity/token-scoped tool among the siblings, so it is trivially distinguishable from the event/attendee/venue 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?

Explicitly frames the use case: 'A cheap way to confirm the token works,' which tells the agent when to reach for it. It does not name alternatives or exclusions, but with zero parameters and a unique identity scope there is little to disambiguate against.

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

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

The readOnlyHint annotation already establishes this is a safe read. The description adds nothing behavioral beyond that: no auth requirements, no not-found/error behavior, no rate limits, and the 'GET /orders/{order_id}/' line merely restates the read semantics the annotation already declares.

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

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

Three short sentences, zero filler, with the core operation front-loaded and the optional expand guidance immediately after. Every sentence is functional.

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 2-parameter read tool this is close to adequate, but with no output schema the description says nothing about what an order object contains or what happens if the order_id is invalid, leaving the agent to guess at the response 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 coverage is 100%, so the baseline is 3, but the description contributes a concrete, practically relevant expansion example (attendees,event) that differs from and supplements the schema's venue,organizer,ticket_classes example. This adds real value for the expand parameter.

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

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

States a specific verb and resource ('Fetch one order') and the singular framing implicitly separates it from the sibling list_orders. It does not explicitly name that sibling, so it falls 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?

It tells the agent how to enrich the response with expand=attendees,event, but gives no guidance on when to use this tool versus eventbrite_list_orders or eventbrite_get_attendee. Usage is implied by the 'one order' framing 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?

readOnlyHint=true already tells the agent this is a safe read, so the description only needs to add context. It discloses the metric set, optional grouping, and the underlying Eventbrite endpoint, but says nothing about pagination, rate limits, or the shape of the response despite there being 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?

One dense sentence with the payload description front-loaded; every clause carries meaning. The trailing 'Eventbrite: GET /reports/sales/.' is mildly extraneous but useful as a mapping hint.

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 an 8-parameter read tool with no output schema, the description conveys what comes back at a high level but omits return format details and any guidance on how period/date_facet/start_date/end_date interact. Adequate, 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 description coverage is 100%, so all 8 parameters are already documented, which sets the baseline at 3. The description loosely echoes group_by ('by ticket, payment method, country, ...') and date_facet ('per time bucket') but adds no format or interaction 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?

The description names a specific resource ('Sales report for one or more events') and enumerates the returned metrics (gross, net, fees, royalty, quantity) per time bucket, which distinguishes it from list/get tools. It does not explicitly distinguish itself from the close sibling eventbrite_get_attendee_report, so it falls 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 explicit when-to-use statement, no when-not-to-use, and no mention of alternatives such as eventbrite_get_attendee_report. An agent must infer that this is the financial-metrics view versus a per-attendee listing.

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

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

Annotations only supply readOnlyHint=true; the description adds substantive behavioral context by enumerating the per-attendee fields returned (checked_in, cancelled, refunded, status, ticket_class_name, profile, barcodes) and noting barcode status values. It does not cover pagination semantics or rate limits, but it adds genuine value beyond the annotation.

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 tightly packed sentences: scope and granularity first, then the returned fields, then the invocation constraint and REST endpoints. No filler; every clause carries information an agent needs.

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

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

With no output schema, the description helpfully enumerates the return fields and both endpoints, and the schema covers pagination and filtering params. Minor gaps remain around ordering and page-size behavior, but nothing essential for a correct call is missing.

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

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

Schema description coverage is already 100%, so the baseline is 3, but the description adds a crucial constraint absent from the schema: event_id and organization_id are mutually exclusive and one is required (the schema declares no required params and enforces no oneOf).

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

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

States a specific verb and resource ('List attendees') plus the granularity ('one per sold ticket') and the two supported scopes (single event OR all organization events). An agent can distinguish it from the singular sibling eventbrite_get_attendee without opening a schema.

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

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

Gives an explicit invocation constraint ('Pass exactly one of event_id / organization_id') and clarifies the two access patterns, which is real usage guidance. It stops short of naming an alternative tool or stating when-not to use it (e.g. versus get_attendee or list_orders).

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds the underlying REST endpoint and notes quantity_sold is returned. Beyond that it says nothing about pagination semantics, permission requirements, or result limits, so it adds only modest 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?

Dense and front-loaded: one sentence covers the resource, an output field, and the scope branches, followed by a compact endpoint reference. Slight redundancy with the schema's scope description, but no wasted padding.

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

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

For an 8-parameter, no-output-schema list tool, the description plus a fully documented schema gives an agent enough to call it correctly, and the quantity_sold mention hints at the return payload. Missing explicit guidance on pagination flow and relationship to sibling discount tools keeps it short of 5.

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 eight parameters, including the mutual exclusion of code/code_filter and the event_id requirement. The description's scope explanation largely restates the schema's own scope description, adding little beyond it.

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 ('Search') and resource ('an organization's discounts and access codes') and adds a return-value hint ('with quantity_sold'). It does not name the sibling tools it complements (create_discount, update_discount), so sibling differentiation is only implicit via the 'search' 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?

Explains the scope variants ('event needs event_id', 'multi_events = cross-event', 'user = all of the organization's'), which guides parameter choice, but never states when to use this tool versus create_discount/update_discount or what prerequisites exist beyond event_id. Usage is implied rather than spelled out.

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

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

readOnlyHint=true already declares this as a safe read, and pagination mechanics (continuation, page_size) are disclosed in the schema rather than the description. The description adds the upstream endpoint reference, which is mild but real context; it does not describe result shape or defaults beyond that.

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

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

Two compact sentences with the purpose front-loaded and filtering scope immediately after. The trailing 'Eventbrite: GET /organizations/{organization_id}/events/' is borderline filler but does help map to the upstream API.

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

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

For a read-only list tool with 8 fully documented parameters and no output schema, the description covers the essentials: what is listed and what can be filtered. Only the absence of any sibling routing or paging guidance keeps it short of 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%, including enum meanings for status and time_filter, so the schema carries the parameter burden. The description's mention of status/name/past-upcoming filters largely restates filters already documented in the schema and adds no syntax or format 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?

States a specific verb and resource ('List the events of an organization') and names the filtering dimensions, so the operation is unambiguous. It does not explicitly distinguish itself from siblings like eventbrite_get_event or eventbrite_list_organizations, but the scoping to 'events of an organization' is clear enough to route on.

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

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

The description says what can be filtered but gives no when-to-use context, no prerequisites, and never points at alternatives such as eventbrite_get_event for a single event or eventbrite_list_organizations for the parent resource. Usage must be inferred from the name and schema.

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

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

The readOnlyHint annotation already establishes this as a safe read, and the description adds value beyond it by enumerating the key returned fields (quantity_total, quantity_sold, quantity_pending, linked ticket_class_ids) and citing the underlying endpoint. It does not, however, mention pagination behavior despite the continuation param.

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

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

Two tight sentences with the scope and return fields front-loaded and no wasted prose; the endpoint reference is compact and informative.

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

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

For a read-only list tool with no output schema, the description usefully names the return fields, and annotations carry the safety profile. Only pagination semantics (continuation) go unexplained, 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 event_id, continuation, and count_against_event_capacity. The description adds no parameter-level 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 (List) and resource (inventory tiers) and constrains scope to 'tiered or reserved-seating event', which an agent can act on. It does not explicitly name the nearest sibling (eventbrite_list_ticket_classes) to disambiguate, so it stops short of a 5.

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

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

Usage is only implied by the 'tiered or reserved-seating event' qualifier; there is no explicit when-to-use, when-not, or alternative-tool guidance. An agent can infer the context but must decide routing 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds real behavioral context on top: the mutual-exclusivity contract for event_id/organization_id, the underlying REST endpoints, and the shape of the returned fields. It does not mention rate limits or pagination behavior (beyond the schema's continuation param), keeping it below 5.

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

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

Two tight sentences: the scope constraint and the returned fields are front-loaded, and the endpoint mapping is appended as supporting detail. No filler, no repetition of the title.

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

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

For a read-only list tool with no output schema, the description covers the essential: what it returns, the two scoping modes, and the mutual-exclusivity rule, while the schema fully documents pagination (continuation), status enum, and expand. A brief note on pagination looping or default status would make it complete at 5.

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 earns above baseline by surfacing the exactly-one-of constraint between event_id and organization_id, a relationship the schema does not express (no required fields, no oneOf), plus the endpoint form each maps to.

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

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

States a specific verb (List) plus resource (orders) and precisely scopes it to either one event or all of an organization's events, with the returned fields named (buyer name/email, status, costs). An agent can distinguish it from eventbrite_get_order (single order) and eventbrite_list_attendees without opening any 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?

Gives an explicit selection rule: 'Pass exactly one of event_id / organization_id.' This tells the agent how to choose between the two modes of operation, which is the main usage ambiguity for this tool. It stops short of naming an alternative sibling (e.g. get_order for a single order) or stating when not to use it, so it isn't a full 5.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the relational context that downstream tools depend on this output, but says nothing about pagination (the continuation param) or the shape/count of results.

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 short sentences plus the raw endpoint, with the return-value dependency front-loaded ahead of the HTTP detail. Nothing extraneous.

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-required-param, read-only list tool with a fully documented schema, the description gives enough to call it correctly and explains why it matters in the workflow. It does not describe the returned fields, which an agent must infer from downstream usage.

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 optional parameter and schema coverage is 100%, so the schema already documents 'continuation' fully. The description adds no parameter-level meaning, which is the expected baseline here.

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

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

States a specific verb and resource ('List the organizations you are a member of') and scopes it to the caller's memberships. The added note that other tools consume an organization_id from here further distinguishes it from the many create/get/list siblings.

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

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

Explicitly frames this as the entry point ('Almost every other tool needs an organization_id from here'), which tells an agent to call it before org-scoped tools. It stops short of stating when not to call it or naming a specific alternative, but the sequencing guidance 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?

readOnlyHint=true already declares the safety profile, so the description's burden is lower. It adds the HTTP mapping (GET /events/{event_id}/ticket_classes/) and the shape of returned fields, which is modestly useful, but says nothing about pagination behavior or rate limits. Adequate against the annotation baseline.

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

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

Two tight sentences with the resource and return shape front-loaded and no filler. The trailing HTTP endpoint reference is slightly redundant but harmless.

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

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

For a read-only list tool with full schema coverage and no output schema, the description compensates by naming the returned fields and the underlying endpoint. It omits pagination guidance for the continuation parameter, which is the main 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%, so the enum filters (pos, category), required event_id, and the continuation token are all fully documented in the schema. The description adds no parameter meaning beyond that, so the baseline 3 is correct.

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

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

States a specific verb (List) and resource (an event's ticket types) and even enumerates the returned fields (price, capacity, quantity_sold, sales window). It does not explicitly distinguish itself from siblings like eventbrite_list_inventory_tiers or get_capacity, but the purpose is immediately clear.

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 offers no when-to-use guidance, no exclusions, and no prerequisites. It never tells the agent how this differs from related read tools such as list_inventory_tiers or get_capacity, leaving selection entirely to inference.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description usefully adds what is returned (address, capacity), which goes beyond the annotation, but it says nothing about pagination behavior despite that being the tool's main non-obvious trait.

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 short sentences; the purpose and returned fields are front-loaded and the API endpoint is kept as trailing context. Nothing is padded, though the endpoint reference adds little for an agent.

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

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

With no output schema, the description helpfully names the fields returned (address, capacity). The only gap is that pagination via 'continuation' is left solely to the schema, which is acceptable for a simple read tool.

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

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

Schema description coverage is 100%, including a detailed warning that organization_id is not the organizer id, so the schema does the heavy lifting. The description adds no parameter-level meaning 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 ('List the saved venues of an organization') plus scope ('with address and capacity'), which clearly separates it from eventbrite_create_venue. It does not explicitly differentiate from any other read tool, but none of the siblings list venues.

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 read verb and the GET endpoint; there is no statement of when to prefer this over alternatives or of prerequisites. The schema hints organization_id comes from eventbrite_list_organizations, but the description itself gives no 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?

Annotations only supply destructiveHint=true; the description adds real behavioral context beyond that: the required prerequisite state, the fact that publishing exposes tickets for sale, and the reversibility boundary (undo only while there are no orders). It does not say what happens to an already-published event or failure/permission behavior, so not a 5.

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

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

Three tight sentences, front-loaded with the action and effect, followed by prerequisites, the undo route, and the API endpoint. 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 one-parameter state-changing tool with no output schema and minimal annotations, the description covers prerequisites, effect, reversal path, and endpoint. Missing only error/permission behavior and idempotency, which are minor 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?

Single parameter (event_id) fully documented in the schema at 100% coverage, so the schema carries the load. The description's prerequisite list describes event state, not the parameter itself, adding little semantic detail about event_id format or source.

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

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

Specific verb+resource (make a draft event live) plus the consequential outcome (tickets go on sale) and the REST endpoint. It is clearly distinguishable from sibling mutation tools like eventbrite_create_event or eventbrite_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?

States the preconditions for use (name, organizer, at least one ticket class, valid payment options) and names the inverse operation eventbrite_unpublish_event with its limiting condition (no orders). No explicit when-not-to-use, but the context is unambiguous.

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

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

Annotations only declare destructiveHint=true; the description adds the crucial eligibility gates around order state and payout that determine whether the call will succeed. It does not say what happens to already-issued tickets or whether the action is reversible, so it stops short of full 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?

Two tight sentences: the state transition first, then the eligibility constraint, then the API endpoint. Front-loaded and waste-free, though the raw endpoint reference is marginal 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 single-parameter mutation with no output schema, the definition covers the required input, the eligibility precondition, and the resulting state. Minor gaps (side effects on existing attendees/orders) remain but the essentials are present.

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 carries the semantics. The description only implies the ID through the POST /events/{event_id}/unpublish/ path and adds no extra meaning beyond it. 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 (unpublish) and resource (published event), and the reversal framing ('take a published event back to unpublished') cleanly distinguishes it from the sibling publish_event. An agent can pick the right tool 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?

Gives explicit preconditions for when the operation is permitted: no pending or completed orders, or for paid events after completion and payout. It does not name publish_event as the inverse alternative, but the usage condition is clearly stated.

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

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

Annotations only supply destructiveHint=true, so the description carries much of the burden. 'Only the fields you pass are sent' usefully discloses partial-update (PATCH-like) semantics, but it does not say what is at risk of being destroyed, whether changes are reversible, or how an org-wide vs event-scoped discount is 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?

Two compact clauses with the mutation semantics ('only the fields you pass are sent') front-loaded, followed by the underlying endpoint. No filler sentences, though the raw REST path adds little for an agent that never sees HTTP.

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

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

For a 10-parameter mutation tool with a single required field, no output schema, and only destructiveHint in annotations, the definition covers payload semantics but omits return/response expectations, error behavior, and any caution about destructive edits. 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 description coverage is 100% and every parameter carries its own format, pattern, and constraint text (e.g. percent_off range, amount_off exclusion), so the schema does the heavy lifting. The description adds only a high-level field taxonomy, which is baseline-level value.

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?

Names a specific verb ('Change') and resource ('a discount or access code') and enumerates the mutable field categories (amount, uses, dates, scope). An agent can distinguish this from eventbrite_create_discount and eventbrite_list_discounts on name and verb 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?

The description implies the update path (change an existing discount) but never states when to use this versus eventbrite_create_discount, nor any prerequisites such as required permissions or whether the discount must be in draft. Usage is inferable from the verb but not explicitly 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?

Annotations only supply destructiveHint=true; the description adds real behavioral context beyond that: it is a partial update ('only the fields you pass are sent') and that time fields are coupled with timezone. It still does not explain the destructive implications (e.g., effects on paid sales) that the hint implies.

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

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

Three tight clauses, front-loaded with the core action, then the partial-update rule, then the timezone caveat, closing with the endpoint. Zero filler and every sentence earns its place.

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

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

For a 20-parameter mutation tool with no output schema, the description covers the key non-obvious behaviors (partial update, timezone coupling) and the rich schema documents the rest. It could say more about destructive side effects, but it is largely sufficient.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: the partial-update semantics of passing fields, and the non-obvious requirement that start_utc/end_utc must be accompanied by timezone. This is useful semantic framing above 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+resource ('Change fields of an existing event'), making it clearly distinguishable from eventbrite_create_event and eventbrite_copy_event. It does not name those siblings, so differentiation is implied by the name rather than explicit.

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

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

Gives a conditional rule ('Changing start/end needs timezone too') and the partial-update behavior, which is genuine usage guidance. However, it never states when to choose this over siblings like eventbrite_publish_event or eventbrite_update_ticket_class, nor any prerequisites.

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

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

The annotations already declare destructiveHint=true, and the description adds meaningful update semantics: only supplied fields are sent and price cannot change after tickets are sold. It does not cover permissions or reversibility, but it goes beyond the annotation.

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?

It is two compact sentences plus the API path, all front-loaded and free of repetition. Every element contributes information useful for 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?

The tool is complex with 17 parameters, but the schema is fully described and no output schema exists. The description supplies the key behavioral constraint and the endpoint, making it sufficiently complete, though it could mention permissions or error behavior.

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 17 parameters. The description still adds semantic value by clarifying partial-update behavior and the post-sale price restriction for the cost field.

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: changing an existing ticket type, with the Eventbrite resource path included. It is clearly distinguishable from create_ticket_class 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?

It gives clear context for updating an existing ticket type and notes that only passed fields are sent, which tells the agent how to use it for partial updates. It does not explicitly name alternatives such as create_ticket_class, but the intended use is unambiguous.

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