What can you do with this server?

etix-mcp lets you discover and explore events, venues, and performers on Etix.com. Here's what you can do: * Search (etix_search): Search for events, venues, and performers by keyword (e.g., artist name, event name, venue name) and get top matches with their IDs and canonical Etix URLs. * Get event details (etix_get_event): Retrieve complete information for a specific event by ID — including name, date/time, venue address and coordinates, organizer, ticket price range, and individual priced offer levels. * Get venue details (etix_get_venue): Fetch a venue by ID to get its name, organizer, full address, and a list of all upcoming events at that venue (each with event ID, name, start time, and ticket URL). * Resolve locations (etix_find_location): Convert a city name or postal code into geographic coordinates (latitude/longitude) plus a normalized city/state — useful for location-based event browsing. * Diagnose connectivity (etix_healthcheck): Run an end-to-end health check of the fetchproxy bridge to identify which hop is failing when other tools aren't working.

How do I use etix-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@etix-mcp search for upcoming comedy shows in Chicago" 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.

etix-mcp

by chrischall

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

etix-mcp

Etix event discovery as an MCP server for Claude — search events, venues, and performers and pull full event/venue details via natural language.

⚠️ Etix does not publish a public consumer API, and its consumer site sits behind a DataDome bot-wall. This server reads the same /ticket/api/online/... endpoints and server-rendered pages that etix.com itself uses, routed through your own signed-in browser tab via the fetchproxy extension. Every request acts on behalf of your existing session — your cookies, your TLS, your JS context — exactly as if you'd browsed it yourself. No Etix account is required; this is public discovery data. Use at your own discretion.

Tools

Tool	Purpose
`etix_search`	Search events, venues, and performers by keyword. Returns a few top matches per category, each with its id and canonical etix.com URL.
`etix_get_event`	Full record for an event/performance by `event_id` — name, date/time, venue (with address + coordinates), organizer, ticket price range and the individual priced offer levels.
`etix_get_venue`	A venue by `venue_id` — name, organizer, full address, and the list of upcoming events at that venue.
`etix_find_location`	Resolve a city name or postal code to coordinates plus normalized city/state — a building block for location-based event browsing.
`etix_healthcheck`	End-to-end bridge check — round-trips `/robots.txt` and reports which hop failed (bridge down vs. extension not connected vs. DataDome challenge on your tab). Call when other tools fail.

Related MCP server: Ticketmaster Discovery MCP Server

How it works

Etix fronts its consumer site with a DataDome interstitial that a server-side fetch can't clear, so etix-mcp routes every request through your signed-in, already-cleared etix.com tab via the shared fetchproxy bridge (WebSocket on 127.0.0.1:37149). etix_search reads the clean search/suggest JSON endpoint; etix_get_event and etix_get_venue parse the server-rendered performance/venue pages (schema.org JSON-LD + microdata). See docs/ETIX-API.md for the verified endpoint shapes.

Setup

See skills/etix/SKILL.md for full install steps: add the server to your MCP config, install the shared fetchproxy extension, open etix.com, and approve the one-time pairing. Then run etix_healthcheck.

Development

npm ci
npm run build   # tsc --noEmit + esbuild bundle → dist/bundle.js
npm test        # vitest

Acknowledgement of Terms

By using this MCP server, you acknowledge that it uses your own etix.com session via the fetchproxy extension, that Etix offers no public consumer API (so the underlying endpoints may change at any time), and that this is an unofficial, AI-developed project with no affiliation to Etix. Use at your own discretion, consistent with Etix's Terms of Use.

License

MIT — developed and maintained by AI (Claude Code).

Available Tools

5 tools

etix_find_locationResolve a city or postal code to coordinatesA

Read-onlyIdempotent

Resolve a city name or postal code to coordinates (latitude/longitude) plus the normalized city/state, using Etix's geolocation lookup. Useful as a building block for location-based event browsing. Read-only, no Etix account required.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	A city (optionally "City, ST") or a postal code, e.g. "Charlotte, NC" or "28202".
`country`	No	Country code/name to scope the lookup. Defaults to "USA".

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already provide readOnlyHint, idempotentHint, openWorldHint. Description adds 'Read-only, no Etix account required' which reinforces and adds practical context. No contradictions.

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 sentences, no wasted words. Front-loaded with purpose, then usage hint and constraints. Perfectly concise.

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 simple geolocation tool with no output schema, description adequately covers return type (coordinates plus normalized city/state). Could explicitly mention lat/lng precision, but still sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% coverage on two parameters. Description adds example format ('City, ST' or postal code) and default country, going beyond schema descriptions. Provides clear usage guidance for each parameter.

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?

