AMC MCP Server

by hi5d

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose within the movie theater booking domain. book_seats handles seat reservations, get_now_showing lists current movies, get_recommendations suggests films, get_seat_map shows seat availability, get_showtimes fetches screening times, and process_payment handles transactions. There is no overlap or ambiguity between these functions.
Naming Consistency5/5
All six tools follow a consistent verb_noun naming pattern with snake_case. The verbs are appropriate and descriptive: 'book', 'get' (used four times consistently), and 'process'. This uniformity makes the tool set predictable and easy to understand.
Tool Count5/5
With 6 tools, this server is well-scoped for its movie theater booking purpose. It covers the essential workflow from discovery (get_now_showing, get_recommendations) to booking (get_showtimes, get_seat_map, book_seats) to payment (process_payment). Each tool earns its place without being excessive or insufficient.
Completeness4/5
The tool set covers the core movie booking workflow comprehensively, from discovery to payment. However, there are minor gaps: no tools for canceling bookings, updating reservations, or managing user profiles. These are not critical failures but represent areas where agents might need workarounds.
Average 3.4/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Reserves' implies a write/mutation operation, it doesn't specify permissions required, whether reservations are reversible, rate limits, or what happens on failure (e.g., seat conflicts). The return format is mentioned but lacks detail on error cases or confirmation structure.
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 appropriately sized and well-structured with clear sections (purpose, Args, Returns). The purpose statement is front-loaded, and each sentence adds value. Minor verbosity in repeating 'JSON string' could be trimmed, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage, no annotations, and an output schema exists (though unspecified), the description provides basic purpose and parameter examples but lacks critical context. It doesn't cover error handling, dependencies on other tools, or behavioral traits needed for safe invocation. The output schema existence reduces burden, but gaps remain for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds basic semantics by naming parameters and giving examples (e.g., 'st001', ['A5', 'A6']), which helps understand what each parameter represents. However, it doesn't explain format constraints (e.g., seat numbering scheme) or validation rules, leaving gaps.
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 the tool's purpose with a specific verb ('Reserves') and resource ('selected seats'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'process_payment' which might handle payment aspects of booking, leaving some ambiguity about the scope of this reservation operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing seat availability from 'get_seat_map' first), nor does it clarify if this is the final booking step or if 'process_payment' should follow. There's no explicit when/when-not guidance or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns a list, but doesn't describe traits like error handling, rate limits, authentication needs, or whether it's a read-only operation. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 appropriately sized and front-loaded, with the core purpose stated first, followed by structured sections for Args and Returns. Each sentence earns its place, though the 'Returns' section could be slightly more detailed given the lack of output schema description in this context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) and the presence of an output schema, the description is minimally adequate. However, with no annotations and incomplete behavioral details, it doesn't fully compensate for the structured data gaps. The output schema existence reduces the need to explain return values, but more context on usage and behavior would improve completeness.
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?
The description adds meaningful context for the single parameter 'location', specifying it as 'City, state or ZIP code (e.g., "Boston, MA")'. Since schema description coverage is 0% and there's only one parameter, this compensates well, providing clear examples and format guidance beyond the basic schema type.
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 the tool's purpose: 'Returns a list of movies currently showing in a given city or ZIP code.' This specifies the verb ('returns'), resource ('list of movies'), and scope ('currently showing in a given city or ZIP code'). However, it doesn't explicitly differentiate from sibling tools like 'get_showtimes' or 'get_recommendations', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_showtimes' or 'get_recommendations', nor does it specify prerequisites, exclusions, or contextual cues for usage. The agent must infer usage based on the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool 'suggests movies' and returns 'JSON string with movie recommendations', which implies a read-only operation. However, it lacks details on behavioral traits like rate limits, error handling, or whether the suggestions are personalized or generic. The description doesn't contradict annotations (none provided).
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 appropriately sized and front-loaded: the first sentence states the purpose, followed by a structured 'Args' and 'Returns' section. Every sentence adds value, with no redundant information. It could be slightly more concise by integrating the parameter explanations into the opening sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 optional parameters) and the presence of an output schema (which covers return values), the description is somewhat complete. It explains the tool's purpose and parameters but lacks usage guidelines and behavioral context. With no annotations, it should do more to compensate, such as mentioning if it's a read-only operation or any limitations.
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 0%, so the description must compensate. It adds meaning by explaining each parameter's purpose with examples (e.g., 'genre: Movie genre (optional, e.g., "action", "comedy")'). This clarifies semantics beyond the schema's basic type definitions. However, it doesn't cover constraints like valid values or interactions between parameters.
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 the tool's purpose: 'Suggests movies based on mood, genre, or time preferences.' This specifies the verb ('suggests'), resource ('movies'), and filtering criteria. However, it doesn't explicitly differentiate from sibling tools like 'get_now_showing' or 'get_showtimes', which might also return movie information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_now_showing' or 'get_showtimes', which could be relevant for movie-related queries. There's no context about prerequisites, such as whether user authentication is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a 'simulated' transaction, which is useful context about it being non-production. However, it doesn't disclose critical behavioral traits like whether this is idempotent, what happens on failure, authentication requirements, or rate limits for a payment operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by organized Arg and Return sections. Every sentence earns its place by providing essential information without redundancy. The formatting with clear section headers enhances readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (payment transaction with 3 parameters), no annotations, but with an output schema (implied by Returns section), the description is moderately complete. It covers parameters well and mentions returns, but lacks behavioral context about simulation details, error handling, or integration with the booking system that would be helpful for an agent.
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?
With 0% schema description coverage, the description must fully compensate. It provides clear semantic meaning for all 3 parameters: booking_id links to another tool, payment_method gives examples, and amount specifies currency. This adds substantial value beyond the bare schema, though it doesn't specify format constraints like amount precision or payment_method validation.
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 the tool 'handles simulated payment transaction', which is a specific verb+resource combination. It distinguishes itself from sibling tools like book_seats and get_showtimes by focusing on payment processing rather than booking or information retrieval. However, it doesn't explicitly contrast with potential payment alternatives (none exist in the sibling list).
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 implies usage context through the 'booking_id' parameter reference to 'book_seats', suggesting this should be used after booking. However, it doesn't provide explicit when-to-use guidance, alternatives, or exclusions. No mention of prerequisites like booking confirmation or payment method availability is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the return format ('JSON string with seat availability map'), which is helpful, but lacks critical behavioral details such as whether this is a read-only operation, potential rate limits, authentication requirements, or error conditions. The description doesn't contradict annotations (none exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by structured 'Args' and 'Returns' sections. Every sentence earns its place with no wasted words.
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?
Given the tool's moderate complexity (single parameter, read-focused operation), the description is reasonably complete. It covers purpose, parameter, and return format. However, with no annotations and an output schema present (though not detailed here), it could benefit from more behavioral context like error handling or data freshness.
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 0%, so the description must compensate. It provides the parameter name ('showtime_id') and an example value ('st001'), adding meaning beyond the bare schema. However, it doesn't explain format constraints or validation rules beyond the example.
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 clearly states the tool's purpose with specific verbs ('displays') and resources ('available and reserved seats for a specific showtime'). It distinguishes from siblings like 'get_showtimes' (which lists showtimes) and 'book_seats' (which reserves seats).
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 implies usage when seat availability is needed for a showtime, but provides no explicit guidance on when to use this tool versus alternatives like 'get_showtimes' (for showtime listings) or 'book_seats' (for seat booking). 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'fetches' data without disclosing behavioral traits like authentication requirements, rate limits, error handling, or whether this is a read-only operation. It mentions the return format but lacks operational context.
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 appropriately sized and front-loaded with the core purpose in the first sentence. The Args/Returns sections are structured but slightly verbose; every sentence earns its place by clarifying parameters and output.
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?
Given the tool's moderate complexity (3 required parameters) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers purpose and parameters well but lacks behavioral context that would be needed without annotations.
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%, so the description must compensate fully. It successfully adds meaning beyond the bare schema by explaining each parameter's purpose (movie ID, date format, location type) with concrete examples, making the semantics clear despite no schema descriptions.
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 clearly states the tool's purpose with specific verb ('fetches') and resource ('available showtimes'), and distinguishes it from siblings by focusing on movie/location/date filtering rather than booking, recommendations, or payments.
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 implies usage context (when you need showtimes for a specific movie, date, and location) but doesn't explicitly state when to use this versus alternatives like get_now_showing (which likely shows currently playing movies without filtering) or provide exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![amc-mcp MCP server](https://glama.ai/mcp/servers/hi5d/amc-mcp/badges/card.svg)](https://glama.ai/mcp/servers/hi5d/amc-mcp)

Score Badge

Copy to your README.md:

[![amc-mcp MCP server](https://glama.ai/mcp/servers/hi5d/amc-mcp/badges/score.svg)](https://glama.ai/mcp/servers/hi5d/amc-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hi5d/amc-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server