Click on "Deploy 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., "@AMC MCP Server find showtimes for Dune: Part Two in Boston tonight"
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.
An Model Context Protocol (MCP) server that provides a comprehensive movie booking experience for AMC Theatres. This server enables conversational AI assistants to help users discover movies, find showtimes, book seats, and process payments through a simple API interface.
Movie Discovery: Browse currently showing movies and get personalized recommendations
Showtime Lookup: Find available showtimes by location, date, and movie
Seat Selection: View interactive seat maps and check availability
Booking Management: Reserve seats with real-time availability checking
Payment Processing: Handle mock payment transactions with confirmation receipts
Multi-location Support: Search across multiple AMC theater locations
Related MCP server: AMC MCP Server
Python 3.8+
Docker (optional, for containerized deployment)
Clone the repository:
git clone <repository-url>
cd amc-mcpInstall dependencies:
pip install -r requirements.txtInstall the package:
pip install -e .Run the server:
python -m amc_mcp.fastmcp_serverBuild and run with Docker Compose:
docker-compose up --buildOr build and run manually:
docker build -t amc-mcp .
docker run -it amc-mcpReturns a list of movies currently showing in a given location.
Input:
{
"location": "Boston, MA"
}Output:
{
"location": "Boston, MA",
"movies": [
{
"movie_id": "mv001",
"title": "Dune: Part Two",
"rating": "PG-13",
"duration": 166,
"genre": "Sci-Fi/Action",
"description": "Paul Atreides unites with Chani..."
}
]
}Suggests movies based on mood, genre, or preferences.
Input:
{
"genre": "action",
"mood": "exciting"
}Output:
{
"criteria": {"genre": "action", "mood": "exciting"},
"recommendations": [...]
}Fetches available showtimes for a specific movie and location.
Input:
{
"movie_id": "mv001",
"date": "2025-10-28",
"location": "Boston, MA"
}Output:
{
"movie": {"id": "mv001", "title": "Dune: Part Two"},
"date": "2025-10-28",
"location": "Boston, MA",
"showtimes": [
{
"showtime_id": "st001",
"theater_name": "AMC Boston Common 19",
"theater_address": "175 Tremont Street",
"time": "14:00",
"format": "IMAX",
"price": 18.50
}
]
}Displays available and reserved seats for a specific showtime.
Input:
{
"showtime_id": "st001"
}Output:
{
"showtime_id": "st001",
"movie": "Dune: Part Two",
"theater": "AMC Boston Common 19",
"date": "2025-10-28",
"time": "14:00",
"seat_map": [
{
"seat_number": "A5",
"row": "A",
"column": 5,
"is_available": true,
"price_tier": "Standard",
"price": 18.50
}
]
}Reserves selected seats for the user.
Input:
{
"showtime_id": "st001",
"seats": ["A5", "A6"],
"user_id": "user123"
}Output:
{
"booking_id": "booking-uuid",
"status": "pending",
"movie": "Dune: Part Two",
"theater": "AMC Boston Common 19",
"date": "2025-10-28",
"time": "14:00",
"seats": ["A5", "A6"],
"total_price": 37.00
}Handles simulated payment transaction.
Input:
{
"booking_id": "booking-uuid",
"payment_method": "card",
"amount": 37.00
}Output:
{
"payment_id": "payment-uuid",
"payment_status": "success",
"booking_id": "booking-uuid",
"receipt_url": "https://amc.com/receipts/payment-uuid",
"confirmation": {
"movie": "Dune: Part Two",
"theater": "AMC Boston Common 19",
"date": "2025-10-28",
"time": "14:00",
"seats": ["A5", "A6"],
"total_paid": 37.00
}
}Here's how a typical movie booking conversation would work:
User: "Find an action movie near me tonight."
Server calls: get_now_showing + get_recommendations
Returns: List of action movies with showtimes
User: "Book two seats for Dune: Part Two at 8 PM."
Server calls: get_showtimes ā get_seat_map ā book_seats
Returns: Seat selection and booking confirmation
User: "Pay with my card."
Server calls: process_payment
Returns: Payment confirmation with digital receipt
amc-mcp/
āāā src/
ā āāā amc_mcp/
ā āāā __init__.py
ā āāā server.py # Main MCP server implementation
āāā data/
ā āāā movies.json # Movie catalog
ā āāā theaters.json # Theater locations
ā āāā showtimes.json # Showtime schedules
ā āāā seats.json # Seat maps by showtime
āāā config/
ā āāā nginx.conf # Web server configuration
āāā Dockerfile # Container configuration
āāā docker-compose.yml # Multi-service orchestration
āāā requirements.txt # Python dependencies
āāā pyproject.toml # Package configuration
āāā README.md # This file{
"movie_id": str,
"title": str,
"rating": str, # PG, PG-13, R, etc.
"duration": int, # Minutes
"genre": str,
"description": str,
"poster_url": str
}{
"theater_id": str,
"name": str,
"address": str,
"city": str,
"state": str,
"zip_code": str
}{
"showtime_id": str,
"movie_id": str,
"theater_id": str,
"date": str, # YYYY-MM-DD
"time": str, # HH:MM
"format": str, # Standard, IMAX, 3D, Dolby
"price": float
}Edit data/movies.json to add new movies:
{
"movie_id": "mv011",
"title": "New Movie Title",
"rating": "PG-13",
"duration": 120,
"genre": "Action",
"description": "Description of the movie...",
"poster_url": "https://example.com/poster.jpg"
}Edit data/theaters.json:
{
"theater_id": "th011",
"name": "AMC New Location 15",
"address": "123 Main Street",
"city": "New City",
"state": "NY",
"zip_code": "12345"
}Edit data/showtimes.json and data/seats.json to add new showtimes and corresponding seat maps.
You can test individual tools using the MCP inspector or by connecting to any MCP-compatible client.
Configure Claude Desktop to connect to your MCP server
Use natural language to test the booking flow
Example: "Find me a sci-fi movie showing tonight in Boston"
PYTHONPATH: Set to /app/src for proper module resolution
PYTHONUNBUFFERED: Set to 1 for real-time logging
MCP_LOG_LEVEL: Set logging level (DEBUG, INFO, WARNING, ERROR)
The server runs in a lightweight Python 3.11 container with:
Non-root user for security
Health checks for monitoring
Volume mounts for data persistence
Network isolation
This is a mock implementation for demonstration purposes. In production:
Payment Processing: Integrate with real payment gateways (Stripe, PayPal)
Authentication: Add user authentication and authorization
Data Validation: Implement comprehensive input validation
Rate Limiting: Add API rate limiting
Encryption: Use HTTPS and encrypt sensitive data
Database: Replace JSON files with a real database
Logging: Implement structured logging and monitoring
Real AMC API Integration: Connect to actual AMC Theatres API
User Accounts: Persistent user profiles and booking history
Group Bookings: Support for multiple users booking together
Loyalty Programs: AMC Stubs integration
Mobile Tickets: Generate QR codes for mobile entry
Seat Recommendations: AI-powered optimal seat suggestions
Price Alerts: Notify users of discounts and promotions
Social Features: Share movie plans with friends
Accessibility: ADA-compliant seat selection
Multi-language: International language support
Fork the repository
Create a feature branch: git checkout -b feature/new-feature
Make your changes and add tests
Commit your changes: git commit -am 'Add new feature'
Push to the branch: git push origin feature/new-feature
Submit a pull request
This project is licensed under the MIT License - see the LICENSE file for details.
For questions, issues, or feature requests:
Create an issue in the GitHub repository
Check the documentation for common solutions
Review the example conversation flows
Happy movie booking! šæš¬
Reserves selected seats for the user.
Args: showtime_id: Showtime ID (e.g., "st001") seats: List of seat numbers (e.g., ["A5", "A6"]) user_id: User identifier
Returns: JSON string with booking confirmation
| Name | Required | Description | Default |
|---|---|---|---|
| showtime_id | Yes | ||
| seats | Yes | ||
| user_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Returns a list of movies currently showing in a given city or ZIP code.
Args: location: City, state or ZIP code (e.g., "Boston, MA")
Returns: JSON string with list of movies
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Suggests movies based on mood, genre, or time preferences.
Args: genre: Movie genre (optional, e.g., "action", "comedy") mood: Mood description (optional, e.g., "exciting", "romantic") time_preference: Time of day preference (optional, e.g., "evening")
Returns: JSON string with movie recommendations
| Name | Required | Description | Default |
|---|---|---|---|
| genre | No | ||
| mood | No | ||
| time_preference | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Displays available and reserved seats for a specific showtime.
Args: showtime_id: Showtime ID (e.g., "st001")
Returns: JSON string with seat availability map
| Name | Required | Description | Default |
|---|---|---|---|
| showtime_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Fetches available showtimes for a specific movie and location.
Args: movie_id: Movie ID (e.g., "mv001") date: Date in YYYY-MM-DD format (e.g., "2025-10-28") location: City, state or ZIP code
Returns: JSON string with available showtimes
| Name | Required | Description | Default |
|---|---|---|---|
| movie_id | Yes | ||
| date | Yes | ||
| location | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Handles simulated payment transaction.
Args: booking_id: Booking ID from book_seats payment_method: Payment method (e.g., "card", "cash") amount: Payment amount in USD
Returns: JSON string with payment confirmation and receipt
| Name | Required | Description | Default |
|---|---|---|---|
| booking_id | Yes | ||
| payment_method | Yes | ||
| amount | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
book_seatsget_now_showingget_recommendationsget_seat_mapget_showtimesprocess_paymentScored across 6 tools
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.
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.
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.
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.
Booking gateway for AI agents ā discover events, movies & hotels, hand off to partner checkout.
AI ticket commerce for theme parks, zoos, museums, and aquariums via any AI agent
Discover and book businesses via AI agents.
Discover local services and availability, then create, track, reschedule, or cancel bookings.