Clearly states the tool resolves a city or postal code to coordinates (latitude/longitude) plus normalized city/state. The verb 'resolve' and resource are specific. Distinct from sibling tools which focus on events, venues, health checks, and general search.

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?

Explicitly says 'useful as a building block for location-based event browsing', indicating when to use. Also notes 'Read-only, no Etix account required', providing context. Lacks explicit when-not-to-use or alternative tools, but the purpose is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

etix_get_eventGet an Etix event/performance by idA

Read-onlyIdempotent

Fetch a single Etix event (performance) by its numeric event_id — name, date/time, venue (with address + coordinates), organizer, ticket price range and the individual priced offer levels. Get the event_id from etix_search. Read-only, no Etix account required.

ParametersJSON Schema

Name	Required	Description	Default
`event_id`	Yes	Etix event/performance id (e.g. 39004863). From etix_search.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already provide readOnlyHint, idempotentHint, openWorldHint. The description adds that it is read-only and requires no Etix account, plus details on return fields. No contradiction.

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 sentences, front-loaded with verb 'Fetch', no unnecessary words. Efficient and clear.

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?

Given one parameter, good annotations, and no output schema, the description adequately explains return fields. Could add format details but 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?

Only one parameter, event_id, with schema description and example. The description adds minimal extra meaning beyond the schema, which already covers it. 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 specifies 'Fetch a single Etix event (performance) by its numeric event_id' and lists returned fields, distinguishing it from siblings like etix_search (which searches) and etix_get_venue (which gets venue).

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 description states 'Get the event_id from etix_search', implying when to use this tool after a search. It does not explicitly provide exclusions or alternatives, but context suggests clear usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

etix_get_venueGet an Etix venue and its upcoming events by idA

Read-onlyIdempotent

Fetch a single Etix venue by its numeric venue_id — name, organizer, full address, and the list of upcoming events at that venue (each with event_id, name, start time, and ticket URL). Get the venue_id from etix_search. Follow up with etix_get_event for any listed event. Read-only, no Etix account required.

ParametersJSON Schema

Name	Required	Description	Default
`venue_id`	Yes	Etix venue id (e.g. 17987). From etix_search.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already provide readOnlyHint, idempotentHint, and openWorldHint. Description adds 'Read-only, no Etix account required' and describes the response content. No contradictions.

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 concise sentences, front-loaded with action verb, no redundant information. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (1 param, no output schema, annotations covering safety), the description fully covers what the tool does, input source, follow-up steps, and constraints. No missing critical information.

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?

Only one parameter (venue_id) with 100% schema description coverage. Description reinforces it's numeric and from etix_search but does not add significant new meaning 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?

The description clearly states the tool fetches a single Etix venue by numeric venue_id and lists returned fields (name, organizer, address, upcoming events). It distinguishes from siblings by referencing etix_search for the ID and etix_get_event for follow-up.

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?

Explicitly instructs to get venue_id from etix_search, follow up with etix_get_event, and states it is read-only with no account required. Clear when-to-use and alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

etix_healthcheckVerify the fetchproxy bridge end-to-endA

Read-onlyIdempotent

Round-trips a small public www.etix.com URL (/robots.txt) through the fetchproxy bridge and returns diagnostics: the bridge's role (host/peer/null), port, version, the extension link (linked / pair pending / not attached / never answered), the elapsed round-trip time, and a plain-English hint distinguishing 'bridge never came up' from 'extension not connected' from 'real www.etix.com-side problem'. Read-only, no auth required. Call this when a real tool fails and you want to know which hop broke.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses no-auth requirements, a fixed public URL, diagnostic fields including the bridge role and link state, and a hint that differentiates failure modes. This fully describes observable behavior without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense sentence carries a lot of diagnostic detail and could be split for readability, but every clause earns its place and the core action is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Since there is no output schema, the description compensates by enumerating exactly what diagnostics are returned and how to interpret them. A no-parameter diagnostic tool needs little else for correct invocation.

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?

The input schema has zero parameters, so the baseline 4 applies; the description confirms the fixed round-trip target (/robots.txt), leaving no ambiguity about inputs.

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 concrete action ('Round-trips a small public www.etix.com URL') and identifies the resource and diagnostic purpose. It clearly distinguishes this from the sibling content tools by framing it as a bridge health check rather than a data lookup.

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?

It gives an explicit trigger: 'Call this when a real tool fails and you want to know which hop broke.' It does not name alternative tools or spell out when not to use it, but the diagnostic context is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

