Skip to main content
Glama
chrischall

eventbrite-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

eb_search_events

Read-only

Search public Eventbrite events with keyword, location, date, category, and price filters. Resolve location to place id using eb_resolve_place, then retrieve matching event details.

Instructions

Search public Eventbrite events (the consumer search absent from the documented API). Resolve the location to a place id first with eb_resolve_place. Filters: keyword, dates, category/subcategory/format ids (see eb_reference), free/paid, online-only. Answers with the slim per-event projection by default; pass view:"full" for Eventbrite's whole search envelope.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoKeyword query
aggsNoFacet buckets to aggregate alongside results
pageNoPage number (default 1)
viewNoResponse shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact returns { id, name, start date/time, timezone, venue, city, online flag, free/sold-out flags, organizer, summary, url } per event; "full" returns Eventbrite's whole search envelope, every field included.
priceNo
place_idNoEventbrite place id from eb_resolve_place (e.g. 85981333 = Charlotte NC)
format_idNoFormat id
page_sizeNoResults per page (default 20)
category_idNoCategory id (eb_reference categories)
date_keywordNoRelative date filter
date_range_toNoISO date upper bound (YYYY-MM-DD)
subcategory_idNoSubcategory id
date_range_fromNoISO date lower bound (YYYY-MM-DD)
online_events_onlyNo

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. Changed2 schema fields changedv0.3.1
    • removedInput schema / properties / compact
      Removed value: -{
-  "description": "Return slim event summaries instead of full records (default false)",
-  "type": "boolean"
-}
    • 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 returns { id, name, start date/time, timezone, venue, city, online flag, free/sold-out flags, organizer, summary, url } per event; \"full\" returns Eventbrite's whole search envelope, every field included.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "type": "string"
+}
  3. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server

Other Tools