Skip to main content
Glama
dragosh29

Line-Up MCP server

by dragosh29
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

List performances

list_performances
Read-onlyIdempotent

Retrieve and filter dated performances by event, venue, date range, tags, or day of week to get capacity and pricing for reservations.

Instructions

Performances (dated showings) with start and end, time zone, total capacity and capacity remaining, and pricing per price band and variant (the price_id values a reservation needs). Filter by event, venue, date range, tags, days of the week. The spec says this endpoint 'bypasses Pydantic due to performance requirements', so the shape is documented but not validated by Line-Up on the way out. Uses GET /performance/.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoAPI page number to start from (1-based, as the spec documents; use next_page from a previous call)
tagsNoOnly performances with these tags (API parameter `tags`, repeated)
codesNoValues for the API's `code` parameter (repeated). The spec types it as a list of strings and does not say what it does.
event_idNoOnly performances of this event (API parameter `event_id`)
venue_idNoOnly performances at this venue (API parameter `venue_id`)
start_dateNoOnly performances starting on this date (API parameter `start_date`)
day_of_weekNoOnly these days of the week (API parameter `day_of_week`, repeated integers; the spec does not document the numbering)
max_resultsNoStop once at least this many records have been fetched. Whole API pages are returned, so up to one page more may come back; next_page says where to continue
end_date_gteNoOnly performances ending on or after this date (API parameter `end_date.gte`)
end_date_lteNoOnly performances ending on or before this date (API parameter `end_date.lte`)
start_date_gteNoOnly performances starting on or after this date (API parameter `start_date.gte`)
start_date_lteNoOnly performances starting on or before this date (API parameter `start_date.lte`)
include_contact_detailsNoInclude email addresses and phone numbers typed into performance descriptions, price band and variant names and tags. 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.1/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: the endpoint bypasses Pydantic validation so the response shape is documented but unvalidated, and it notes the redaction default for contact details. No statement about pagination semantics beyond what the schema says, but the validation caveat is real added value.

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 resource and returned fields, then filters, then the implementation caveat. Three dense sentences, each carrying information. The 'Uses GET /performance/' tail is marginally redundant but not wasteful.

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 correctly compensates by enumerating the return fields. All 13 parameters are documented in the schema. What remains thin is how pagination and max_results interact at the tool boundary, though the schema parameters cover it individually.

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 description coverage is 100%, so baseline would be 3, but the description adds meaning the schema does not: it explains that price_id values are what a reservation requires, tying the pricing output to a sibling workflow. Filter parameters are summarized rather than repeated, which is the right level.

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 names a specific verb+resource ('Performances (dated showings)'), enumerates the returned fields (start/end, time zone, capacity, pricing per price band and variant), and lists the filter axes. An agent can distinguish this list endpoint from get_performance or list_events without opening the schema.

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?

It states what can be filtered by (event, venue, date range, tags, days of week), which implies when the tool is applicable, but never gives explicit when-to-use/when-not guidance or names a preferred alternative such as get_performance for a single showing. Usage is inferred rather than directed.

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