Eventbrite Events Scraper MCP Server

Search Eventbrite events

search_eventbrite_events

Read-onlyIdempotent

Find Eventbrite events by location, keyword, or event URL and return flat rows with dates, venue, category, organizer, and ticket price ranges.

Instructions

Search Eventbrite events by location and keyword, or read events by URL. Returns one flat row per event with dates, venue, category, organizer, and ticket price range. Refused pages and missing events are free rows. Costs 0.003 USD per event with its page read, 0.0015 USD per event from search only, 0.007 USD per search Eventbrite answers (with or without events), plus 0.026 USD per run start.

Input Schema

Name	Required	Description
`keywords`	No	Search words, such as tech, startup, or yoga. Each keyword is searched in each location. Leave empty to list all events in a location.
`locations`	No	Places to search, one per line: "City, Region" such as "Austin, TX" or "London, United Kingdom", an Eventbrite location slug such as ca--san-francisco, or online. A location Eventbrite does not know returns a free row.
`event_urls`	No	Eventbrite event URLs or event IDs, on any Eventbrite domain. Each event page is read for its organizer and price.
`max_events`	No	The most events to return in this run, across every search and URL, from 1 to 2,000. Default 50. Text or a number.
`read_details`	No	true (default) or false. With true, each event page is read for the organizer name and the ticket price range, at the event row with details price. With false, rows come from search pages only, at the lower event row price, with no organizer name and no price.
`start_date_to`	No	Optional, YYYY-MM-DD. Search results that start later are skipped and not charged.
`max_charge_usd`	No	Optional. The run stops before a charge that would pass this amount. Summary rows are always returned.
`start_date_from`	No	Optional, YYYY-MM-DD. Search results that start earlier are skipped and not charged.
`max_pages_per_search`	No	Search pages read for each location and keyword pair, from 1 to 50. A page holds about 20 events. Default 5.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 9, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the exact cost model, including differential pricing for detail-read rows versus search-only rows and a per-run start fee. It also states failure behavior ('Refused pages and missing events are free rows'), which is precisely the kind of behavior an agent cannot infer from readOnlyHint/openWorldHint.

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?

Front-loaded with capability and mode selection, then return shape, then failure semantics, then cost. Three sentences, and each one carries information an agent needs before calling.

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?

With no output schema, the description supplies the return shape (one flat row per event with dates, venue, category, organizer, price range) and error-row behavior. Pricing and page limits are also exposed. The only gap is the lack of any mention that the three selector inputs are alternatives rather than cumulative, which the agent must infer from the schema.

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 coverage is 100%, so parameter meaning is already fully carried by the schema and the baseline is 3. The description only indirectly informs parameter choice by tying the 0.003 versus 0.0015 USD tiers to reading event pages, implying the read_details tradeoff; it adds no format or constraint detail beyond the schema.

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?

States specific verbs and resources ('Search Eventbrite events by location and keyword, or read events by URL') and names both operating modes in one sentence. An agent immediately knows the tool both discovers and hydrates events, and what one row represents.

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

Usage Guidelines4/5

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

The opening sentence gives a clear routing rule between the two modes: keyword/location search versus URL lookup. It does not state exclusions or prerequisites (e.g. that at least one of keywords/locations/event_urls is effectively needed), which keeps it 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.

Deploy Server

Other Tools

search_eventbrite_eventsA