Eventbrite Events Scraper MCP Server
Enables searching Eventbrite events by location and keyword, or reading specific Eventbrite event URLs, to retrieve event details such as dates, venue, category, organizer, and ticket price range.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Eventbrite Events Scraper MCP Serverfind tech events in San Francisco next month with organizers and prices"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Eventbrite Events Scraper MCP Server
An MCP server for the Mamba Labs Eventbrite Events Scraper actor on Apify. Search Eventbrite events by location and keyword, with organizer and ticket prices.
What's Inside
Related MCP server: mcp-funcheap
What it does
Give a location and keywords, or Eventbrite event URLs. You get one flat row per event with dates, venue, category, organizer, and the ticket price range shown on the event page.
All of the work runs on Apify. This package is a thin client that starts the actor run, waits for it, and hands back the dataset rows.
Quick start
You need Node.js 18 or newer and an Apify account with an API token.
Add this to your Claude Desktop config (claude_desktop_config.json), Cursor, or any MCP client:
{
"mcpServers": {
"mamba-eventbrite-events-scraper": {
"command": "npx",
"args": [
"-y",
"@mambalabsdev/mcp-eventbrite-events-scraper"
],
"env": {
"APIFY_TOKEN": "your-apify-token"
}
}
}
}Restart the client. The search_eventbrite_events tool appears.
Prerequisites
Node.js 18 or newer.
An Apify API token from console.apify.com/account/integrations, set as
APIFY_TOKEN. The server lists its tool without a token; a call needs one.
Example prompts
"List tech events in San Francisco next month with their organizers and ticket prices."
"Which business events are coming up in Austin, TX, and who runs them?"
"Read these Eventbrite event pages and give me the price range of each."
Tool
search_eventbrite_events. One tool. Example arguments:
{
"locations": [
"Austin, TX"
],
"keywords": [
"startup"
],
"max_events": 10
}Inputs
Every buyer facing input of the actor. Omitted inputs take the actor's own defaults.
Input | Type | Required | Description |
| array | 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. |
| array | 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. |
| array | no | Eventbrite event URLs or event IDs, on any Eventbrite domain. Each event page is read for its organizer and price. |
| string | no | Optional, YYYY-MM-DD. Search results that start earlier are skipped and not charged. |
| string | no | Optional, YYYY-MM-DD. Search results that start later are skipped and not charged. |
| boolean | 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. |
| number | 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. |
| number | no | Search pages read for each location and keyword pair, from 1 to 50. A page holds about 20 events. Default 5. |
| string | no | Optional. The run stops before a charge that would pass this amount. Summary rows are always returned. |
Pricing
Pay per event on Apify, billed to your Apify account. Prices in USD.
Event | Free plan | Bronze | Silver | Gold |
| $0.003 | $0.00285 | $0.0027 | $0.00255 |
| $0.0015 | $0.001425 | $0.00135 | $0.001275 |
| $0.007 | $0.00665 | $0.0063 | $0.00595 |
| $0.026 | $0.026 | $0.026 | $0.026 |
Refused pages, missing events, and refused input are free. A search Eventbrite answers is charged once, with or without events. Mamba Labs pays the platform costs of the run, Apify proxy traffic included.
Full actor documentation
apify.com/mambalabs/eventbrite-events-scraper
License
MIT. See LICENSE.
Available Tools
1 toolsearch_eventbrite_eventsSearch Eventbrite eventsARead-onlyIdempotent
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
TDQS
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.
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.
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.
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.
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.
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.0.0- First observed
search_eventbrite_events
TDQS
Scored across 1 tool
With only one tool there is no risk of misselecting between tools, so the agent's choice is trivial. However, the tool bundles two distinct modes (keyword/location search and URL-based page read) under one name, which can make it unclear which behavior will trigger for a given input.
A single, descriptive snake_case verb_noun name (search_eventbrite_events) establishes a clean, predictable convention with no deviations to compare against.
One tool is thin for a scraping domain that naturally splits into search, event detail, and possibly pagination or batch operations. It is workable but feels under-decomposed, especially given the overloaded input modes.
The tool covers both event discovery (search by keyword/location) and retrieval (read by URL) with rich per-event fields, which handles the core read-only scraper lifecycle. There is no pagination or batch control surfaced, but agents can work around it via repeated calls.
Maintenance
Related MCP Connectors
European and US event data from Eventbrite: dates, venues, categories, ticket prices, organizers.
Manage Eventbrite events, ticket classes, venues and discounts; read attendees, orders and reports.
Read Eventzilla events, tickets, orders, attendees and users; open or close ticket sales.
Read events, programmes, speakers, registration orders, tickets and attendance in eventOne.
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables natural language access to the Eventbrite API for creating, managing, and interacting with events, venues, and categories.134 npm4MIT
- AlicenseNot gradedqualityCmaintenanceEnables querying San Francisco Bay Area events from Funcheap, including event details, tags, and categories.454 npmMIT
- FlicenseNot gradedqualityBmaintenanceEnables natural-language event searches through Google Events, returning structured JSON with dates, venues, ticket links, and map details, plus support for localization, filters, and pagination.2-
- FlicenseCqualityBmaintenanceEnables managing events, organizations, venues, ticket classes, attendees, and orders through the Eventbrite API v3, including creating drafts, publishing or unpublishing events, tracking capacity and sold ticket counts, checking in attendees, and reviewing payouts and transfers.871-