PropLineofficial
A
licenseA
qualityA
maintenanceLive sports betting odds, cross-book +EV, and graded player-prop resolution across 13 books.
11
1,893 npm
1
MIT
TicketsData
Server Details
Real-time ticket listings, prices and fees across major ticket marketplaces.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.5/5.0
Scored across 4 tools
Disambiguation5/5
Each tool targets a distinct scope: list_marketplaces is metadata, find_events discovers URLs, get_event_listings fetches single-market listings, and compare_marketplaces does cross-market comparison. The descriptions explicitly state when to use compare_marketplaces versus get_event_listings, eliminating the main overlap risk.
Naming Consistency5/5
All four names follow a strict verb_noun snake_case pattern (compare_marketplaces, find_events, get_event_listings, list_marketplaces). The verbs are distinct and accurately reflect each action.
Tool Count4/5
Four tools is slightly lean but each earns its place across discovery, retrieval, comparison, and reference. The surface is well-scoped to a read-only ticketing data API, though a filtering or search helper could round it out.
Completeness4/5
The lifecycle is coherent: reference → discovery → single-market listings → cross-market comparison, and read-only scope means no create/update/delete is expected. Minor gaps exist, such as no cross-marketplace event search by criteria beyond a discovered URL.
Available Tools
5 toolsanalyze_listingsFilter, sort and summarise fetched listingsRead-onlyIdempotentInspect
Work on the COMPLETE response of an earlier get_event_listings, compare_marketplaces or find_events call, including items too many to show inline. Pass the file link from that result. Free: spends no credits and makes no new fetch. Works for 15 minutes after the fetch, only for the account that made it. For marketplace listings it uses one standard row per listing with the same field names on every marketplace: section, row, quantity (tickets available), splits (quantities you can buy), price (per ticket before fees), fees, price_total (all-in per ticket), face_value, currency, notes, area, ticket_type, inventory_type, deal_score, delivery, is_parking, listing_id, marketplace. Any other field name is read from the original listing (prefix 'raw.' to force that). compare_marketplaces results merge every marketplace's listings into one list with a marketplace field. Filter with conditions (AND) and tickets, sort, pick fields, get min/median/max of a numeric field, and count or price items per group (per section, per marketplace, per row). Every reply includes an overview of all matches: count, tickets, price range and the cheapest listing.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | The file link from an earlier result (https://mcp.ticketsdata.com/mcp?file=...) or just its token. | |
| limit | No | How many matching items to return (0 for summary only). Default 50. | |
| where | No | Conditions every returned item must meet, combined with AND. Example: [{"field":"price_total","op":"<=","value":300},{"field":"section","op":"in","value":["101","102"]}]. | |
| fields | No | Return only these fields of each item. Omit to return the standard rows (or raw items when there is no standard view). | |
| offset | No | Skip this many matching items, for paging. | |
| sort_by | No | Field to sort matches by, e.g. 'price_total'. Numbers (including prices written as text) sort numerically. Items without the field go last. | |
| tickets | No | Keep only listings where exactly this many tickets can be bought together (uses splits, or quantity when the marketplace gives no splits). | |
| group_by | No | Field to group matches by, e.g. 'section' or 'marketplace'. Returns count per group (and prices with stats_field), cheapest group first. | |
| list_path | No | Dotted path of a list in the raw response to analyze instead, e.g. 'body.events'. Turns off the standard view. | |
| descending | No | Sort from highest to lowest. | |
| include_raw | No | Add the original listing under 'raw' to each standard row. | |
| stats_field | No | Numeric field to summarise over ALL matches: min, p25, median, p75, max, mean. Also adds min, median and max to each group. |
compare_marketplacesCompare one event across marketplacesRead-onlyIdempotentInspect
Cross-market report for ONE event. Give any marketplace's event URL: TicketsData finds the same event on the other marketplaces, fetches all of them live, and returns matched URLs, normalized listings per marketplace, per-market price and fee summaries, the cheapest all-in entry point and per-section price spreads between marketplaces. Returns the complete TicketsData API response, unchanged: always as a link to a JSON file, and also inline (the report's analytics in full, listings cut to the first part when large). The report also contains each matched marketplace's own full listings response, so there is no need to call get_event_listings for those marketplaces afterwards. EXPENSIVE: costs 1 report plus up to 12 API credits and takes 20 to 60 seconds. Needs a Pro plan or above. Only one can run at a time per account. Use get_event_listings instead when the user asks about a single marketplace.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| event_url | Yes | Full event URL from ticketmaster, stubhub, seatgeek, vividseats, gametime, tickpick or viagogo. |
find_eventsFind events for a performer or venueARead-onlyIdempotentInspect
List upcoming events for a performer, artist, team, organizer or venue page on one marketplace. Use it to discover event URLs, then pass one to get_event_listings or compare_marketplaces. Real time, costs 1 API credit. Returns the complete TicketsData API response, unchanged: always as a link to a JSON file, and also inline when it is small enough. Pass performer_url for most platforms. venue_url is for dice only (dice.fm/venue/... and dice.fm/promoters/... pages). For eventbrite pass the organizer page URL as performer_url. viagogo and axs are not supported here.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Marketplace id: ticketmaster, stubhub, seatgeek, vividseats, gametime, tickpick, dice, eventbrite. | |
| venue_url | No | dice only: venue or promoter page URL. | |
| performer_url | No | Performer, artist, team or organizer page URL on that marketplace. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations (readOnly/idempotent/openWorld) by disclosing real-time execution, a cost of 1 API credit, and the exact return shape: the complete TicketsData API response unchanged, always as a JSON-file link and inline when small. It also flags unsupported marketplaces, which is behavioral context the annotations cannot convey.
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?
Front-loads the purpose and workflow before cost, return format, and parameter routing, and every sentence carries actionable information. It is somewhat dense with five sentences of guidance, but none is filler, so it stays close to optimal.
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?
Without an output schema, the description compensates by explaining that the raw API response is returned as a JSON link plus optional inline. Combined with cost, real-time behavior, platform coverage, and parameter routing, an agent has everything needed to call it correctly.
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 the baseline is 3, but the description adds real routing value beyond the schema: it resolves when to use performer_url versus venue_url (dice only) and clarifies that eventbrite organizers go in performer_url. This meaningfully reduces parameter-selection error even though the per-parameter text is already present.
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 and resource ('List upcoming events') and scopes it to a performer/venue page on one marketplace. It also distinguishes itself from siblings by naming get_event_listings and compare_marketplaces as downstream tools for the URLs it produces.
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 it ('Use it to discover event URLs, then pass one to get_event_listings or compare_marketplaces') and names the alternative tools. It further gives per-platform routing rules (performer_url for most, venue_url for dice only, eventbrite organizer URL) and excludes unsupported platforms (viagogo, axs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_event_listingsGet live listings for an eventRead-onlyIdempotentInspect
Fetch live ticket listings for ONE event on ONE marketplace: section, row, quantity, price and fees. Real time, not cached. Costs 1 API credit per call. Returns the complete TicketsData API response, unchanged: always as a link to a JSON file, and also inline (whole when small, otherwise the first part of the listings in the API's order). The body structure differs per marketplace. Primary platforms (ticketmaster, dice, eventbrite, axs) return face-value offers and ticket tiers rather than resale listings. axs needs a Pro plan or above. The result also says where the listings sit and what the price fields mean for that marketplace.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Optional. gametime: 'all' (quantities 1 to 10) or 'qty=N'. ticketmaster: 'availability', 'pricing' or 'quickpicks'. Omit for other platforms. | |
| platform | Yes | Marketplace id: ticketmaster, stubhub, seatgeek, vividseats, gametime, tickpick, viagogo, dice, eventbrite, axs. | |
| event_url | Yes | Full event URL on that marketplace. ticketmaster, gametime and dice also accept a bare event ID. |
list_marketplacesList supported marketplacesARead-onlyIdempotentInspect
List the marketplaces TicketsData supports, the URL or ID format each one expects, which ones support event discovery and cross-market comparison, and valid mode values. Free: uses no credits. Call this first when unsure how to format an input.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuinely new behavioral context the annotations cannot express: the cost model ('Free: uses no credits') and the shape of the returned reference data. It does not discuss rate limits or freshness, keeping it out of the top band.
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?
One dense sentence plus a short cost note, with the highest-value information (what is returned) front-loaded and the action directive at the end. No filler and nothing repeated from the name or title.
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?
With no output schema, the description carries the burden of explaining the return payload and does so by listing the four categories of information returned. Combined with the cost note and the 'call this first' routing hint, an agent has everything needed to call and use it correctly.
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 tool takes zero parameters, so the schema has nothing to document and the baseline of 4 applies. The description correctly adds no parameter noise and instead frames the tool as a formatting reference.
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 states a specific verb and resource ('List the marketplaces TicketsData supports') and then enumerates the exact payload: URL/ID formats, event-discovery and cross-market support flags, and valid mode values. That content signature clearly separates it from siblings like compare_marketplaces, find_events, and get_event_listings, which operate on live data rather than reference metadata.
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 first when unsure how to format an input,' which tells the agent exactly when this tool should precede a data-fetching sibling. It stops short of naming when-not-to-use conditions or naming alternatives by name, so it falls just below the top band.
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
- Added
analyze_listings
4 tool updates
- First observed
compare_marketplaces - First observed
find_events - First observed
get_event_listings - First observed
list_marketplaces
Related MCP Connectors
Live event ticket market data: prices, inventory, demand and seat maps, with screens and alerts.
Find live events worldwide and link each seller's tickets. Some ticket links are affiliate links.
61Live-event ticket exchange for agents: quote, buy, make offers, bid, and sell, with escrow.
401Live festival data for AI agents: lineups, set times, dates, locations and ticket links worldwide.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceTrade and monitor prediction markets across Polymarket, Kalshi, Opinion, Limitless, and PredictFun from any AI agent. Unified real-time data, live orderbook streaming, and order execution — one API key, one interface, five exchanges.-
- AlicenseAqualityCmaintenanceSchedules, scores, odds, splits & explainable AI bet confidence — 8+ sports, free instant key.1169MIT
- AlicenseAqualityCmaintenanceEnables AI agents to fetch real-time exchange trading fees, compare rebate-adjusted costs, obtain referral links, calculate trading costs, and identify compliant exchanges for crypto trading.699 npmMIT
Try in Browser
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
Glama MCP Gateway
Add one secure layer between your agents and this server.