Skip to main content
Glama

Best seats by view

best_seats
Read-onlyIdempotent

UPFRONT's own listings for one event ranked by where the seats are, not only by price: "best view for 2 under $250", "closest seats to the court for $400 total", "seats in the shade", "not too high up". event_id is UPFRONT's event id (eventId in event results).

prefer: "closest" (nearest the field, court or stage; the default), "lowest" (lowest eye height), "covered" (a roof or deck overhead first, for shade or rain) or "value" (the best mix of closeness and price). quantity: the number of tickets needed together. max_price: per ticket, fees included. max_total_price: the whole group's budget, with quantity. limit: how many picks (default 5, at most 10).

Each pick has the section, row, all-in price (and total for the quantity), the row's distance and height, whether it's covered, the section's view picture (UPFRONT's 3D view, not a photo), its section page, why it was picked, and url, the link to buy exactly that listing.

placed says how many of the matching listings could be put on the seating chart; only those are ranked. hasFacts false means UPFRONT has no seat facts for this venue, so the picks are simply the cheapest and the ranking is by price only. {"error": "search_failed"} means the listings lookup failed, not that nothing is on sale.

Input Schema

NameRequiredDescriptionDefault
limitNo
preferNoclosest
event_idYes
quantityNo
max_priceNo
max_total_priceNo

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?

Beyond the readOnly/idempotent/openWorld annotations, the description discloses real behavioral edge cases: 'placed' limits which listings are ranked, hasFacts=false degrades ranking to price-only, and {"error": "search_failed"} is a lookup failure, not an empty inventory. Those are exactly the surprises an agent needs warned about.

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-loaded with the differentiator ('ranked by where the seats are, not only by price') followed by parameter and return-value blocks; almost every sentence earns its place. It is dense and long, with some run-on enumeration in the return-value paragraph, but nothing is padding.

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?

There is no output schema, and the description compensates by enumerating the returned fields (section, row, all-in price, distance, height, covered, 3D view picture, section page, reason, buy url) and by explaining degraded and error states. An agent can call and interpret results without further documentation.

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 description coverage is 0% and the schema only gives bare titles, so the description carries the full burden — and it does: prefer is defined with all four accepted values plus the default, quantity is 'tickets needed together', max_price is per-ticket with fees, max_total_price is group budget, limit is 5 default / 10 max, and event_id is tied to eventId from event results.

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 states a specific verb and resource: it ranks UPFRONT's own listings for one event by seat location rather than price alone, illustrated with concrete query examples. It implicitly separates itself from compare_prices ('not only by price', 'UPFRONT's own listings') but never names that sibling, so an agent must infer the boundary.

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 opening examples ('best view for 2 under $250', 'seats in the shade') make the intended use case concrete, and the prefer values clarify which framing to choose. It stops short of explicit alternatives or exclusion rules (e.g., when to call compare_prices or find_ticket_groups instead).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources