Skip to main content
Glama
chrischall

eventbrite-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

eb_my_orders

Read-only

List the authenticated user's ticket orders with event details, filtering by upcoming or past events to find relevant purchases.

Instructions

List the authenticated user's ticket orders (attendee side), with the event expanded. time_filter narrows to upcoming or past events.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viewNoResponse shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact strips image/avatar URLs from the response; "full" returns Eventbrite's payload untouched. No field projection on this tool: this server has no verified record of which Eventbrite fields matter here, and inventing one would risk dropping a field a caller needs.
time_filterNoFilter orders by event time (default all)
continuationNoPagination continuation token from a previous response

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Changed1 schema field changedv0.3.1
    • addedInput schema / properties / view
      Added value: +{
+  "description": "Response shape: \"compact\" (default) drops fields the response already carries elsewhere; \"full\" returns every field this server understands. compact strips image/avatar URLs from the response; \"full\" returns Eventbrite's payload untouched. No field projection on this tool: this server has no verified record of which Eventbrite fields matter here, and inventing one would risk dropping a field a caller needs.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}
  3. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

Deploy Server

Other Tools