Skip to main content
Glama
dragosh29

Line-Up MCP server

by dragosh29

Performance seating

get_performance_seating
Read-onlyIdempotent

Retrieve seating availability for a performance, including groups with capacity and remaining seats, and optionally individual available seats with price band and seat type.

Instructions

Seating availability for one performance: the seating groups (areas, sections, blocks, rows) with capacity and capacity remaining, from GET /performance/{id}/seating-group/, and optionally the individual available seats (seating objects with price band, seat type and group) from GET /performance/{id}/seating-object/. Seat lists can be large, so seats are off by default and capped by max_seats; a per-group summary is always included when seats are fetched.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codesNoValues for the API's `code` parameter (repeated). The spec types it as a list of strings and does not say what it does.
max_seatsNoMost individual seats to return (the endpoint is not paged; the rest are summarised)
package_idNoSeats priced for this package (API parameter `package_id` on seating-object; only with include_seats)
parent_idsNoOnly groups/seats under these seating groups (API parameter `parent_id`, repeated, on both endpoints)
include_rootNoInclude the top-level groups (API parameter `include_root` on seating-group; the API's default is true)
include_seatsNoAlso fetch the individual available seats
performance_idYesPerformance ID (a positive whole number)
include_contact_detailsNoInclude email addresses and phone numbers typed into seating group labels. Off by default: email addresses and phone numbers typed into any text field (names, descriptions, notes, labels, references) are replaced with [email redacted] / [phone redacted].

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover the read-only, idempotent, non-destructive profile, so the description earns credit for adding what they cannot: seat lists can be large, seats default off, results are capped by max_seats with the remainder summarised, and a per-group summary always accompanies seat fetches. It still does not discuss authentication or rate limits, but the added operational context is substantive.

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 core purpose and no filler sentences; every clause carries information. The single dense sentence is slightly run-on, which is the only structural weakness.

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 fully carries the burden of describing return values (capacity, capacity remaining, price band, seat type, group) and the default/cap behavior. Nothing an agent needs to invoke and interpret the call is missing.

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 meaning beyond the schema by explaining the interaction between include_seats and max_seats and the always-present per-group summary, clarifying why the cap exists. The ambiguous `codes` parameter is left unexplained in both places, which keeps this from a 5.

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 ('Seating availability for one performance') and enumerates the returned entities (groups, areas, sections, rows with capacity/capacity remaining). An agent can distinguish this from get_performance, which covers performance metadata rather than seat inventory.

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 explains the two underlying endpoints and the default-off seat behavior, which implies usage, but never says when to call this instead of siblings like get_performance or list_performances, nor any preconditions. Usage is inferable but not stated.

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