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

The readOnlyHint annotation already signals a safe read operation. The description adds useful behavioral context by stating that the tool works for any public event, implying no ownership or organizer credentials are required. It does not contradict the annotation and appropriately avoids re-stating the read-only nature.

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

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

The description is two short, front-loaded sentences with no filler. The core action and scope come first, followed by a concrete, useful id-extraction hint. 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 simple read-only fetch tool, the description covers the essential context: what it gets, the id format, and public-event scope. The schema covers all parameter semantics, and the readOnlyHint covers safety. There is no output schema, so a note on return shape would be beneficial, but the overall definition is still sufficient for correct invocation.

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

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

Schema description coverage is 100%, establishing a baseline of 3. The description adds practical meaning beyond the schema by explaining that event ids are the trailing digits in an event URL (…-tickets-<id>), which helps the agent construct correct input. The `view` and `expand` parameters are already thoroughly documented in the schema, so the description does not need to repeat 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 uses a specific verb and resource: 'Get an Eventbrite event by id'. It further clarifies scope with 'works for any public event, not just yours', which distinguishes it from organization-scoped siblings like eb_org_events. The exact method of identifying the event via trailing URL digits leaves no ambiguity about what the tool operates on.

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

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

The description gives clear operational context: this tool fetches a single event by its id and works on any public event, not only events owned by the user. It also explains how to extract the id from an Eventbrite event URL. It does not explicitly name alternative tools or state when not to use it, so it falls just short of full guidance.

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

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

The readOnlyHint annotation already covers the safety profile, and the description adds useful output context by mentioning barcode, profile answers, and check-in state. There is no contradiction between the description and the annotation.

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

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

The description is a single focused sentence with the operation and key data points front-loaded. The parenthetical adds meaningful detail without 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 simple single-attendee getter backed by a readonly annotation and a fully documented schema, the description is nearly complete. It could be improved by explicitly routing to the plural list tool for collection queries, but nothing essential blocks a correct call.

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

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

The schema description coverage is 100%, with event_id and attendee_id documented and the view parameter thoroughly explained. The tool description does not add parameter-specific detail beyond saying 'by id', so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Get') and resource ('one attendee of an event by id'), and the parenthetical adds the attendee data returned. It clearly implies a singular lookup, which distinguishes it from the plural sibling eb_event_attendees, though it does not name that alternative 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 establishes a clear calling context: use this when you already have an event_id and attendee_id. It does not explicitly state when not to use it or name alternatives such as eb_event_attendees for listing attendees, so it falls short of a 5.

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

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

The readOnlyHint annotation already establishes this is a read operation, so the bar is lower. The description adds meaningful context beyond that: it is organizer-side, requires event access, and signals that repeated full reads are discouraged in favor of changed_since-based incremental polling. These are useful behavioral traits not present in the annotations or schema.

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

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

Two sentences carry the full message: the first defines the operation and scope, the second gives the key usage guidance on incremental polling. There is no redundant wording or restating of schema fields.

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, the description is largely sufficient: it names the resource, the single-event scope, the access requirement, and the preferred polling approach. With no output schema, it could say a bit more about the response shape, and status filtering is left entirely to the schema, so it is not perfect.

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 high (80%), so the schema already documents most parameters. The description enriches changed_since by explaining its polling purpose, and it ties event access to event_id indirectly, but it does not add much for view, status, or continuation beyond what the schema provides.

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

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

