Skip to main content
Glama
Eventbrite Events Scraper MCP Server

Eventbrite Events Scraper MCP Server

Eventbrite Events Scraper MCP Server

npm version license

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

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

locations

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.

keywords

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.

event_urls

array

no

Eventbrite event URLs or event IDs, on any Eventbrite domain. Each event page is read for its organizer and price.

start_date_from

string

no

Optional, YYYY-MM-DD. Search results that start earlier are skipped and not charged.

start_date_to

string

no

Optional, YYYY-MM-DD. Search results that start later are skipped and not charged.

read_details

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.

max_events

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.

max_pages_per_search

number

no

Search pages read for each location and keyword pair, from 1 to 50. A page holds about 20 events. Default 5.

max_charge_usd

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

event-detail-row, one event with its event page read (organizer and price)

$0.003

$0.00285

$0.0027

$0.00255

event-row, one event from a search page only (read_details false)

$0.0015

$0.001425

$0.00135

$0.001275

search, one location and keyword search that Eventbrite answered, with or without events

$0.007

$0.00665

$0.0063

$0.00595

apify-actor-start, per run start

$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 tool
search_eventbrite_eventsSearch Eventbrite eventsA
Read-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.

NameRequiredDescriptionDefault
keywordsNoSearch words, such as tech, startup, or yoga. Each keyword is searched in each location. Leave empty to list all events in a location.
locationsNoPlaces 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_urlsNoEventbrite event URLs or event IDs, on any Eventbrite domain. Each event page is read for its organizer and price.
max_eventsNoThe most events to return in this run, across every search and URL, from 1 to 2,000. Default 50. Text or a number.
read_detailsNotrue (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_toNoOptional, YYYY-MM-DD. Search results that start later are skipped and not charged.
max_charge_usdNoOptional. The run stops before a charge that would pass this amount. Summary rows are always returned.
start_date_fromNoOptional, YYYY-MM-DD. Search results that start earlier are skipped and not charged.
max_pages_per_searchNoSearch pages read for each location and keyword pair, from 1 to 50. A page holds about 20 events. Default 5.

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.0.0
    • First observedsearch_eventbrite_events

TDQS

A4.3/5.0

Scored across 1 tool

Disambiguation4/5

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.

Naming Consistency5/5

A single, descriptive snake_case verb_noun name (search_eventbrite_events) establishes a clean, predictable convention with no deviations to compare against.

Tool Count3/5

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.

Completeness4/5

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

ActivityMaintained
ResponsivenessNo recent community issues

Related MCP Connectors

Related MCP Servers