Skip to main content
Glama
Sign In
tickets-dev-mcp

tickets-dev-mcp

Official
by Tickets-dot-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Find events

find_events
Read-only

Search upcoming events by name, performer, venue, or marketplace URL and return each event’s listing URLs across supported ticket marketplaces.

Instructions

Find upcoming events by name, performer, venue or any marketplace event URL, with the same event's URL on every marketplace that lists it (Ticketmaster, StubHub, SeatGeek, Vivid Seats, TickPick, Gametime, Viagogo and more). Never billed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "find_events"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoLatest date, ISO 8601
fromNoEarliest date, ISO 8601
queryYese.g. "eagles sphere" or a stubhub.com event URL

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover read-only and open-world behavior, so the bar is lower, and the description adds real value: results include each event's URL across eight named marketplaces, and 'Never billed' signals no cost to the caller. It stops short of describing pagination or how many results are returned.

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?

One sentence, front-loaded with the verb and lookup keys, with the marketplace list placed in a parenthetical rather than leading. The trailing 'Never billed' is a slight non sequitur but is short and useful.

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 carries return-shape duty and does so by explaining that results pair each event with its URLs on multiple marketplaces. The main gap is how the from/to date filters interact with 'upcoming' and what the result set ordering is.

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?

Schema coverage is 100%, so baseline is 3, but the description extends the meaning of `query` beyond the schema's examples by stating it accepts performer names, venue names, and any marketplace event URL (not just StubHub). The from/to window is only loosely implied by 'upcoming'.

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 a specific verb (find) and resource (upcoming events), plus the accepted lookup keys (name, performer, venue, marketplace URL) and the distinctive cross-marketplace URL aggregation. This clearly separates it from get_listings and compare_prices, which operate on an already-identified event.

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

Usage Guidelines3/5

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

The description implies this is the discovery entry point before get_listings/compare_prices/get_seat_map, but it never names those siblings or states when not to use it. An agent can infer the workflow, but nothing explicit routes it.

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