Enables users to search the menu by keyword or category, manage a cart with item customizations, find nearby restaurant locations, and place or track orders at Burger King.
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., "@Burger King MCP Server Add a Whopper with no onions and a medium fry to my cart"
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 MCP (Model Context Protocol) server for Burger King fast food ordering. This package enables AI assistants like Claude to search the BK menu, manage a cart, find nearby locations, and place orders via Playwright browser automation.
Search the full Burger King menu by keyword or category
Get detailed nutrition info and customization options for any item
Add items to an in-memory cart with customizations
View cart contents and estimated totals (with tax)
Find nearby Burger King locations
Checkout with delivery or pickup options
Track order status after placement
Related MCP server: DoorDash MCP Server
npm install @striderlabs/mcp-burgerkingnpm install /path/to/striderlabs-mcp-burgerking-1.0.0.tgzAfter installing, you must install Playwright's Chromium browser:
npx playwright install chromiumAdd to your claude_desktop_config.json:
{
"mcpServers": {
"burgerking": {
"command": "npx",
"args": ["-y", "@striderlabs/mcp-burgerking"]
}
}
}Or if installed globally:
{
"mcpServers": {
"burgerking": {
"command": "mcp-burgerking"
}
}
}Config file locations:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
search_menuSearch the Burger King menu by keyword or category.
Parameters:
query (optional): Search keyword (e.g., "chicken", "burger", "fries")
category (optional): One of burgers, sides, drinks, desserts, breakfast
Example:
"Search for chicken items on the BK menu"
get_item_detailsGet detailed information about a specific menu item including nutrition facts and customization options.
Parameters:
item_id (required): Item ID from search results (e.g., whopper, fries-md)
Example:
"Get details for the Whopper"
add_to_cartAdd a menu item to the cart with optional customizations.
Parameters:
item_id (required): Item ID to add
quantity (optional): Number to add (default: 1)
customizations (optional): Array of customization strings (e.g., ["no pickles", "extra cheese"])
Example:
"Add 2 Whoppers with no pickles to my cart"
view_cartView current cart contents with subtotal, estimated tax, and grand total.
Example:
"Show me my cart"
checkoutProceed to checkout. Attempts browser automation to bk.com; falls back gracefully if bot protection is encountered.
Parameters:
order_type (required): delivery or pickup
address (optional): Delivery address (required for delivery)
location_id (optional): BK location ID for pickup (from find_locations)
Example:
"Checkout for delivery to 123 Main St, San Francisco CA"
get_order_statusCheck the status of a placed order.
Parameters:
order_id (required): Order ID returned by checkout
Example:
"What's the status of order BKA1B2C3?"
find_locationsFind nearby Burger King locations.
Parameters:
address (required): Address, city, or ZIP code
radius_miles (optional): Search radius in miles (default: 5)
Example:
"Find BK locations near 10001"
User: Find me something vegetarian at Burger King
Claude: [calls search_menu with query="vegetarian"] → Returns Impossible Whopper
User: Add an Impossible Whopper with no mayo and a large Coke to my cart
Claude: [calls add_to_cart for impossible-whopper] → Added
[calls add_to_cart for coke-lg] → Added
User: Show my cart
Claude: [calls view_cart] → Shows items, subtotal $11.27, tax $0.90, total $12.17
User: Checkout for pickup at the downtown location
Claude: [calls find_locations] → Gets location IDs
[calls checkout with order_type=pickup] → Returns order IDBot Protection: bk.com uses Akamai/Cloudflare bot protection. The checkout and location tools gracefully fall back to demo/simulated responses when the site blocks automation.
In-Memory Cart: Cart state is maintained in memory for the duration of the server process. Restarting the server clears the cart.
Playwright Requirement: Playwright and Chromium must be installed for browser automation features. The server will still function with demo data if Playwright is unavailable.
Real Orders: Due to bot protection and authentication requirements, actual order placement on bk.com requires signing into a BK account. The checkout tool provides an order reference ID for completing the order manually.
git clone https://github.com/markswendsen-code/mcp-burgerking
cd mcp-burgerking
npm install
npm run buildRun in development mode:
npm run devMIT - Strider Labs
Add a menu item to the cart with optional customizations.
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes | The item ID to add to cart | |
| quantity | No | Number of items to add (default: 1) | |
| customizations | No | List of customizations (e.g., ['no pickles', 'extra cheese', 'no mayo']) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions adding an item with customizations but does not specify side effects, such as whether multiple additions accumulate, any limits, or if the cart is automatically saved. This is insufficient for a mutation tool.
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 a single sentence of 8 words with no unnecessary information. It is concise and front-loaded with the key action.
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?
For a tool with 3 parameters and no output schema, the description does not explain return behavior or any constraints. Given the sibling tools, the agent may infer context, but the description alone is incomplete.
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 only the word 'optional' for customizations, which is already clear from the schema. No additional semantic value beyond the schema.
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 action ('add'), the resource ('menu item to the cart'), and mentions optional customizations. It distinguishes from sibling tools like 'checkout' and 'view_cart', though it could be more explicit about the cart being the current user's cart.
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?
No guidance provided on when to use this tool versus alternatives, no prerequisites or conditions. The intended use is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Proceed to checkout with the current cart. Initiates the order on bk.com via browser automation.
| Name | Required | Description | Default |
|---|---|---|---|
| address | No | Delivery address (required if order_type is 'delivery') | |
| order_type | Yes | Whether to deliver or pick up the order | |
| location_id | No | BK location ID for pickup (use find_locations to get IDs) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'via browser automation', which is a behavioral trait, and implies the order will be placed. However, it does not disclose side effects (e.g., cart cleared, payment required) or prerequisites (non-empty cart). With no annotations, more detail is needed.
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, each efficient and front-loaded. No wasted words, and the core purpose is delivered immediately.
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?
While the purpose is clear, the description omits necessary context such as preconditions (non-empty cart), return value (no output schema), and error scenarios (e.g., invalid address). For a 3-parameter tool with no annotations, it is minimally adequate.
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 coverage is 100%, so the input schema already describes all parameters. The description adds no additional meaning beyond the schema, meeting the baseline expectation.
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 that the tool proceeds to checkout and initiates the order, distinguishing it from sibling tools like add_to_cart or view_cart. It uses a specific verb-resource pair and implies the final step in the purchase flow.
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?
No explicit guidance on when to use this tool (e.g., after adding items to cart) or when not to use it (e.g., if cart is empty). No alternatives are mentioned, leaving the agent to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find nearby Burger King locations by address or ZIP code. Returns location names, addresses, and hours.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Address, city, or ZIP code to search near | |
| radius_miles | No | Search radius in miles (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses return fields (names, addresses, hours) beyond schema input, but lacks details on result limits, error handling, or behavior when no locations are found.
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, front-loaded with verb and resource, every word earns its place. 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?
For a simple two-parameter tool with no output schema, the description sufficiently covers purpose and return values. Could mention default radius, but schema already provides that.
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 coverage is 100% with descriptions for both parameters. The description's mention of 'address or ZIP code' slightly overlaps with schema, adding no significant new meaning.
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 it finds nearby Burger King locations by address or ZIP code, listing returned data (names, addresses, hours). This distinguishes it from siblings like search_menu or get_item_details.
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?
No guidance on when to use this tool vs alternatives. While the purpose is clear, it lacks explicit when-to-use or when-not-to-use context, leaving the agent to infer based on tool naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific menu item including nutrition facts, price, and customization options.
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes | The item ID (e.g., 'whopper', 'fries-md') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read operation but does not disclose any behavioral traits such as authentication needs, rate limits, or whether the data is cached. Basic disclosure is present but minimal.
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 a single, clear sentence with no wasted words. It is appropriately sized and front-loaded with the key information.
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?
For a simple 1-parameter lookup tool, the description covers the purpose and expected output content. However, without an output schema, the exact return structure is not specified, leaving a minor gap.
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 coverage is 100% with one parameter that includes example values. The description adds context about what 'detailed information' includes, but does not significantly augment the schema's own description.
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 action ('Get'), the resource ('detailed information about a specific menu item'), and specifies what is included (nutrition facts, price, customization options). It distinguishes well from siblings like 'search_menu' (list) and 'get_order_status' (order-level).
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?
No guidance is provided on when to use this tool versus alternatives (e.g., 'search_menu') or prerequisites. The description lacks context for usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the status of a placed order.
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The order ID returned after checkout |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behaviors. It only states 'get', implying a read operation, but does not mention idempotency, caching, rate limits, or the format of the status response. The behavioral context is minimal.
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 7 words, no extraneous content. Front-loaded with the action and resource. Highly concise.
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 description covers the basic purpose, but given the lack of output schema, it should describe what 'status' means (e.g., possible values, structure). Parameter info is covered by schema, but the return format is missing, lowering completeness for a simple 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% with 'order_id' described as 'The order ID returned after checkout'. The tool description does not add any further parameter information, so baseline score of 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?
Description clearly states the tool retrieves the status of a placed order. The verb 'get' and resource 'order status' are specific, and the tool name distinguishes it from sibling tools like 'view_cart' (current cart) and 'checkout' (placing order).
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?
No explicit guidance on when to use this tool vs alternatives. The description implies post-checkout usage by mentioning 'placed order' and the parameter description references checkout, but the tool description itself lacks when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View the current cart contents, quantities, and total price.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It only states the basic purpose without disclosing any behavioral traits like authentication needs, side effects, or empty cart 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?
Single sentence, no fluff, directly conveys the tool's purpose.
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?
For a simple read operation with no parameters and no output schema, the description covers what the tool returns (cart contents, quantities, total price). It could mention empty cart behavior but is largely complete.
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?
There are no parameters, so the description need not add param meaning. The baseline for 0 params is 4, and the description is adequate.
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 'View' and the resource 'current cart contents, quantities, and total price'. It effectively distinguishes from siblings like add_to_cart (adds items) and checkout (completes purchase).
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?
No guidance on when to use this tool versus alternatives. While it implies viewing the cart, it lacks explicit when-not-to-use or contrast with siblings.
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.
v1.0.0add_to_cartcheckoutfind_locationsget_item_detailsget_order_statussearch_menuview_cartEach tool has a clearly distinct purpose: searching, details, cart management, checkout, locations, and order status. No overlap or ambiguity.
All tools follow a consistent verb_noun snake_case pattern (e.g., add_to_cart, get_item_details, search_menu). Even 'checkout' as a single verb is clear and fits the pattern.
With 7 tools, the server is well-scoped for a food ordering service. Each tool serves a necessary function without redundancy or bloat.
Covers the full ordering workflow: search, details, add to cart, view cart, checkout, find locations, and order status. Minor gap: no tool to remove or modify cart items, but the core flow is complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
Provides cloud browser automation capabilities using Stagehand and Browserbase, enabling LLMs to i…
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/markswendsen-code/mcp-burgerking'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
