Skip to main content
Glama
delorenj

MCP Server for Ticketmaster Events

by delorenj

MCP Server for Ticketmaster

A Model Context Protocol server that provides tools for discovering events, venues, and attractions through the Ticketmaster Discovery API.

Features

  • Search for events, venues, and attractions with flexible filtering:

    • Keyword search

    • Date range for events

    • Location (city, state, country)

    • Venue-specific searches

    • Attraction-specific searches

    • Event classifications/categories

  • Output formats:

    • Structured JSON data for programmatic use

    • Human-readable text for direct consumption

  • Comprehensive data including:

    • Names and IDs

    • Dates and times (for events)

    • Price ranges (for events)

    • URLs

    • Images

    • Locations and addresses (for venues)

    • Classifications (for attractions)

Related MCP server: SeatGeek MCP Server

Installation

Installing via Smithery

To install mcp-server-ticketmaster for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install mcp-server-ticketmaster --client claude

Manual Installation

npx -y install @delorenj/mcp-server-ticketmaster

Configuration

The server requires a Ticketmaster API key. You can get one by:

  1. Going to https://developer.ticketmaster.com/

  2. Creating an account or signing in

  3. Going to "My Apps" in your account

  4. Creating a new app to get your API key

Set your API key in your MCP settings file:

{
  "mcpServers": {
    "ticketmaster": {
      "command": "npx",
      "args": ["-y", "@delorenj/mcp-server-ticketmaster"],
      "env": {
        "TICKETMASTER_API_KEY": "your-api-key-here"
      }
    }
  }
}

Usage

The server provides a tool called search_ticketmaster that accepts:

Required Parameters

  • type: Type of search ('event', 'venue', or 'attraction')

Optional Parameters

  • keyword: Search term

  • startDate: Start date in YYYY-MM-DD format (for events)

  • endDate: End date in YYYY-MM-DD format (for events)

  • city: City name

  • stateCode: State code (e.g., 'NY')

  • countryCode: Country code (e.g., 'US')

  • venueId: Specific venue ID

  • attractionId: Specific attraction ID

  • classificationName: Event category (e.g., 'Sports', 'Music')

  • format: Output format ('json' or 'text', defaults to 'json')

Examples

Structured JSON Output (Default)

<use_mcp_tool>
<server_name>ticketmaster</server_name>
<tool_name>search_ticketmaster</tool_name>
<arguments>
{
  "type": "event",
  "keyword": "concert",
  "startDate": "2025-02-01",
  "endDate": "2025-02-28",
  "city": "New York",
  "stateCode": "NY"
}
</arguments>
</use_mcp_tool>

Human-Readable Text Output

<use_mcp_tool>
<server_name>ticketmaster</server_name>
<tool_name>search_ticketmaster</tool_name>
<arguments>
{
  "type": "event",
  "keyword": "concert",
  "startDate": "2025-02-01",
  "endDate": "2025-02-28",
  "city": "New York",
  "stateCode": "NY",
  "format": "text"
}
</arguments>
</use_mcp_tool>

Development

  1. Clone the repository

  2. Copy the example environment file:

    cp .env.example .env
  3. Add your Ticketmaster API key to .env

  4. Install dependencies:

    npm install
  5. Build the project:

    npm run build
  6. Test with the inspector:

    npm run inspector

Contributing

Contributions are welcome! Please feel free to submit a Pull Request. For major changes, please open an issue first to discuss what you would like to change.

License

MIT License - see LICENSE file for details

Available Tools

1 tool
search_ticketmasterC

Search for events, venues, or attractions on Ticketmaster

ParametersJSON Schema
NameRequiredDescriptionDefault
typeYesType of search to perform
keywordNoSearch keyword or term
startDateNoStart date in YYYY-MM-DD format
endDateNoEnd date in YYYY-MM-DD format
cityNoCity name
stateCodeNoState code (e.g., NY, CA)
countryCodeNoCountry code (e.g., US, CA)
venueIdNoSpecific venue ID to search
attractionIdNoSpecific attraction ID to search
classificationNameNoEvent classification/category (e.g., "Sports", "Music")
formatNoOutput format (defaults to json)json

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries full burden but provides minimal behavioral insight. It mentions searching but doesn't disclose rate limits, authentication needs, pagination, error handling, or what happens with partial/no results. This is inadequate for a search tool with 11 parameters.

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?

The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It earns its place by clearly stating the tool's function in minimal space.

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

Completeness2/5

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

For a complex search tool with 11 parameters, no annotations, and no output schema, the description is insufficient. It lacks details on behavior, output format (beyond the 'format' parameter), error cases, and usage context, leaving significant gaps for an AI agent.

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 description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying search across multiple resource types, which aligns with the 'type' parameter. Baseline 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Search') and resources ('events, venues, or attractions on Ticketmaster'), making the purpose immediately understandable. It doesn't need to distinguish from siblings since none exist, but it could be more specific about what 'search' entails (e.g., listing vs. filtering).

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives or any prerequisites. The description merely states what it does without context about appropriate scenarios, limitations, or integration with other tools.

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

TDQS

B3.1/5.0
Disambiguation5/5

With only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is clearly defined as searching for events, venues, or attractions, making it straightforward for an agent to understand its function without confusion.

Naming Consistency5/5

Since there is only one tool, naming consistency is inherently perfect. The tool name 'search_ticketmaster' follows a clear verb_noun pattern, which would be consistent if more tools were added, but as a standalone, it sets a good precedent.

Tool Count2/5

A single tool is too few for a server focused on Ticketmaster events, which typically involves operations like browsing events, getting details, checking availability, or purchasing tickets. This minimal set feels thin and incomplete for the apparent scope, limiting agent capabilities.

Completeness2/5

The tool surface is severely incomplete for the domain of Ticketmaster events. While search is a useful starting point, there are obvious gaps such as retrieving event details, listing venues, checking ticket availability, or handling bookings, which are essential for comprehensive event management workflows.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    Enables users to search for events, performers, and venues through the SeatGeek API. Provides event recommendations, detailed venue seating information, and performer discovery capabilities for ticketed entertainment events.
    4
    3
    MIT
  • A
    license
    C
    quality
    D
    maintenance
    Enables discovery and search of Ticketmaster events, venues, and attractions with advanced filtering options including date ranges, location-based search, and event classifications through the Ticketmaster Partner API.
    1
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/delorenj/mcp-server-ticketmaster'

If you have feedback or need assistance with the MCP directory API, please join our Discord server