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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds two things annotations cannot: that the tool reaches any public event rather than only owned ones, and how the id is obtained. That is useful behavioral context beyond the structured fields.

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, zero filler, with the core action and its scope front-loaded and the id-derivation hint following. Nothing needs trimming or reordering.

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 read tool with full schema coverage, explicit annotations, and a view/expand parameter set documented in the schema, the description covers what is needed to call it correctly. No output schema exists, but the view parameter already describes 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 3 is the baseline. The description earns a bump by explaining the event_id value's origin ("trailing digits in an event URL (…-tickets-<id>)"), which is more actionable than the schema's bare "Numeric event id".

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 an Eventbrite event by id") and scopes it ("works for any public event, not just yours"), which separates it from the org-scoped siblings like eb_org_events. It does not distinguish itself from the near-namesake eb_event_details, so an agent still has to guess between those two.

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 clarifies a usage condition — ownership is not required — which is real guidance. However, no alternative is named (e.g., eb_search_events for discovering ids, or eb_event_details for whatever that returns), so routing between siblings is left to inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuine value by enumerating what the response carries (barcode, profile answers, check-in state), which is exactly the return-content context the schema does not provide. Missing auth or rate-limit notes keeps it from a 5.

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

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

A single tight sentence, front-loaded with the verb and resource, with the parenthetical field list adding information rather than padding. 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?

With no output schema, the description must convey return contents, and it does so at a summary level (barcode, profile answers, check-in state). Combined with the rich 'view' parameter documentation, an agent has enough to call this correctly, though a hint about auth scope would round it out.

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 explanation of the 'view' enum, so the schema does the heavy lifting. The description only adds that lookup is by id, 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 (Get) and resource (one attendee of an event) plus the lookup key (by id). The singular 'one attendee' implicitly distinguishes it from the list-style sibling eb_event_attendees, though no sibling is named explicitly.

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

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

