Skip to main content
Glama

UPFRONT

by tickets.upfront
OverviewDiscussionsAdmin

Compare all-in prices

compare_prices
Read-onlyIdempotent

One event's all-in prices on every site in one answer: UPFRONT's own listings and the other marketplaces (StubHub, SeatGeek, Vivid Seats, TickPick, Gametime, AXS, Ticketmaster), cheapest first. Matches requests like "cheapest 2 seats together for Saturday's game under $500 total" or "who has it cheaper?". event_id is UPFRONT's event id (eventId in event results).

quantity: how many tickets are needed together. Only listings that sell exactly that many as one group count, and totalAllInPrice is the whole group's price. max_price: the most per ticket, fees included, in dollars. max_total_price: the budget for the whole group, as the user stated it (needs quantity); UPFRONT works out the per-ticket limit. section: a section name or number ("112", "Floor"): only that section. limit: how many picks to return (default 5, at most 10).

Returns:

  • event: name, venue, city, startsAt and url (the event's page).

  • sites: one per site, cheapest first: site ("UPFRONT" for ours), checked, checkedAt, listings (how many match there) and lowestAllInPrice. checked "ok" means the site was read; "incomplete" means only some listings came back; "failed" means it couldn't be read, which is not the same as having nothing. A site missing from sites wasn't matched to this event, which is not the same as sold out there.

  • listings: the cheapest matching picks across every site: site, section, row, allInPrice (per ticket, that site's own price with its fees), totalAllInPrice (with quantity), quantities, notes and url, the link to buy exactly that listing on that site. feesIncluded false (rare) means that site gave no fees-in price.

  • moreListings: how many matched but weren't returned.

Other sites' prices are as of checkedAt and may have changed since. otherSites says where they came from: "saved" is UPFRONT's last check of each site, which can be hours or a few days old; "none" means no recent check, and event.url compares every site live. All prices are all-in totals. unavailable means other sites' prices aren't offered in this assistant right now; UPFRONT's own listings still stand. notShown lists sites whose prices aren't offered here, which is not the same as not found or sold out. error "search_failed" (on a site or the answer) means that lookup failed, not that nothing is on sale; "event_not_found" means no event has that id.

Input Schema

NameRequiredDescriptionDefault
limitNo
sectionNo
event_idYes
quantityNo
max_priceNo
max_total_priceNo

Output Schema

NameRequiredDescriptionDefault
errorNo
eventNo
sitesYes
listingsYes
notShownNo
quantityNo
otherSitesNo
unavailableNo
moreListingsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

The description goes well beyond the readOnly/idempotent annotations by explaining site statuses (ok/incomplete/failed), otherSites freshness, unavailable/notShown distinctions, and error meanings such as search_failed and event_not_found. This is exactly the behavioral context an agent needs to interpret results correctly.

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?

The description is well structured and front-loads the core purpose before parameters and return details. It is somewhat long, especially the return-value section, but the density of useful semantics justifies most of the length.

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?

For a six-parameter, multi-site price comparison tool with no schema descriptions, the description is exceptionally complete. It covers parameter meaning, return shape, freshness caveats, and error/status semantics.

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?

Despite 0% schema description coverage, the description explains every parameter: event_id, quantity, max_price, max_total_price, section, and limit. It adds crucial semantics, especially the distinction between per-ticket max_price and group-level max_total_price.

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 that this tool returns one event's all-in prices across UPFRONT and other marketplaces, cheapest first. It is specific about the resource and operation, though it does not explicitly distinguish itself from sibling tools such as best_seats or find_ticket_groups.

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 provides concrete example requests ('cheapest 2 seats together...', 'who has it cheaper?') that clearly indicate when to use the tool. It stops short of naming alternatives or stating when not to use it, but the context is strong.

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

All UPFRONT toolsInspect
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.

Resources