etix_searchSearch Etix events, venues, and performersA

Read-onlyIdempotent

Search Etix by keyword and get matching events (performances), venues, and performers — each with its id and canonical etix.com URL. Follow up with etix_get_event (event_id) or etix_get_venue (venue_id) for full details. Backs onto Etix's public suggest endpoint; returns a few top matches per category, not an exhaustive list. Read-only, no Etix account required.

ParametersJSON Schema

Name	Required	Description	Default
`keywords`	Yes	Search text — an artist, event, or venue name (e.g. "jazz", "Marion Meadows").

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. Description adds that it's read-only and requires no Etix account, and that the backend is a public suggest endpoint returning a limited set of top matches. This adds value beyond annotations without contradiction.

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, front-loaded with the action, no wasted words. Every sentence provides useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Description fully explains what the tool returns (events, venues, performers with IDs and URLs) and how to proceed with other tools. No output schema needed, but the description covers the essential context for an agent to use the tool correctly.

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% with a clear description for the keyword parameter. The main description adds no additional meaning for the parameter itself, just context about the return structure. 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 clearly states the tool searches Etix by keyword and returns matching events, venues, and performers with IDs and URLs. It distinguishes itself from sibling tools by mentioning follow-up tools like etix_get_event and etix_get_venue.

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?

Explicitly states when to use (keyword search) and the nature of results (top matches, not exhaustive). Advises follow-up with specific tools for full details. Provides clear context for usage.

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.

5 tool updatesv0.2.0Jun 12, 2026
- First observedetix_find_location
- First observedetix_get_event
- First observedetix_get_venue
- First observedetix_healthcheck
- First observedetix_search

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.5/5.0

Scored 2026-09-10 22:59 across 5 tools

Disambiguation5/5

Each tool targets a clearly distinct responsibility: healthcheck for diagnostics, find_location for geocoding, search for discovery, and get_event/get_venue for fetching specific resources. There is no meaningful overlap between any two tools.

Naming Consistency5/5

All tools share the etix_ prefix and use a consistent snake_case pattern with a clear action or resource name, such as etix_get_event and etix_search. The naming is uniform and predictable.

Tool Count5/5

Five tools is well-scoped for a read-only event discovery server. Each tool serves a distinct purpose without unnecessary bloat or missing essentials.

Completeness4/5

The server covers the main discovery workflow: search, fetch event details, fetch venue details, and geolocation. Minor gaps exist such as lack of performer detail retrieval and limited search result depth, but the core read-only surface is coherent.

Maintenance

ActivityActive

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Related MCP Connectors

Nevent MCP A
io.github.nevent-dev
Talk to your live-events CRM (campaigns, analytics, paid ads, segments) in Claude and ChatGPT.
CRM Marketing
5921
good_wook B
com.mino-yakking
Ask Claude about Phish shows: setlists, song gaps, jams, venues. Live from Phish.net.
Entertainment & Media Search
111
QuallaaOAuth
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2
agentorist A
com.agentorist
Booking gateway for AI agents — discover events, movies & hotels, hand off to partner checkout.
Travel & Transportation Entertainment & Media
72

Related MCP Servers

MCP Live Events Server
Search Entertainment & Media Agent Orchestration
mmmaaatttttt
F
license
B
quality
D
maintenance
This server integrates with the Ticketmaster API to provide AI agents with real-time concert and event data, enabling dynamic fetching and formatting for ease of interpretation.
Updated 2 years ago (2025-02-10 03:03 UTC)
1
2
-
Ticketmaster Discovery MCP
Search Entertainment & Media
ag2-mcp-servers
F
license
Not graded
quality
D
maintenance
An MCP Server that enables interaction with Ticketmaster's Discovery API for accessing event, venue, and artist information through natural language commands.
Updated a year ago (2025-07-16 14:32 UTC)
-
Local Events Finder
Entertainment & Media Travel & Transportation
raheeltanvir
F
license
B
quality
D
maintenance
Connects Claude to the Ticketmaster API to let users discover local events by city, category, keyword, or weekend through natural conversation.
Updated 3 months ago (2026-06-04 18:16 UTC)
4
-
gigora-mcp
Entertainment & Media Search
sezgimeydanci
F
license
Not graded
quality
C
maintenance
Live-concert discovery MCP server: search concerts, artist tour dates, festivals and shows by city. Gives AI assistants real-time access to Gigora's global live-music data.
Updated 2 months ago (2026-07-12 21:57 UTC)
-