Provides read-only access to Fandango movie showtimes, theater calendars, and seat availability, including seat map rendering and multi-day availability scanning.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Fandango MCP find showtimes for Twisters this Friday"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Unofficial, read-only MCP server for Fandango showtimes and seat availability, reverse-engineered from observed web traffic.
Built entirely by GPT-5.5 via Codex CLI.
Exposes anonymous, read-only Fandango movie discovery, theater calendars, showtimes, and seat maps through MCP. It can find showtimes and inspect available seats, but it cannot buy, hold, reserve, validate, favorite, or check out tickets.
fandango_movie_showtimes - search one movie across nearby theaters for a date
fandango_theater_showtimes - list one theater's movie showtimes for a date
fandango_theater_calendar - read a theater's available showtime dates
fandango_seat_availability - read raw seat availability for a showtime
fandango_scan_movie_availability - scan movie availability across multiple days, optionally with seat maps and best open groups
fandango_render_seat_map - render a terminal seat map with open/taken seats and contiguous open groups
Typical workflow: fandango_movie_showtimes or fandango_theater_showtimes returns a showtimeHashCode, then fandango_render_seat_map or fandango_seat_availability inspects seats. For multi-day "good seats" searches, use fandango_scan_movie_availability with includeSeatDetails; it returns all showtimes, capped seat-map details, and bestAvailability.
Seat map symbols: □ open, ☒ taken, ▣ open wheelchair, ▦ taken wheelchair.
Find read-only Fandango showtimes for one movie across nearby theaters on one date. Requires either zip or lat/long; lat/long is preferred when both are present.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Search latitude. | |
| zip | No | Search ZIP code. | |
| date | Yes | Show date in YYYY-MM-DD. | |
| long | No | Search longitude. | |
| page | No | Optional Fandango result page. | |
| format | No | Optional format filter, e.g. IMAX 70MM. | |
| movieId | Yes | Fandango movie id, for example 241283. | |
| chainCode | No | Optional theater chain code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'read-only', which matches the readOnlyHint annotation, but does not add significant behavioral context beyond that. The annotation already covers safety, so the description adds only the scope constraint (one movie/date) and location preference. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. Every word serves a purpose: verb, resource, scope, constraints, and a preference. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, the description covers core functionality but omits details about pagination (the page parameter exists but is not explained), return format, or error conditions. It is minimally adequate but leaves gaps for a complex search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 8 parameters. The description adds value by explaining the location requirement and preference (zip vs lat/long), but does not enhance understanding of other parameters like page, format, or chainCode. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find', the resource 'read-only Fandango showtimes', and scopes it to 'one movie across nearby theaters on one date'. This distinguishes it from sibling tools like fandango_theater_showtimes which focus on a specific theater.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions requirements ('Requires either zip or lat/long') and a preference ('lat/long is preferred when both are present'), but does not provide guidance on when to use this tool versus alternatives (e.g., fandango_theater_showtimes or fandango_scan_movie_availability). No when-not conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read and render a Fandango seat map as terminal-friendly Unicode boxes. Uses □ for open seats and ☒ for taken seats.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | Terminal render style. Default: spaced. | |
| referer | No | Optional browser page referer from captured traffic. | |
| maxOpenGroups | No | Maximum open-seat groups to list. | |
| showtimeHashCode | Yes | Fandango showtimeHashCode from a showtime result. | |
| includeOpenGroups | No | Include best contiguous open-seat groups. Default: true. | |
| includeColumnLabels | No | Include a column-number ruler above the map. Default: true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint and openWorldHint. The description adds value by detailing the output (Unicode boxes, symbols for open/taken seats) and mentions the rendering style, going beyond structural metadata without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that front-load the core purpose and then provide specific output details. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description sufficiently explains the return format (Unicode boxes with specific symbols). It covers key behaviors like open-seat groups and column labels, making it complete for a render tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The tool description does not add individual parameter guidance but gives overall output context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Read and render a Fandango seat map as terminal-friendly Unicode boxes.' It specifies the output format and symbols used, distinguishing it from sibling tools that handle showtimes or availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly guide when to use this tool versus alternatives, such as requiring a showtimeHashCode from a prior search. The usage context is implied by the required parameter and sibling names but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan one movie across a date range and nearby theaters. Optionally attaches seat counts for available showtimes. This is read-only and capped at 31 days.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Search latitude. | |
| zip | No | Search ZIP code. | |
| days | Yes | Number of dates to scan, capped at 31. | |
| long | No | Search longitude. | |
| format | No | Optional format filter, e.g. IMAX 70MM. | |
| movieId | Yes | Fandango movie id, for example 241283. | |
| startDate | Yes | First show date in YYYY-MM-DD. | |
| includeSeatCounts | No | When true, fetch seat-map counts for available showtimes with showtimeHashCode. | |
| maxSeatMapFetches | No | Maximum seat-map requests when includeSeatCounts/includeSeatDetails is true. Default: 100. | |
| includeSeatDetails | No | When true, fetch and include full normalized seat maps plus best open-seat groups. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds the 31-day cap and optional seat count behavior beyond structured data. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with front-loaded purpose and no unnecessary words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters and no output schema, the description does not explain what the tool returns (e.g., list of showtimes, theaters) and is too minimal given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal additional meaning beyond stating optional seat counts, which is already implied by the corresponding parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (scan), the resources (movie, date range, nearby theaters), and optional behavior (seat counts). It distinguishes from siblings like fandango_movie_showtimes by emphasizing a broad scan across dates and locations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for scanning availability across date range and theaters but does not explicitly state when to use this tool over siblings or provide exclusions. Context is clear but no alternative guidance is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the Fandango seat map for one showtimeHashCode and return normalized open/taken seat counts and coordinates. This never enters ticketing or checkout.
| Name | Required | Description | Default |
|---|---|---|---|
| referer | No | Optional browser page referer from captured traffic. | |
| showtimeHashCode | Yes | Fandango showtimeHashCode from a showtime result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reinforces the readOnlyHint and openWorldHint annotations by confirming no ticketing or checkout involvement, adding context that the tool is a safe, non-destructive read operation. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no unnecessary words. The first sentence states the core action and result, the second clarifies safety. Perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only one required parameter. The description states what it returns (seat counts and coordinates), compensating for the lack of an output schema. Combined with annotations, it feels sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented. The description adds minor context by noting the referer is 'from captured traffic' and that showtimeHashCode comes 'from a showtime result', but these are not critical for understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read', the resource 'Fandango seat map', and the input 'showtimeHashCode', and specifies the output 'normalized open/taken seat counts and coordinates'. It distinguishes itself from siblings like 'fandango_render_seat_map' by focusing on data retrieval rather than rendering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking seat availability without side effects ('never enters ticketing or checkout'), but does not explicitly state when to use versus alternatives like 'fandango_render_seat_map' or when not to use. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Fandango's showtime calendar for one theater, including which dates currently have showtimes.
| Name | Required | Description | Default |
|---|---|---|---|
| startDate | No | Optional start date in YYYY-MM-DD. | |
| theaterId | Yes | Fandango theater id, for example AANEM. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark as read-only and open-world. Description adds that tool returns dates with showtimes, giving specific behavioral insight beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no extraneous words. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description adequately explains output (dates with showtimes). With openWorldHint, volatility is acknowledged. Lacks only details like pagination or format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. Description doesn't repeat parameter details but adds context that theaterId identifies a single theater and startDate is optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Read', resource 'showtime calendar for one theater', and output 'which dates currently have showtimes'. It distinguishes from siblings like fandango_theater_showtimes and fandango_movie_showtimes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description indicates use case: reading calendar for one theater to see dates with showtimes. It doesn't explicitly exclude other uses, but sibling names provide context for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find read-only Fandango showtimes for one theater on one date. Optionally filter to a movie id and format.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Show date in YYYY-MM-DD. | |
| format | No | Optional format filter, e.g. IMAX 70MM. | |
| movieId | No | Optional Fandango movie id filter. | |
| chainCode | No | Optional chain code, for example AMC. | |
| theaterId | Yes | Fandango theater id, for example AANEM. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. Description confirms 'read-only' but adds no further behavioral context (e.g., data currency, rate limits, or side effects). With annotations, bar is lower, but no extra value beyond restating.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with front-loaded purpose and optional filters. Every word earns its place; no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 5 params, the description adequately covers scope and optionality. Could optionally mention return format (showtimes list) but not required. Sufficient for agent decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all 5 parameters. The tool description does not add additional meaning beyond the schema's parameter descriptions. Baseline 3 applies per rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Find read-only Fandango showtimes for one theater on one date' with optional filters. This distinguishes from siblings like fandango_movie_showtimes which operates on movies, and fandango_theater_calendar which gives a broader view. Verb and resource are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for specific theater and date showtimes, but does not explicitly state when to use this vs siblings or provide when-not-to-use guidance. No alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0fandango_movie_showtimesfandango_render_seat_mapfandango_scan_movie_availabilityfandango_seat_availabilityfandango_theater_calendarfandango_theater_showtimesTools have distinct purposes: movie showtimes, theater showtimes, seat mapping, theater calendar, and availability scanning. The only potential confusion is between fandango_movie_showtimes and fandango_theater_showtimes, but the descriptions clarify the different foci. Overall, agents should reliably select the correct tool.
All tools start with 'fandango_', but naming mixes noun_noun (movie_showtimes, seat_availability) and verb_noun (render_seat_map, scan_movie_availability) patterns. This inconsistency could cause slight confusion, though the verbs are informative.
With 6 tools, the set is well-scoped for a read-only movie ticketing service. Each tool covers a distinct aspect (showtimes by movie or theater, seat maps, availability scanning, theater calendar), and there are no redundant tools.
The tools provide comprehensive read-only access to showtimes, seat maps, and theater calendars. Missing features like movie metadata (synopsis, ratings) are understandable given the focus on ticketing; minor gaps exist but do not hinder core workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only MCP server for HolyDB: find Catholic parish Mass times by location and time.
Unofficial read-only MCP server for VeryChic hotel offers
The official Planning Center MCP server for interacting with your ministry's data.
MCP server for the FFmpeg Micro video transcoding API — create, monitor, download transcodes.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/atfinke/fandango-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