The description states a specific action ('List'), a clear resource ('a single event's attendees'), and adds the organizer-side scope. This differentiates it from sibling tools like eb_event_attendee (singular) and eb_org_attendees (organization-wide) without needing to inspect schemas.

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

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

It explicitly gives the incremental polling guidance: 'Use changed_since to poll incrementally instead of re-reading the whole list.' It also notes the access prerequisite. It does not explicitly name alternative sibling tools or say when not to use it, but the context is clear enough for an agent to select it 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 declare readOnlyHint=true and the 'Get' verb is consistent with that, so the safety profile is covered and there is no contradiction. The description adds one small behavioral signal — the response is HTML rather than plain structured data — which matters to callers who may need to render or sanitize it. It says nothing about payload size, auth needs, or rate limits, but the annotation lowers the bar and the description clears it adequately.

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, and the core action is fully front-loaded. It cannot be shortened without losing meaning, and the rich view-parameter documentation in the schema lets the short description get away with being minimal. It could carry slightly more value (e.g., a sibling contrast) without becoming bloated, but as written it is efficiently 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?

For a simple 2-parameter read tool, the schema plus annotation covers the invocation essentials: the required event_id type is documented and the view enum is fully specified. However, with no output schema and no guidance distinguishing this from eb_event_details or eb_event, an agent facing the large sibling set could plausibly invoke the wrong tool. Adequate, but with a real ambiguity gap.

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

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

Schema description coverage is 100% for both parameters, so per the baseline the description need not compensate for schema gaps. The schema's view parameter documentation is unusually strong, explaining the compact/full response shapes and why the server deliberately avoids field projection, while event_id is documented as 'Numeric event id'. The tool description itself adds no parameter meaning beyond the schema, which is acceptable at this coverage level.

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

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

The description states a specific verb ('Get') and a specific resource ('an event's full HTML description'), so an agent knows this fetches the HTML body of an event listing — distinct in resource from the venue, organizer, and order tools. It stops short of 5 because it does not differentiate from the closely related siblings eb_event and eb_event_details, which also target event data, leaving an agent unable to tell them apart without opening their schemas.

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

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

The description offers no when-to-use guidance, no exclusions, and no named alternatives. With 30 siblings including eb_event and eb_event_details in the same event-data domain, the one-line purpose statement gives an agent no basis for selecting this tool over them. Any when-to-use signal is purely implicit in the tool's name and purpose.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses authentication fallback behavior and detailed response-shape semantics: compact drops image/avatar URLs, full returns Eventbrite payload untouched, and no field projection is performed. This is valuable behavioral context an agent would not otherwise know.

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

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

The description is three concise sentences, front-loaded with the core purpose. It has zero filler and each sentence earns its place: what it does, how auth works, and which sibling to prefer.

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 batch-fetch read tool with rich input schema and readOnly/openWorld annotations, the description covers purpose, auth, response-shape choices, and sibling differentiation. Without an output schema, the description gives enough context to call the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds significant extra meaning for the view parameter, explaining exactly what compact/full do and why there is no field projection. It also ties event_ids to the batch-fetch purpose.

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: 'Batch-fetch public event details by id.' This clearly distinguishes the tool from single-resource siblings like eb_event and from ticket-class-specific 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 explicitly says when not to use it: 'For ticket-class detail prefer eb_ticket_classes.' The description also gives useful context about authentication fallback, but does not explicitly contrast with eb_event or other event-fetching siblings.

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

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

The readOnlyHint annotation already covers the safety profile, and the description adds useful permission context: organizer-side access and the requirement that the caller have access to the event. It does not cover pagination or error behavior, but the auth-related disclosure goes beyond the annotation.

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

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

One front-loaded sentence states the verb, resource, and access constraint with no filler. The parenthetical packs organizer scope and authorization into a compact form.

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

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

The schema covers filters, pagination, and response-shape options, and the readOnlyHint covers safety. However, with no output schema and no mention of expected return format or how this compares to the many order-related siblings, the description leaves some context to inference.

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 event_id, view, continuation, and changed_since already described; the tool description itself adds no parameter-level meaning. The status parameter lacks a description, but since the schema carries most of the burden, baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'List a single event's orders.' The parenthetical 'organizer-side; requires access to that event' adds scope and distinguishes it from personal order lists like eb_my_orders and org-wide lists like eb_org_orders.

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 provides implied context: this is for organizers with access to a specific event. However, it does not explicitly state when to prefer this tool over siblings like eb_org_orders, eb_my_orders, or eb_order, leaving routing 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?

The readOnlyHint annotation already signals a safe read operation, and the description's 'List' verb agrees. It adds the useful distinction between custom and canned question banks, but it does not disclose output format or any other behavioral details; with annotation coverage, a 3 is appropriate.

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

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

The description is two purposeful sentences, front-loading the action and resource, then giving the key behavioral toggle. There is no filler or repeated information from the schema.

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

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

For a simple read-only list tool, the description plus rich schema (especially the detailed view parameter covering response shape) gives an agent everything needed to select and invoke it correctly. No output schema is required for this level of complexity.

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

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

Schema description coverage is 100%, so the schema already documents event_id, view, and canned. The description's canned guidance almost exactly repeats the schema's parameter description, adding no new semantic meaning beyond the structured fields.

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

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

The description opens with the verb 'List' and a specific resource ('registration questions an event asks its buyers'), which clearly identifies the operation and object. It also distinguishes the two modes (custom vs canned standard bank), making it easy to separate from the other eb_* sibling 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 gives a clear operational instruction for the canned parameter: set canned=true when the standard question bank is needed instead of the event's custom questions. It does not explicitly name alternative sibling tools or list when-not-to-use exclusions, so it falls just short of a 5.

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

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

The annotations already mark the tool as read-only, idempotent, and open-world. The description adds useful behavioral context beyond that: no auth required, a real network round-trip through the bridge, and the three failure categories it distinguishes. This is meaningful supplementary disclosure with no contradiction.

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

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

The description is a single, information-dense sentence that front-loads the action ('Round-trips a small public... URL') before listing the diagnostic outputs and usage trigger. Every clause earns its place; no filler or repetition.

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

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

There is no output schema, so the description carries the burden of explaining return values, and it does so thoroughly: bridge role, port, version, extension link state, elapsed time, and a plain-English failure hint. It also covers when to use the tool and the absence of auth requirements, making it complete for an agent to invoke correctly.

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

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

There are zero parameters, so the baseline of 4 applies. Nothing about parameters needs to be explained in the description; the empty schema is complete.

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 uses a specific verb ('round-trips') with a concrete public URL, then enumerates exactly what diagnostics it returns (role, port, version, extension link, elapsed time, hint). This clearly identifies the tool as the fetchproxy healthcheck and sets it apart from the sibling Eventbrite data 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 gives an explicit trigger: 'Call this when a real tool fails and you want to know which hop broke.' It does not name alternatives or when-not conditions, but the failure-diagnosis framing is enough for an agent to select it appropriately.

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

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

The description aligns with readOnlyHint=true and adds useful context beyond the annotation: it clarifies that the tool returns the authenticated user's id, name, and primary email. For a simple read-only profile operation, this is meaningful behavioral disclosure, even if error or rate-limit behavior is not mentioned.

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

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

The description is a single, efficient sentence with no wasted words. The verb, target resource, and expected response fields are all front-loaded and immediately actionable.

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 profile tool with one optional, fully documented parameter, the description is complete enough. It names the return fields and authenticated scope, and no output schema is needed for an agent to understand what the tool will return.

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 is already thoroughly documented with compact/full semantics and the no-field-projection policy. The tool description adds no additional parameter information, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Get') and clearly identifies the resource: the authenticated Eventbrite user's profile, with the expected fields listed. It is clear enough to distinguish from most siblings, though it does not explicitly differentiate itself from the similarly named eb_user 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?

There is no guidance about when to use this tool versus alternatives like eb_user, nor any mention of exclusions or prerequisites. The word 'authenticated' implies the self-profile use case, but the description never states the decision rule.

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

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

The readOnlyHint annotation already covers safety, and the description adds useful behavioral context: the response expands the related event, and time_filter affects which orders are returned based on event time. It does not describe pagination limits, ordering, or error cases, but the continuation parameter in the schema already signals pagination. This is reasonably transparent for a simple read-only list tool.

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

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

Two short sentences with no filler. The primary action and scope are front-loaded, and the second sentence covers the key filtering behavior. 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 tool with no required parameters and full schema coverage, the description is largely complete: it identifies the user, the order scope, the attendee perspective, event expansion, and the time filter. The lack of an output schema is partially mitigated by the 'event expanded' hint, though more detail about the returned order shape would make it fully self-sufficient.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters in detail, including the verbose explanation of 'view' and the enum values for 'time_filter'. The description adds only a brief paraphrase of time_filter ('narrows to upcoming or past events') that does not materially exceed the schema. Baseline 3 is appropriate.

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

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

The description names a specific verb ('List'), a clear resource ('the authenticated user's ticket orders'), and an explicit perspective ('attendee side'). This distinguishes the tool from sibling order tools such as eb_org_orders and eb_event_orders. The mention of 'with the event expanded' further clarifies what the result contains.

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 a clear context: it is for the current user's own attendee-side orders. However, it does not explicitly state when to prefer this tool over closely related siblings like eb_order, eb_event_orders, or eb_org_orders, nor does it mention any exclusions. The 'attendee side' phrase implies the distinction but does not make it 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?

With readOnlyHint=true already present, the safety profile is covered. The description adds useful behavioral context: the result is scoped to the authenticated user and the 'organizer side', and the returned id is meant to be reused in other calls. No contradictions with 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 short sentences with zero fluff: the purpose comes first, followed by actionable routing guidance. 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 simple, zero-required-parameter list tool with readOnly annotations and fully documented params, the description is complete. It states what is returned, what scope it covers, and how the returned org id should be used downstream.

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

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

Schema coverage is 100%, and the schema already fully documents view (including compact/full behavior) and continuation. The description does not add parameter-level semantics, 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 and resource ('List the organizations the authenticated user belongs to'), adds the 'organizer side' scope, and explicitly ties the output to downstream eb_org_* tools. This distinguishes it from sibling tools like eb_my_orders or eb_org_events.

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

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

It provides clear context and a concrete follow-up workflow: use the returned org id with eb_org_events / eb_org_attendees / eb_org_orders. It falls just short of a 5 because it does not explicitly state when not to use this tool versus alternatives like eb_my_orders or eb_me.

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

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

The annotations already declare readOnlyHint=true, and the description's 'Get a single order' is consistent with that. The description adds a small bit of domain context by identifying the order as the buyer-side record behind a ticket, but it does not disclose additional behavioral traits such as response size, expansion effects, or error behavior. Given the annotation coverage, a 3 is appropriate.

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

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

The description is two short sentences with no redundancy. It front-loads the core action ('Get a single order by id') and follows with essential provenance for the id parameter. 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 simple get-by-id tool with a fully described input schema and a read-only annotation, the description covers the essential context: the resource, the required parameter's source, and the relationship to list endpoints. The lack of an output schema is partially mitigated by the view parameter's detailed description of compact vs full response shapes, so nothing critical is missing.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by telling the caller where order ids come from ('Order ids appear in eb_my_orders / eb_event_orders results'), which is operationally useful for supplying the required order_id parameter. This goes slightly beyond what the schema provides.

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

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

The description states a specific verb and resource: 'Get a single order by id'. It also contextualizes the resource as 'the buyer-side record behind a ticket', and clarifies that order ids come from eb_my_orders / eb_event_orders results, which differentiates this from the list-oriented sibling tools.

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

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

The description clearly implies when to use the tool: when you already have an order id, particularly one obtained from the listed order-list endpoints. It does not explicitly say when not to use it or name alternatives, but the single-vs-list distinction among siblings is strongly implied.

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

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

The readOnlyHint annotation already covers safety; the description adds that the profile is 'public,' implying the read requires no special permissions. It does not describe error or absent-profile behavior, but there is no annotation contradiction.

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

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

A single front-loaded sentence communicates the essential operation and expected return fields with no filler. The description earns its length.

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 lookup with fully documented parameters and readOnlyHint, the field list is sufficient even without an output schema. It lacks explicit notes about absent or private organizers, but that is a minor gap against the otherwise complete 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?

The input schema covers 100% of parameters, including a detailed description of the view enum and organizer_id format, so the tool description does not need to restate them. The phrase 'by id' reinforces organizer_id's role but adds no new semantics.

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'), with a short list of returned fields (name, description, logo, social links). It is unambiguous against sibling event/venue tools, though it never explicitly contrasts itself with 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?

There is no explicit when-to-use statement or mention of alternatives. The phrase 'by id' plus 'public profile' implies the call is for a single profile lookup, but the description leaves it to the agent to infer that sibling tools cover events and venues.

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

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

The readOnlyHint annotation already covers safety; the description adds a meaningful accessibility trait ('public') and implies broad scope ('everything one organizer is running'). However, it says nothing about pagination, rate limits, defaults, or what happens when no events are found, so it is informative but incomplete.

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 clear, single-sentence description with no filler. The key action and the public distinction are front-loaded, and every word carries information.

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

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

The tool definition gives enough to call it, especially with a well-documented schema for the main parameters. But it omits any relation to the many sibling event-listing tools, which creates real ambiguity for an agent choosing between them, and there is no guidance on typical use cases.

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 already explains view, status, continuation, and organizer_id meaningfully. The description adds no additional parameter semantics, which is acceptable but also not a plus. order_by lacks a description but its enum values are self-explanatory.

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 ('List') and resource ('an organizer's events'), making the core purpose immediately clear. The phrase 'the public way' adds a useful distinguishing hint, though it does not explicitly name sibling tools, so it falls just short of full 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?

There is no explicit guidance on when to use this tool versus alternatives like eb_org_events or eb_series_events. The 'public way' phrase weakly implies a contrast with authenticated/private endpoints, but no direct comparison or exclusion conditions are given.

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

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

Annotations already provide readOnlyHint=true, so the description does not need to restate safety. It adds 'organizer side', which implicitly signals that organizer-level authorization is required, a useful behavioral note. However, it does not disclose other traits like pagination behavior or response shape beyond what the schema parameters (e.g., continuation, view) already explain. Given the annotation coverage, 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?

The description is a single, 8-word sentence that is front-loaded with the core action and scope. Every word earns its place: 'List' states the operation, 'attendees across an organization's events' specifies the resource and breadth, and '(organizer side)' adds access context. 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 list tool with a well-documented schema (100% parameter descriptions, enum explanations, continuation token) and readOnlyHint annotation, the description is sufficient. It clarifies the organizational scope and organizer context. It does not describe return values, but no output schema exists and the schema's pagination parameter implies a paginated list. Minor gap: it does not explicitly state that results aggregate across multiple events, though that is already in the description.

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 input schema has 100% description coverage, so all four parameters (view, org_id, status, continuation) are already documented. The description's phrase 'across an organization's events' reinforces the org_id scope but adds no new meaning beyond the schema's description for org_id (from eb_my_organizations). Baseline 3 is appropriate since the schema carries the semantic load.

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 'List attendees across an organization's events (organizer side)' uses a specific verb ('List'), a specific resource ('attendees across an organization's events'), and adds 'organizer side' to indicate the access context. This clearly distinguishes the tool from sibling tools like eb_event_attendees (single-event attendee list) and eb_event_attendee (single attendee), without needing to open their schemas.

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

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

The description implies usage for organizer-scoped, multi-event attendee listing but does not explicitly mention when to prefer this over alternatives such as eb_event_attendees. The 'organizer side' qualifier hints at the intended audience, and 'across an organization's events' clarifies scope, but no direct when-not or alternative references are given.

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

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

Annotations declare readOnlyHint=true and the description's 'List' matches that read-only behavior with no contradiction. The description adds minimal behavioral context beyond the annotation: it only promises that usage limits are included, and says nothing about pagination behavior or response shape.

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 tightly worded sentence with the verb and resource front-loaded, and no redundant or filler content. The clause 'including their usage limits' is the only useful extra and 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 simple read-only listing tool, the description plus fully documented schema parameters and the readOnlyHint cover what is needed to invoke it correctly. The only minor gap is that the return format and pagination behavior are not described, but these are already implied by the schema and the absence of an output schema lowers the burden.

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 input schema already covers all three parameters with meaningful descriptions, including org_id provenance and continuation-token semantics, so the description does not need to add parameter detail. The description contributes nothing specific to parameter meaning beyond framing the response around discount/access codes.

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

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

Description states a precise action ('List') and a distinctive resource ('an organization's discount and access codes'), and adds the useful detail that usage limits are included. Among the sibling org_* tools, none target discounts/access codes, so the definition distinguishes itself without opening the schema.

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

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

The org-scoped phrasing makes it evident this is for listing discount codes for a specific organization, and no sibling tool overlaps, so usage context is implied. However, the description does not explicitly state when to choose this tool, what prerequisites exist (other than the org_id hint in the schema), or how it relates to other org listing tools.

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

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

The readOnlyHint annotation already discloses that this is a safe read operation. The description adds modest behavioral context by stating the organizational scope and status filtering, but it does not mention pagination behavior or response shape, which would be useful given the continuation parameter. No contradiction with the annotation exists.

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

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

The description is a single, scannable sentence with no filler or redundant phrasing. It front-loads the action and core resource, then appends the optional filter, making it easy for an agent to parse quickly.

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 list tool with a readOnly annotation and a detailed input schema, the basic purpose is adequately conveyed. However, the lack of differentiation from eb_organizer_events, and the absence of any hint about paginated responses or what fields the list returns, leaves meaningful gaps for an agent deciding whether and how to call it.

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 already documents the key parameters clearly, including the status enum, view behavior, and continuation token. The description's mention of status filtering aligns with the schema but does not add new meaning beyond it; the baseline of 3 applies since the schema carries the descriptive weight.

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 ('List'), a clear resource ('an organization's events'), and adds the '(as organizer)' scoping qualifier plus optional status filtering. It is clear on its own but does not explicitly differentiate itself from the sibling tool eb_organizer_events, which likely covers a similar organizer-centered listing.

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_organizer_events or the other listing siblingsasi. The description only mentions an optional status filter, which is a parameter-level detail rather than usage context, and no exclusions or alternative tool references appear.

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

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

Annotations already declare readOnlyHint=true, so the safe read behavior is covered outside the description. The description adds the scoping constraint that this operates across the organization's events and is organizer-facing, but it does not mention pagination flow, permission requirements, or what the response 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?

The description is a single front-loaded sentence with no filler. It states the verb, resource, scope, and audience efficiently without repeating schema or annotation details.

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, the description plus the fully documented schema covers the essential call context: what is listed, from which org, the response shape choice, and pagination via continuation. The only notable gap is the lack of any description of the return payload, but no output schema exists and the endpoint's list nature makes this a minor omission.

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

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

Schema description coverage is 100%, so the schema already documents org_id, view, and continuation thoroughly, including the compact/full view distinction and the source of org_id. The description itself adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

The description is specific: it names the action (list), the resource (orders), and the scope (across an organization's events). The parenthetical '(organizer side)' further distinguishes this from user-facing order tools like eb_my_orders, making its role clear without opening the schema.

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

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

The phrase 'organizer side' and 'across an organization's events' implies when this should be used, but the description never explicitly contrasts it with siblings like eb_event_orders or eb_my_orders. The usage context is present only implicitly, with no exclusions or alternative 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?

Annotations already declare readOnlyHint=true, and the description correctly frames this as a report operation with no side effects. It adds that the report is aggregated and optionally date-windowed, but it does not disclose pagination behavior, grouping effects, or response shape beyond what the schema's 'view' parameter already documents.

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

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

The description is a single, front-loaded sentence that communicates the core function and the key optionality. Every word earns its place, and it remains readable without unnecessary filler.

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

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

For an 8-parameter report tool with no output schema, the description is adequate but has gaps. It explains the high-level purpose and date windowing, and the schema covers most parameters, but it does not clarify what the report returns, how group_by affects rows, or how continuation tokens should be used across calls.

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 carries most parameter meaning. The description reinforces the 'kind' values (sales or attendees) and the optional date window, but it does not add meaning beyond what the schema already provides for parameters like group_by, continuation, or event_status.

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 clearly states a specific verb ('Run'), a resource ('an organization's sales or attendees report'), and the aggregated nature of the output. It does not explicitly name a sibling tool to differentiate from, but 'aggregated analytics behind its events' helps separate it from raw-list tools like eb_org_attendees or eb_org_orders.

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 guidance on when to use this tool versus alternatives such as eb_org_attendees, eb_org_orders, or eb_org_events. The phrase 'aggregated analytics' implies a distinction from raw data tools, but no direct when-to-use or when-not-to-use guidance is given.

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

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

Annotations declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the 'bundled across events' context and the view parameter's behavioral detail (compact strips image/avatar URLs, full returns Eventbrite's payload untouched). It doesn't disclose pagination behavior or rate limits, but the readOnly annotation covers the main 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?

The description is a single clear sentence that front-loads the main purpose. The parenthetical adds useful disambiguation without bloat. The schema's view parameter description is verbose but earns its place by explaining the compact/full distinction and the rationale for not offering field projection.

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 100% schema coverage and a readOnlyHint annotation, the description is mostly adequate. However, it doesn't mention pagination behavior (the continuation parameter implies it), what fields the response contains, or how this relates to eb_ticket_classes. An agent might not know whether to call this or eb_ticket_classes without more explicit guidance.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds minimal extra meaning beyond the schema: it clarifies that org_id comes from eb_my_organizations and that view controls response shape. The view parameter's description is unusually detailed and helpful, but the tool description itself doesn't add much beyond what the schema provides.

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

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

The description states a specific verb ('List') and resource ('an organization's ticket groups'), with a clarifying parenthetical that ticket groups are ticket classes bundled across events. This distinguishes it from eb_ticket_classes (which lists ticket classes for an event) and eb_org_events, though it doesn't explicitly name a sibling.

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

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

The description implies the tool is for listing ticket groups at the organization level, and the org_id parameter description ('from eb_my_organizations') gives a hint about where the ID comes from. However, it doesn't explicitly state when to use this over eb_ticket_classes or other sibling tools, nor does it mention pagination usage beyond the continuation parameter.

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 mark readOnlyHint=true, so the safety profile is covered. The description adds only that the result includes name/address/geo; it does not mention pagination, sorting, or other behavioral traits. With annotations present, this is acceptable 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?

A single front-loaded sentence states the action, scope, and key response fields with no filler. This is appropriately sized for a simple list tool.

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

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

The tool is low-complexity and has strong annotations plus schema explanations for view and continuation. The description supplies enough return-value context (name, address, geo) to compensate for the missing output schema, though it leaves details like venue id and default pagination to inference.

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 clear descriptions for org_id, view, and continuation, so the baseline is 3. The tool description itself contributes no parameter-level meaning, only output fields, so it does not exceed that 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?

The description names a specific verb ('List'), a specific resource ('an organization's saved venues'), and the contained fields ('name, address, geo'). This clearly distinguishes it from siblings like eb_venue (single venue) and eb_venue_events (events at a venue), even without explicitly naming 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?

When to call is implied by the purpose: retrieve the saved venues for an organization. The schema's org_id description adds that the id comes from eb_my_organizations, but the description itself names no alternative or exclusion, so an agent gets no explicit guidance on choosing between this and venue-related siblings.

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

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

The annotation readOnlyHint=true already establishes this is a safe read operation, so the description does not need to restate that. The description adds that the response includes subscribed actions, but it does not disclose other behavioral traits such as pagination behavior, rate limits, or authorization requirements; there is no contradiction.

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

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

The description is a single, front-loaded sentence that names the action and resource without filler. It is concise while still conveying the key output dimension.

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 endpoint with fully described parameters and annotations, the description provides sufficient purpose and output scope. The schema fills in response-shape and pagination details, and no major operational context appears missing.

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

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

The input schema covers all three parameters with descriptions, including the view enum's response-shape semantics and the continuation token's pagination meaning, so schema description coverage is 100%. The tool description itself adds no parameter-level detail, so the baseline of 3 applies.

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

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

The description states a specific verb ('List') and a concrete resource ('an organization's registered webhooks'), and clarifies that the output includes the actions they subscribe to. It is unambiguous and stands apart from sibling tools by resource, though it does not explicitly contrast with other eb_org_* tools.

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

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

The description gives no guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites beyond what is implied by the tool name. A user must infer from the name alone that this is the webhook-listing endpoint.

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

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

The readOnlyHint annotation already signals that this is a safe read operation, and the description's 'List' wording is consistent with that. The description adds useful integration context but does not disclose further operational behavior such as auth requirements, rate limits, pagination, or failure modes. With the annotation lowering the bar, a neutral 3 is appropriate.

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

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

The description is two efficient sentences with no fluff. It front-loads the core purpose, immediately enumerates the valid kinds, and closes with a practical usage insight. Every sentence earns its place.

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

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

With only two parameters, one required, a readOnly annotation, and a low-complexity reference-data task, the description plus schema are complete enough to invoke the tool correctly. The inline id=label examples hint at the response shape, and the view parameter semantics are already fully documented in 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?

The input schema already documents both parameters at 100% coverage, so the baseline is 3. The description adds meaningful value by providing real category id examples and explaining how 'kind' values relate to eb_search_events filters, going slightly beyond the schema's own parameter descriptions.

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

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

The description states a specific verb and resource: 'List Eventbrite reference data', and enumerates exactly which kinds of data are included. It also shows concrete id-to-label examples, which removes ambiguity and makes the tool clearly distinct from the event/order/venue sibling tools.

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

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

The description provides clear downstream context by noting that category/subcategory/format ids feed eb_search_events filters. This tells an agent when fetching this reference data is useful, though it does not explicitly contrast the tool with alternatives or state when not to use it.

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

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

With readOnlyHint 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, so the read-only nature is covered. The description adds that series_id appears on search results and events, which is helpful provenance context. However, it does not disclose response shape, pagination behavior, or what 'occurrences' includes beyond the basic list operation; overall it provides modest additional transparency beyond 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 short sentences, front-loaded with the core action. The second sentence adds relevant input-origin context. No filler, no repetition of schema details, and every sentence earns its place.

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

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

Given the tool's low complexity, full parameter schema coverage, and readOnly annotation, the description is nearly complete for using the tool correctly. It lacks explicit alternative routing and output-shape details, but the absence of an output schema is partially mitigated by the view parameter documentation. Overall, the core information needed to call and understand the tool is present.

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

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

Schema description coverage is 100%, so the schema already documents series_id, view, status, and continuation clearly. The description's mention that search results and events carry series_id essentially repeats the schema's 'from an event/search result'. It adds no new parameter semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

The description states an exact action and resource: 'List the occurrences of a recurring event series.' This clearly identifies what the tool does and distinguishes it from single-event tools like eb_event or eb_event_details by focusing on series occurrences. It also explains where series_id comes from, adding useful context without ambiguity.

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

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

The description implies usage when you have a series_id and need its occurrences, and it tells readers that search results and events carry series_id. However, it does not explicitly compare this tool to sibling tools such as eb_event or eb_search_events, nor does it state when not to use it. The usage context is present but not fully explicit.

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

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

The readOnlyHint annotation already covers the safety profile, and 'Get' aligns with it, so there is no contradiction. The description adds no further behavioral context such as not-found behavior, auth requirements, or response format, but for a simple read operation the annotation carries most of the burden.

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, with the core purpose front-loaded and the usage prerequisite in the second sentence. Every word is purposeful and there is no 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 straightforward read-by-id tool with fully documented parameters and a readOnly annotation, the description covers the necessary workflow and purpose. It does not describe the response shape or error cases, but no output schema exists and the return value is largely inferable from 'Get one ticket class.'

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 each parameter is already well explained, especially the view parameter. The tool description adds only 'by id' and the list-first prerequisite, so it does not significantly add meaning beyond the schema.

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

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

The description opens with a specific verb and resource: 'Get one ticket class of an event by id.' It also names the sibling tool eb_ticket_classes, making the singular-vs-list distinction immediately clear.

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

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

It explicitly instructs the agent to call eb_ticket_classes first in order to list ticket classes, which establishes the correct workflow and points to the relevant alternative. It does not explicitly list when not to use this tool, but the contrast with the list tool is clear enough.

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 the description's 'List' verb is consistent with that. The description adds little behavioral context beyond the verb and the listed output fields, and it does not mention pagination, ordering, or error behavior; with the annotation carrying the safety profile, 3 is appropriate.

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 states the action, resource, and key output fields with no 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 operation with one required parameter and a clearly documented optional view parameter, the description plus schema provides enough for an agent to call the tool correctly. The absence of an output schema is partly mitigated by the listed output fields, though pagination/ordering are not addressed.

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

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

Schema description coverage is 100%, so the schema fully documents event_id and view, including a detailed behavioral explanation of the compact/full view semantics. The tool description itself adds no parameter-level information, meeting the baseline rather than exceeding 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?

The description uses a specific verb (List), a specific resource (an event's ticket classes), and enumerates key output fields (name, cost, free/paid, on-sale status). It is clear enough to distinguish from the sibling eb_ticket_class by the plural scope, though it does not explicitly call out that 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?

The intended use is implied by 'List an event's ticket classes': use when you need the collection of ticket classes for a given event_id. However, there is no explicit when-to-use or when-not-to-use guidance, and no mention of the singular sibling eb_ticket_class for fetching a single class.

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 mark readOnlyHint=true, and the description adds behavioral context by labeling the data as public and contrasting it with the authenticated/private eb_me call. This signals that no special auth is needed for eb_user. It does not cover rate limits/errors, but for a simple read-only profile lookup the disclosure is sufficient.

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 concise sentences with no filler. The core action is front-loaded, and the parenthetical about eb_me earns its place by routing the agent to the correct alternative.

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 read-only tool with no output schema, the description plus schema covers the entire callable surface: required user_id, view behavior, and the alternative for authenticated/private data. Nothing essential is missing for an agent to select and invoke it correctly.

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

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

Schema description coverage is 100%: both user_id and view include descriptions, and view has detailed compact/full semantics. The description itself adds no parameter-level detail, so it stays at the baseline for high schema coverage.

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: 'Get a public user profile by id.' It also distinguishes this tool from eb_me by noting that eb_me targets the authenticated user and returns private fields, making the purpose unambiguous against its siblings.

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

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

The description explicitly gives the selection rule: use eb_user for public profiles by id, and use eb_me for the authenticated user (with private fields). This is direct when-to-use versus alternative guidance.

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

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

Annotations already provide readOnlyHint=true, and the description's 'Get' is consistent with that. The description adds minimal behavioral context (returns name, address, geo) but does not disclose error behavior, auth requirements, or rate limits. Since the safety profile is covered by annotations, 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 sentences, no filler. The core action and resource are front-loaded, and the follow-up sentence provides a useful pointer without digressing. 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 simple ID-lookup tool with no output schema, the description offers a high-level summary of the return fields (name, address, geo) and where to find IDs. It does not cover error handling or edge cases, but given the schema's thorough description of the view parameter and the tool's simple nature, it is nearly complete. A short example or mention of error behavior would push it to 5.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining where a venue_id comes from ('on expanded events and in eb_org_venues'), which helps the agent understand and source the required parameter. The view parameter is fully explained in the schema, so the description's addition is focused and useful.

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

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

The description states a specific verb and resource: 'Get a venue by id (name, address, geo).' It clearly distinguishes this from sibling eb_org_venues (which lists venues) by focusing on fetching a single venue by ID, and it even tells the agent where venue IDs are found (expanded events and eb_org_venues).

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

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

The description implies when to use it: when you have a venue ID it directs you to the sources of those IDs ('Venue ids appear on expanded events and in eb_org_venues'). It does not explicitly name alternatives like eb_venue_events or state when not to use it, but the context is clear enough for an agent to select this tool for a single-venue lookup.

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

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

The readOnlyHint annotation already establishes the safe read-only behavior, and the description's verb 'List' is consistent with that. No additional behavioral context is provided beyond the annotation, but there is no contradiction either.

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

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

The description is a single front-loaded sentence with no filler. Every word contributes to the core purpose, making it appropriately concise for such a simple tool.

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

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

The description is minimally viable for a simple read-only list tool, especially with full schema coverage and the readOnlyHint annotation. However, it lacks explicit usage guidance, output-shape hints, or differentiation from several sibling event-listing 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 coverage is 100%, and the schema thoroughly documents venue_id, status, view, and continuation. The description adds no parameter-level meaning, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'List the events held at a venue.' This clearly identifies the operation and distinguishes it from sibling tools such as eb_venue or eb_org_events, though it does not explicitly name alternatives or exclusions.

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

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

There is no guidance on when to use this tool instead of eb_org_events, eb_organizer_events, eb_series_events, or eb_search_events. The agent must infer selection criteria from the tool name and the venue_id parameter.

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