The 'by id' phrasing implies a point-lookup scenario, letting an agent infer this is for fetching a single attendee rather than listing them. However, there is no explicit statement of when to prefer this over eb_event_attendees or eb_org_attendees, and no prerequisites are mentioned.

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 and openWorldHint, so the safety profile is covered; the description adds the non-obvious access requirement (organizer-side, requires access to that event) and the incremental-polling behavior. It does not describe pagination termination or response size, so it falls 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 tight sentences, front-loaded with the identity of the tool and its access constraint, then the polling advice. No filler or restatement of the name.

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 5-param read tool with no output schema and strong parenthetical schema descriptions, the description covers scope, auth, and incremental polling. It leaves response shape to the view parameter, which the schema already handles, but says nothing about result ordering or exhaustion of the continuation token.

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 80%, so the schema already documents view, status, event_id, continuation, and changed_since. The description only reinforces changed_since as a polling mechanism and adds no syntax or format detail (e.g. status filtering semantics) beyond the schema, making 3 the appropriate 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 (List) and resource (a single event's attendees) and pins the scope as organizer-side, which distinguishes it from the org-wide eb_org_attendees sibling. It does not explicitly name that sibling or eb_event_attendee, so differentiation is implied rather than spelled out.

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 one concrete usage rule — use changed_since to poll incrementally rather than re-reading the whole list — which is genuinely useful. However, it gives no guidance on when to pick this over eb_org_attendees or the singular eb_event_attendee, and no exclusions.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, so the safety profile is already covered. The description adds one genuinely useful behavioral fact: the return value is 'HTML', not plain text, so the agent should expect markup. It says nothing about sanitization, size limits, or what happens when the description is empty.

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 with zero filler. It is arguably terse given the tool has a view parameter affecting response shape, but nothing is wasted or 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?

A simple read tool with full schema coverage and annotations covering safety, and no output schema is needed since the description names the return value. The remaining gap is minor: no note on empty descriptions or HTML sanitization.

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%; event_id and the compact/full view enum are fully documented in the schema. The description adds no parameter-level detail, so baseline 3 applies.

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

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

States a specific verb and resource: 'Get an event's full HTML description.' The word 'description' (vs 'details' / 'event') signals this returns one field rather than a full event object, which is enough to separate it from eb_event and eb_event_details. It stops short of naming those siblings explicitly, so the differentiation is implied 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?

No guidance on when to call this versus eb_event_details, eb_event, or eb_event_attendees. There is no mention of prerequisites (auth, event ownership) or when the HTML description is the right payload over the structured event record.

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

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

With readOnlyHint and openWorldHint already declared by annotations, the description adds genuinely useful behavioral context absent from structured data: the bearer-token default and the browser-bridge fallback when no token exists. It stops short of disclosing rate limits, pagination, or error behavior for a batch endpoint capped at 20 ids.

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, each earning its place: purpose and scope front-loaded, then the auth behavior, then the alternative routing. 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?

For a read-only batch tool with no output schema and full schema coverage, the description covers purpose, auth fallback, and sibling routing adequately. It leaves minor gaps around batch semantics (ordering, partial-failure behavior) but nothing that would block 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 description coverage is 100% – event_ids, expand, and the compact/full view enum are all thoroughly documented in the schema itself. The description only echoes "by id" and adds no format or syntax details 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?

"Batch-fetch public event details by id" states a specific verb (batch-fetch), resource (public event details), and access pattern (by id). The word "batch" implicitly distinguishes it from the singular eb_event sibling, and it explicitly routes ticket-class lookups to eb_ticket_classes. It does not, however, clarify how it relates to eb_event or eb_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?

It gives an explicit alternative for one case ("For ticket-class detail prefer eb_ticket_classes") and the "batch" framing implies the multi-id use case. There is no explicit when-not guidance versus eb_event or eb_event_description, so it falls short of full alternative coverage.

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 and openWorldHint, so the safety profile is covered. The description adds a genuine permission requirement ('requires access to that event'), but says nothing about pagination behavior or result shape for a list endpoint that exposes a continuation token.

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

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

A single front-loaded sentence with zero filler; purpose and the access constraint are both delivered immediately.

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

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

No output schema exists, but for a simple read-only list tool the description plus rich param docs cover what an agent needs. It is nearly complete, missing only pagination guidance that the schema's continuation param largely implies.

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 80%, with the 'view' and other params well documented in the schema itself. The description adds no syntax or meaning 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 ('a single event's orders'), with a scope qualifier that distinguishes it from org-wide siblings like eb_org_orders and eb_my_orders. It does not name those siblings explicitly, but the 'single event' scoping 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?

The parenthetical 'requires access to that event' gives one precondition, but there is no explicit when-to-use guidance nor any named alternative (e.g. eb_org_orders for org-level listings). Usage is implied by scope 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and reach profile is covered structurally. The description adds only the canned-vs-custom distinction; it says nothing about pagination, ordering, or what a listing returns. Adequate but thin given the lower bar set by annotations.

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

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

Two sentences, zero filler, and the core purpose is front-loaded ahead of the conditional parameter tip. Every clause carries information 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?

For a read-only list tool with full schema coverage, annotations covering safety, and no output schema, the description supplies what an agent needs to call it. Pagination and response-shape behavior are only partly implied via the 'view' parameter, leaving a small gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's canned guidance largely restates the schema's own wording ('Fetch the standard question bank instead of the event's custom questions'), and the rich 'view' semantics live entirely in the schema. It adds no syntax or format detail beyond structured data.

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 registration questions an event asks its buyers.' No sibling tool overlaps with registration questions, so the agent can disambiguate immediately. The second sentence further sharpens scope by distinguishing the event's custom questions from Eventbrite's standard bank.

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 tells the agent when to flip behavior: 'Set canned=true for Eventbrite's standard question bank instead of the event's custom ones.' That is actionable conditional guidance. It stops short of naming alternative tools or stating exclusions, but none are needed given the narrow resource.

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?

Adds substantial context beyond the readOnlyHint/idempotentHint annotations: credential resolution order, the exact endpoints hit, round-trip timing, browser-bridge fallback when no token exists, the guarantee that the credential is never returned, and an enumerated set of error.kind values including the useful 'edge_blocked' vs 'credential_rejected' distinction.

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, then branches cleanly into token/no-token behavior before listing error kinds. It is dense and somewhat long, but nearly every clause carries information; only minor pruning is possible.

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 non-trivial branching behavior, the description still fully covers what is reported (round-trip time, credential source, acceptance), the fallback path, and the failure taxonomy. An agent has everything needed to 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?

The tool takes zero parameters and the schema is an empty object, so there is nothing for the description to clarify. Baseline for a parameterless tool is 4.

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: it is a reachability/diagnostic check that reports 'which hop is broken when a real tool fails.' This cleanly distinguishes it from every sibling, which are all Eventbrite data-access tools, and the title reinforces 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?

Gives clear context for invocation ('when a real tool fails') and explains two distinct execution modes depending on whether EVENTBRITE_TOKEN is set. It does not explicitly name the alternative tools to try first, but the trigger condition 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 already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the payload scope (id, name, primary email), which is genuinely useful, but says nothing about auth/token requirements or what happens when the profile is unavailable.

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 tight sentence with zero filler, front-loading the verb, the resource, and the distinguishing scope word 'authenticated'. Every clause earns its place.

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

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

With no output schema, the description usefully enumerates the key return fields, which is the main thing an agent needs here. It is nearly complete for a one-parameter read tool, missing only auth/prerequisite context.

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

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

Schema description coverage is 100%; the single 'view' parameter carries a thorough enum explanation in the schema covering compact vs. full behavior and the absence of field projection. The description adds nothing about it, 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 (Get) and resource (the authenticated Eventbrite user's profile), and names the returned fields (id, name, primary email). The word 'authenticated' scopes it meaningfully, though it never explicitly contrasts itself with the similarly-named sibling eb_user.

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 statement, no prerequisite (e.g. which token scope is required), and no pointer to an alternative such as eb_user for looking up someone else's profile. Usage is only inferable from the 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful return-shape context ("with the event expanded") and notes time_filter's effect, but says nothing about pagination behavior despite a continuation token being accepted.

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 purpose and followed by the filter scoping note. No filler, though the second sentence largely duplicates what the time_filter enum 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?

For a zero-required-parameter read-only list tool with no output schema, the definition gives enough to call it correctly, and the schema carries the parameter detail. The only omission is any mention of how continuation/pagination works in practice.

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 view, time_filter, and continuation thoroughly. The description's only added meaning is restating that time_filter narrows to upcoming/past, which the schema enum already conveys. 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 ("List the authenticated user's ticket orders") and adds the disambiguating scope "(attendee side)", which separates it from eb_org_orders and eb_event_orders. It does not name those siblings explicitly, but the attendee-vs-org distinction is clear enough to route correctly.

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 through the "attendee side" qualifier and the time_filter scoping sentence, so an agent can infer this is the buyer-facing order list. However, no alternative is named and no when-not-to-use condition is given, leaving the agent to compare siblings itself.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully adds that results are scoped to the authenticated user's memberships, but says nothing about pagination behavior, result volume, or what happens with zero memberships — gaps that matter for a list endpoint.

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

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

Two sentences, zero filler, with the purpose front-loaded and the downstream usage guidance second. Every clause earns its place.

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

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

For a no-required-parameter list tool with no output schema and full schema coverage, the description covers what is returned (organizations the user belongs to) and how to consume the output ids. Only minor details like pagination semantics 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 description coverage is 100%, and the 'view' enum is thoroughly documented in the schema itself, so the schema carries the parameter burden. The description adds no syntax or format detail for 'view' or 'continuation', which is acceptable at this coverage level but not value-adding.

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

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

Specific verb 'List' plus resource 'organizations', narrowed by scope to the authenticated user with the '(organizer side)' qualifier, which separates it from eb_organizer (single organizer lookup). It does not explicitly name a sibling it is not, but the scope wording is enough for an agent to route correctly.

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 second sentence gives concrete downstream guidance: use the returned org id with eb_org_events / eb_org_attendees / eb_org_orders, which establishes this tool as the entry point in the org workflow. No when-not conditions or prerequisites are stated, but the chaining context is clear and actionable.

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 and openWorldHint=true, so safety is covered and the bar is lower. The description adds useful semantics (order = buyer-side record behind a ticket) but says nothing about permissions, pagination, or response shape; the rich view/expand behavior lives in the schema, not the description.

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

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

Two short sentences, zero waste, and the core purpose is front-loaded ahead of the provenance hint. Nothing redundant or 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 simple single-resource read with full schema coverage and no output schema, the description supplies what an agent needs: what it fetches and where the id comes from. A brief note on what the response contains would close the only remaining gap, but it is minor.

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 'view' and 'expand' documented in detail and order_id labeled 'Numeric order id', so the schema carries the burden. The description adds no syntax or format detail for any parameter beyond 'by 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?

States a specific verb (get) and resource (a single order) and immediately clarifies what an order is ('the buyer-side record behind a ticket'), which disambiguates it from ticket-oriented siblings. The scope word 'single' paired with the reference to eb_my_orders/eb_event_orders makes clear this is the detail-fetch counterpart to those list 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?

It tells the agent the prerequisite for invocation: order ids 'appear in eb_my_orders / eb_event_orders results', which routes the agent to the right tools for obtaining the id. It gives no explicit when-not or alternative for order retrieval, but the context is concrete enough to invoke correctly.

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 and openWorldHint=true, so the safety profile is covered. The description adds that this is a 'public profile', implying no special authorization, and lists returned fields, but says nothing about error behavior for unknown ids or the effect of the view parameter beyond what the schema already states.

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

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

A single tight sentence with the verb and resource front-loaded and the returned fields parenthesized. 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?

With no output schema, the description usefully enumerates the returned fields, which is the main gap it needed to fill for a simple read tool. It is close to complete, though it omits any note on unknown-id behavior or that this returns a single organizer rather than a list.

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%: organizer_id and the compact/full view semantics are fully documented in the schema itself. The description only restates that lookup is by id, adding no syntax, format, or default information 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 (Get) and resource (organizer's public profile by id) and enumerates the returned fields (name, description, logo, social links), which separates it from event/order-oriented siblings. It does not, however, explicitly contrast itself with near neighbors such as eb_organizer_events or eb_my_organizations.

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 no when-to-use guidance, no prerequisites, and names no alternatives. With siblings like eb_organizer_events and eb_my_organizations in the same namespace, an agent gets no help deciding when this profile lookup is the right call.

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 and openWorldHint=true, so safety is covered. The description adds only the 'public' scope framing; it says nothing about pagination behavior despite a continuation token parameter, nor about what the response contains at each view. Adequate but thin beyond the annotations.

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 short sentence with the scoping qualifier front-loaded and zero filler. Every word 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 low-complexity read-only list tool with a rich schema and annotation coverage, the description is minimally viable. It lacks the one thing most useful here — a clear statement of how it differs from eb_org_events and the other event-listing siblings — leaving a gap for tool 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?

Schema description coverage is 80% and the schema itself documents view, status, order_by, continuation, and organizer_id in detail. The description adds no parameter meaning beyond that, so the schema does the heavy lifting and 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 and resource ('List an organizer's events') and adds a scope qualifier ('the public way to see everything one organizer is running'). It is clear what the tool does, but it never names the obvious sibling eb_org_events, which likely covers the authenticated/organizer view, so the differentiation is only implied.

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

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

The phrase 'the public way to see' hints at the context in which this tool is appropriate versus an authorized org-events listing, but no explicit when-to-use, when-not, or alternative is stated. An agent must infer the public/private split from the sibling list.

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 and openWorldHint, so the safety profile is covered. The description adds no behavioral context of its own: nothing about pagination despite the continuation parameter, nothing about how results are aggregated across events, and nothing about authorization scope beyond the vague 'organizer side'.

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 with zero filler; the resource and its scope come first. Given the schema carries the parameter detail, this is appropriately sized.

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

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

With no output schema, the description should say more about what a caller gets back — the aggregate-per-event shape and the continuation-token pagination are left unstated. Annotations cover safety, and the schema covers inputs, so the remaining gap is return/pagination 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 description coverage is 100%, so all four parameters including the enum filters and continuation token are documented in the schema itself. The description contributes no additional parameter meaning, so the baseline 3 applies.

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

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

Specific verb (List) plus resource (attendees) plus a scoping qualifier (across an organization's events, organizer side) that distinguishes it from the event-level sibling eb_event_attendees. It does not name that sibling explicitly, but the 'organization's events' scope makes the boundary 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?

The parenthetical '(organizer side)' hints at the caller context, implying use when operating as an organizer rather than a single event's perspective. However, no alternative tool is named, no when-not condition is given, and no prerequisite (e.g., needing an org_id from eb_my_organizations) is stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered externally. The description adds a useful scope signal by saying the listing includes usage limits, but says nothing about pagination behavior despite the continuation parameter, nor about ordering, result size, or what an empty result means.

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 that names the resource and the notable return content with no filler. It is efficient, though it is thin enough that a second clause on pagination or prerequisites would have earned 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 readOnly/openWorld annotations and full schema coverage, the remaining burden is modest: no output schema exists, and the description partially compensates by disclosing that usage limits are returned. It stops short of covering pagination and auth prerequisites, which keeps it out of the top tier.

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 schema itself explains org_id's provenance, the compact/full view tradeoff, and the continuation token. The description adds no parameter-level meaning beyond the schema, so the baseline 3 is appropriate.

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

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

States a specific verb ("List") and a specific resource ("discount and access codes") scoped to an organization, and even notes the payload carries usage limits. It is clearly separable from org-scoped siblings like eb_org_orders or eb_org_ticket_groups by resource, though it never names an alternative or explicitly contrasts with 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?

Usage is only implied: the org-scoped name plus the org_id parameter make it obvious this lists discounts for one organization. There is no statement of when to prefer this over another tool, no prerequisites (e.g., required token scopes), and no note that org_id should come from eb_my_organizations (that hint lives only in the 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds only the "as organizer" semantic nuance; it says nothing about pagination behavior despite a continuation token being a parameter, nor about result limits or rate limits. Adds some value beyond annotations but not rich 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?

A single efficient sentence with the core action front-loaded and the optional filter trailing. No filler or redundancy. Slightly under-specified rather than verbose, but structurally sound.

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 could reasonably say more about what is returned, but the view parameter partly covers response shape in the schema. For a 5-parameter listing tool with several near-duplicate siblings, the absence of disambiguation leaves a real 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 80%, with the status, view, and continuation parameters self-documented in the schema, so the baseline is 3. The description restates only the status filter, which the schema already explains, and adds no syntax or default detail 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 and resource ("List an organization's events") and clarifies the scope with "(as organizer)". However, it does not distinguish itself from the very similar sibling eb_organizer_events, which an agent could easily confuse it with. Clear but lacking sibling differentiation.

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

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

The description mentions an optional status filter but gives no guidance on when to use this tool versus alternatives like eb_organizer_events, eb_series_events, or eb_search_events. No prerequisites or exclusions are stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered and the bar is lower. The description adds that the listing spans an organization's events ('organizer side'), which is useful scoping context, but it says nothing about pagination behavior (despite a continuation param), result volume, or ordering. Minimal added value beyond structured data.

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 with no filler; the scope qualifier is placed immediately after the core action. Nothing is wasted and the essential information comes first.

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

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

With no output schema, the description carries more of the burden, yet it only names the resource and scope. For an org-wide listing with pagination, it could note that results are paginated and must be traversed via 'continuation'. It is minimally sufficient for a safe read-only list operation but leaves the pagination workflow to the schema.

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

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

Schema description coverage is 100%, so all three parameters, including the enum meaning of 'view' and the pagination role of 'continuation', are already documented in the schema. 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 ('List') and resource ('orders') plus scope ('across an organization's events'), and the parenthetical '(organizer side)' implicitly separates it from the buyer-oriented eb_my_orders sibling. The phrase 'across an organization's events' also distinguishes it from the single-event eb_event_orders. It falls short of naming alternatives explicitly, but the resource and scope are 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?

There is no explicit when-to-use or when-not-to-use guidance; the only routing signal is the '(organizer side)' parenthetical, which implies this is the organizer-facing counterpart to eb_my_orders. An agent can infer the context but must reason it out rather than being told. Adequate but with a clear gap on alternatives.

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 and openWorldHint, so safety profile is covered. The description adds that this returns aggregated analytics and is optionally date-windowed, which is useful context beyond annotations, but does not discuss pagination behavior despite a continuation param, nor the compact/full implications.

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 efficient sentence that front-loads the core purpose (run an org's report) before the optional date-window detail. No waste, though a touch terse given the 8-parameter surface.

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-param reporting tool with no output schema, the description does not explain return shape or how compact/full and group_by affect results. Annotations cover safety, and the schema covers params, so the remaining gap is modest, but it is not fully complete.

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

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

Schema description coverage is 88%, so the schema documents kind, view, org_id, dates, group_by, continuation, and event_status in detail. The description adds only the date-window framing, not much beyond what the schema provides. 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 (run) and resource (org report), and clarifies it is aggregated analytics over an org's events windowed by date. It largely distinguishes the aggregate/report nature from siblings like eb_org_events, though it does not explicitly name a sibling alternative.

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?

Implies usage (analytics behind events, optionally windowed) but gives no when-to-use vs when-not guidance and no explicit alternatives among the many org_* siblings. Adequate but with clear gaps.

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 and openWorldHint, so the safety profile is covered. The description adds the org-scoping constraint and a definition of ticket groups, but says nothing about pagination behavior despite the continuation param, or about what a returned group contains.

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 tight sentence with the resource and its definition front-loaded and zero filler. Nothing to trim.

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 full schema coverage and annotations handling the safety profile, the definition is minimally adequate. For a list tool with no output schema, it still doesn't hint at the shape or count of ticket groups returned, nor how continuation-driven paging works, 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 org_id, view, and continuation are already documented in the schema; the description adds no syntax, format, or default details beyond what is there. Baseline 3 applies when the schema carries the parameter burden.

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 (ticket groups), and the parenthetical 'ticket classes bundled across events' defines the resource so an agent isn't guessing what a ticket group is. It does not explicitly contrast with near-siblings like eb_ticket_classes or eb_org_events, so it stops short of the 5 bar.

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 only says what the tool does; it gives no guidance on when to use it versus eb_ticket_classes, eb_org_events, or eb_ticket_class, and no prerequisites beyond the schema-embedded 'from eb_my_organizations' hint.

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 and openWorldHint=true, so the safety profile is covered. The description adds a rough return-field list (name, address, geo), which is useful since there is no output schema. It says nothing about pagination behavior despite a continuation parameter existing, nor about rate limits or result size.

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

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

A single sentence with zero filler, front-loaded with the verb and resource. Nothing could be cut without losing 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 low-complexity list tool with full schema coverage and read-only annotations, only the return shape is left to the description and it is given at a shallow level. Missing is any hint about pagination or how results are ordered/limited, which matters for a listing endpoint with a continuation token.

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%: org_id, continuation, and the compact/full view enum are all fully documented in the schema, including the unusual no-field-projection note. 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 ('List') and a clearly scoped resource ('an organization's saved venues'), plus the fields returned. An agent can distinguish it from eb_venue (single venue) and eb_venue_events (events at a venue). It stops short of explicitly naming a sibling to differentiate against.

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 prerequisites, and no pointer to alternatives such as eb_venue for a single venue's details or eb_venue_events for its events. Usage is only inferable from the name and the word 'organization's'.

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 and openWorldHint=true, so safety is covered. The description adds essentially nothing beyond restating the name – it does not mention pagination behavior (despite a continuation param existing) or auth requirements, so it earns little credit against the lowered bar.

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 efficient, front-loaded sentence with no filler. It is well sized, though it is terse to the point that the sentence is doing minimal work.

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 read-only list tool with a fully documented 3-parameter schema and no output schema, the description covers the essential purpose. Only minor gaps remain (pagination expectations, org_id source), and the schema covers continuation.

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 detailed text for the view enum and the continuation token, so the schema does all the work. The description contributes no additional parameter 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 ('List') and resource ('an organization's registered webhooks') plus the payload contents ('the actions they subscribe to'). This is unambiguous, though there are no sibling webhook tools to differentiate from, 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, no prerequisites, and no mention of the org_id sourcing beyond what the schema already carries. Usage is only implied by the 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe external read. The description adds that the output is reference data whose ids are inputs elsewhere, but says nothing about caching, volatility of the lists, or rate limits. With the safety profile already covered, this is 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?

Two dense sentences with zero filler; the resource list comes first and the consumer relationship second, so the most useful information is front-loaded.

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 enumeration tool with no output schema, the description tells the agent what lists exist and why the ids matter, which is enough to call it correctly. It could say more about the shape/size of each list, but the schema's view parameter partially covers that.

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 'view' parameter already carries an unusually detailed explanation of compact vs full, so the schema does the heavy lifting. The description's category examples (103=Music, 101=Business) hint at what 'kind' returns but add no syntax or format detail for either parameter; 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 (Eventbrite reference data) and enumerates the exact resource families, mirroring the schema enum. It also distinguishes itself from siblings by naming eb_search_events as the consumer of the returned ids, so an agent can route 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 sentence 'Category/subcategory/format ids feed eb_search_events filters' gives a clear reason to call this tool (harvesting ids before a search). It stops short of explicit when-not guidance or naming alternatives for the timezone/country/region lists, so it is strong context but not full 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 readOnlyHint and openWorldHint already present, the description still adds valuable behavioral context: city-only inputs fail, accepted input forms, the returned object shape, and that shelves come from the same fetch. It does not cover auth/rate-limits, but the read-only annotation already handles 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?

Three front-loaded sentences, each with a distinct job: purpose, accepted inputs/constraints, and returned fields. There is no redundancy, and the slightly unusual 'harvested free' phrase still communicates that no extra fetch is 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?

For a simple read-only resolver with no output schema, this is nearly complete: return fields are enumerated, location constraints are explicit, and safe-read behavior is annotated. Minor gaps are the absence of error response details beyond rejection and explicit sibling comparison, but these do not block 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 the baseline is 3; the description adds genuine value by stating that a city on its own is rejected and state or country is required, beyond the schema's examples. The view parameter is already fully described in the schema, so no further description is 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?

The first sentence names the exact verb ('Resolve'), the resource ('a location to Eventbrite's internal place id'), and the consumer ('for eb_search_events'). This clearly differentiates the tool as a place-ID resolver rather than a search or venue tool.

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

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

The description gives clear input guidance: accepts a plain location or browse slug, and explicitly warns that a bare city is rejected and a state/country is required. It does not name alternatives or state when not to use it, but the tie to eb_search_events makes the intended workflow clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context: it returns a slim per-event projection by default, can return Eventbrite's whole search envelope with view:"full", and lists exactly which fields the compact projection includes. It does not mention pagination limits or rate limits, but the schema covers page/page_size and the openWorldHint covers external variability.

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

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

Three sentences with no filler. The core purpose is front-loaded, the prerequisite is stated immediately, and the view behavior is explained compactly. 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 14-parameter read-only search tool with no output schema, the description is nearly complete: it names the prerequisite, the filter families, the default response shape, and the full-response alternative. It could add a note about pagination defaults or the meaning of aggs, but the schema already documents page/page_size and aggs, and the openWorldHint covers external variability.

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 86%, so the schema already documents most parameters. The description adds value by explaining the relationship between place_id and eb_resolve_place, clarifying the view parameter's compact vs full response shapes, and grouping filters (keyword, dates, category/subcategory/format ids, free/paid, online-only) into a mental model. The only minor gap is that aggs and online_events_only are not individually elaborated, but the schema covers them.

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 opens with a specific verb and resource ('Search public Eventbrite events') and immediately distinguishes this tool from the documented API and from sibling tools like eb_resolve_place and eb_reference. It clearly states the consumer-search scope, which is unique among the siblings.

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

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

The description explicitly instructs to resolve the location to a place id first with eb_resolve_place, names eb_reference for category/subcategory/format ids, and explains the view parameter's two modes. This gives an agent concrete when-to-use and how-to-prepare guidance, including the prerequisite call.

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 and openWorldHint=true, so the safety profile is covered. The description adds context that events and search results carry a series_id, which is genuinely useful for locating the required input, but it says nothing about pagination behavior or result ordering despite a continuation token being available.

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

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

Two sentences, zero waste, with the core action front-loaded and the supporting detail about series_id immediately after. 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 read-only list tool with no output schema and annotations covering safety, the description is nearly complete. The main omission is that it never mentions the pagination model implied by the continuation parameter, which an agent would want to know before iterating 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%, so the schema already documents series_id, view, status, and continuation in detail. The description's note about series_id provenance largely repeats what the schema field description already states, adding no new syntax or format guidance.

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 occurrences of a recurring event series. It also explains where the series_id comes from, which distinguishes it from generic event endpoints like eb_event_details. It stops short of explicitly contrasting itself with the closest sibling, eb_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?

Usage is implied rather than stated: the agent infers it should call this when it has a series_id and wants the occurrences. There is no explicit when-not guidance or named alternative (e.g. eb_event for a single occurrence, eb_search_events for discovery).

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

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

Annotations cover safety (readOnlyHint, openWorldHint). The description adds no behavioral detail beyond identification—no auth requirements, rate limits, or error behavior. Schema documents the 'view' param behavior, which is useful but comes from schema, not 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 primary action and immediately followed by the routing hint. No 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 read-only get-by-id tool with full schema coverage, this is nearly complete. The routing hint is helpful, but no return-value or error context is given; less critical given the schema's thoroughness.

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 richly documents all three parameters including the view enum semantics. The description adds no parameter meaning beyond the required id. Baseline 3 per rules.

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 specific verb + resource + scope: 'Get one ticket class of an event by id.' Distinguishes from siblings by explicitly referencing eb_ticket_classes as the list counterpart.

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?

Names a prerequisite/alternative ('Use eb_ticket_classes to list them first'). Gives clear context, though no explicit when-not-to-use or boundary conditions are stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the shape of what is returned (name, cost, free/paid, on-sale status), which is genuinely useful, but says nothing about pagination, ordering, or auth scope.

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 tight sentence with the resource front-loaded and the useful return fields parenthesized immediately after. No wasted words.

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

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

With no output schema, the description correctly compensates by naming the fields returned, which an agent needs in order to trust the result. A note on pagination or the list/detail relationship with eb_ticket_class would make it 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%, with the 'view' enum and 'event_id' both fully documented in the schema, so the baseline is 3. The description adds no parameter-level detail 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?

States a specific verb (List) and resource (an event's ticket classes) and even enumerates the returned fields (name, cost, free/paid, on-sale status). It does not explicitly distinguish itself from the sibling eb_ticket_class (singular), leaving the list-vs-detail split 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 explicit when-to-use, when-not, or alternative guidance. The only routing signal is the plural name versus the singular eb_ticket_class sibling, which the agent must infer without help from the description.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds non-obvious behavioral context: this endpoint exposes only public fields, and email-like private data lives on eb_me. It says nothing about rate limits or error behavior, but for a single-resource read that is a minor gap.

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

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

Two short sentences, zero waste, with the core purpose front-loaded and the routing note second. Nothing redundant and nothing 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 two-parameter, annotated, single-resource read tool the description covers purpose, the key sibling disambiguation, and the public/private data boundary. The absence of an output schema is acceptable since the description notes what fields are and aren't returned; only edge details like error cases 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 description coverage is 100%, and the schema itself explains the 'view' enum in unusual depth (compact vs full, image stripping, no field projection). The description only echoes 'by id' and adds nothing about 'view', 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 ('Get a public user profile by id') and immediately distinguishes it from the sibling eb_me by contrast. An agent can tell exactly which of the many eb_* user-facing tools this is 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?

Explicitly names the alternative (eb_me) and the condition that selects it (the authenticated user, including private fields like emails). It implies, but never states outright, that this tool is for other users' public profiles and that self-lookups should go elsewhere. Solid routing guidance with a small inference left to the agent.

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 and openWorldHint=true, so safety and network scope are covered. The description adds the returned field set (name, address, geo), which is genuinely useful given there is no output schema, but it discloses nothing about auth requirements, 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?

Two compact sentences with zero filler, front-loading what the tool returns before explaining where to source the id. Every clause earns its place.

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

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

With no output schema, the description does supply the shape of the return (name, address, geo), and the read-only/open-world annotations carry the safety profile. It is sufficient to call the tool correctly, though a hint about the compact vs. full default would round it out.

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 the view enum fully explained in the schema itself, so the baseline of 3 applies. The description contributes nothing about parameter semantics that the schema does not already provide.

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 venue by id') and enumerates the returned fields (name, address, geo), which is more than a tautology. It gestures at sibling context by naming eb_org_venues as a source of ids, but does not sharply distinguish itself from eb_venue_events or eb_org_venues as a selection choice.

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 note that 'Venue ids appear on expanded events and in eb_org_venues' usefully tells the agent where to obtain the required input. However, there is no guidance on when to prefer this tool over eb_venue_events or eb_org_venues, and no stated preconditions or exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds nothing beyond that — no mention of pagination behavior (despite the continuation token), no auth or visibility constraints for draft/canceled events. For a read tool whose annotations cover the safety profile, this sentence contributes no new behavioral 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?

A single front-loaded sentence with no filler or redundancy. It is concise, though arguably too terse to be maximally useful given the tool's pagination and filtering surface.

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 a moderately complex input (4 params, pagination, status filtering), the description should carry more of the load. It omits pagination expectations, how draft/canceled events are scoped to the caller, and any routing guidance relative to the many sibling event-list tools.

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 schema documents view, status, venue_id, and continuation in detail, including the enum semantics for view. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

The description states a specific verb ('List') and resource ('events held at a venue'), so the agent knows what it does. However, it offers no differentiation from siblings such as eb_org_events, eb_series_events, eb_organizer_events, or eb_search_events, all of which could plausibly return event lists.

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 choose this tool over eb_search_events or eb_org_events, nor any prerequisite or exclusion stated. The agent must infer usage purely from the name and the venue_id requirement.

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