Provides tools for searching restaurants and food, browsing store menus with pricing and promotions, managing shopping carts, and viewing order history on DoorDash.
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., "@DoorDash MCP Server find sushi nearby and add a spicy tuna roll 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 that lets AI agents search restaurants, browse menus, compare prices, and manage your DoorDash cart — all without opening a browser or wasting tokens on HTML parsing.
Instead of using a browser-based AI agent (which eats context and tokens parsing HTML), this MCP server runs a lightweight background browser that handles authentication and API calls. Your AI agent gets clean JSON — no HTML, no screenshots, no wasted tokens.
Under the hood, it uses DoorDash's internal GraphQL API (reverse-engineered from web traffic) via a Playwright browser instance that maintains your session.
Related MCP server: doordash-mcp
Tool | Description |
| Check if your DoorDash session is active |
| Search restaurants and food by keyword |
| Get full menu with prices, deals, and badges |
| Add items to your cart |
| Remove items from cart |
| View all active carts |
| Get recent order history |
Deals and promotions (Buy 1 Get 1 Free, DashPass offers, etc.) are surfaced in both search results and menu items.
git clone <this-repo>
cd doordash-mcp
npm install
npx playwright install chromiumcp .env.example .envEdit .env and set your DoorDash account email:
DOORDASH_EMAIL=your-email@example.comnode login.jsThis opens a browser, sends an OTP to your email/phone, and saves the session. You only need to do this once (or when your session expires).
On headless Linux: The script auto-starts a virtual display via Xvfb. Make sure xvfb is installed (sudo apt install xvfb).
Add to ~/.claude/settings.json:
{
"mcpServers": {
"doordash": {
"command": "node",
"args": ["/absolute/path/to/doordash-mcp/mcp-server.js"]
}
}
}Restart Claude Code to pick up the new server.
Once configured, just talk to your AI agent naturally:
"Search for biryani near me"
"Show me the Pizza Hut menu"
"What's the cheapest dosa at Thanjai Restaurant?"
"Add 2 Masala Dosas to my cart"
"What did I order last time?"
"Find me a burger place with deals"
Want to discover new endpoints or debug? The spy.js script opens a browser and logs all DoorDash API traffic as you browse:
node spy.jsBrowse DoorDash normally — search, view menus, add to cart. All API calls get logged to logs/api-calls.jsonl. Close the browser when done.
AI Agent ──(MCP stdio)──> mcp-server.js ──(GraphQL via Playwright)──> DoorDash API
│
browser-data/ (persistent session cookies)No headless HTTP: Cloudflare blocks plain HTTP requests. The server uses a real browser (positioned off-screen on macOS, or via Xvfb on Linux)
Persistent session: Login once, the browser profile in browser-data/ keeps your cookies alive
Minimal tokens: AI agents get structured JSON, never HTML
Platform | How it runs |
macOS | Browser window positioned off-screen (-32000, -32000) |
Linux with display | Same as macOS |
Linux headless (SSH) | Auto-starts Xvfb virtual display |
This project reverse-engineers DoorDash's internal web APIs for personal use. It is not affiliated with, endorsed by, or connected to DoorDash in any way. Use at your own risk — endpoints may change without notice, and automated access may violate DoorDash's Terms of Service.
MIT
Add an item to your DoorDash cart
| Name | Required | Description | Default |
|---|---|---|---|
| storeId | Yes | Store ID | |
| menuId | Yes | Menu ID | |
| itemId | Yes | Item ID from the menu | |
| itemName | Yes | Item name | |
| unitPrice | Yes | Price in cents (e.g. 1540 for $15.40) | |
| quantity | No | Quantity to add | |
| currency | No | Currency code (e.g. USD, CAD) | USD |
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 'Add an item' implies a write/mutation operation, it doesn't disclose important behavioral traits: whether this requires authentication, if it modifies existing cart state, what happens on duplicate items, error conditions, or what the response looks like. For a mutation tool with zero annotation coverage, this is insufficient.
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 zero wasted words. It's appropriately sized for this tool and front-loads the essential information. Every word earns its place in conveying the core purpose efficiently.
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 mutation tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address authentication requirements, error handling, response format, or how this integrates with the cart management workflow involving sibling tools. The agent lacks sufficient context to use this tool effectively in real scenarios.
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 7 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema. It doesn't explain relationships between parameters (e.g., that storeId, menuId, and itemId should be consistent) or provide usage examples. Baseline 3 is appropriate when schema does the heavy lifting.
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 an item') and target ('to your DoorDash cart'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'remove_from_cart' or explain how it relates to 'list_carts' in terms of cart management workflow.
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 (like needing to be logged in via 'login_check'), how it interacts with 'list_carts' for viewing cart contents, or when to use 'remove_from_cart' instead. There's no context about when this operation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active DoorDash carts
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 'List all active DoorDash carts' which implies a read-only operation, but doesn't specify what 'active' means, whether it requires authentication, how results are formatted, or if there are rate limits. For a tool with zero annotation coverage, this leaves significant gaps.
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, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a simple list operation and front-loads the core functionality 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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It explains what the tool does but lacks behavioral context (like auth requirements or result format) that would be helpful for an agent. For a basic list tool, it meets minimum viability but has clear gaps.
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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the absence of inputs. The description adds no parameter information (which isn't needed), maintaining the baseline of 4 for zero-parameter tools as per the guidelines.
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 ('List') and target resource ('all active DoorDash carts'), making the purpose immediately understandable. It doesn't distinguish from siblings like 'order_history' or 'search_restaurants', but the verb+resource combination is specific enough for basic understanding.
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 like 'order_history' (which might show past orders) or 'add_to_cart' (which modifies carts). There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if the DoorDash session is active
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe the return format (e.g., boolean, status object), error conditions, or any side effects. For a tool with zero annotation coverage, this is insufficient, though it at least correctly indicates a read-only check 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 a single, clear sentence with no wasted words. It's front-loaded with the core purpose and efficiently communicates the essential action. Every part of the sentence earns its place, making it highly concise and well-structured.
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 simplicity (zero parameters, no output schema, no annotations), the description is minimal but adequate for basic understanding. However, it lacks details on the return value or behavioral context, which are important for an agent to use it effectively. With no output schema, the description should ideally hint at what 'active' means or what format the check returns.
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 tool has zero parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. A baseline of 4 is applied for zero-parameter tools when the schema is fully covered.
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 ('check') and resource ('DoorDash session'), making it immediately understandable. It doesn't explicitly differentiate from sibling tools, but since none of the siblings appear to perform session status checks, this is adequate for a 4.
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., whether a session must exist first), timing (e.g., before performing other operations), or what to do based on the result. This leaves the agent with minimal context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent DoorDash order history
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of orders to fetch |
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 what the tool does but provides no information about authentication requirements, rate limits, error conditions, response format, or whether this is a read-only operation. 'Get' implies read-only, but this isn't explicitly confirmed.
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, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple tool with one parameter and gets straight to the point.
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 one well-documented parameter and no output schema, the description is minimally adequate. However, it lacks important context about authentication, response format, and error handling that would be helpful for an agent to use this tool effectively.
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 fully documents the single 'limit' parameter. The description doesn't add any parameter semantics beyond what's in the schema, but with complete schema coverage, the baseline is 3.
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') and resource ('recent DoorDash order history'), making the tool's purpose immediately understandable. It doesn't differentiate from siblings, but none of the listed sibling tools appear to directly overlap with order history retrieval, so a 4 is appropriate.
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. While sibling tools like 'search_restaurants' or 'list_carts' serve different purposes, there's no explicit comparison or context about when order history retrieval is appropriate versus other data access tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an item from your DoorDash cart
| Name | Required | Description | Default |
|---|---|---|---|
| cartId | Yes | Cart ID | |
| itemId | Yes | Order item ID to remove |
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 the action ('remove') which implies a destructive mutation, but provides no information about permissions required, whether changes are reversible, error conditions, or what happens to the cart after removal. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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, efficient sentence that states the core purpose without any wasted words. It's appropriately sized for a simple tool and front-loads the essential information. Every word earns its place in this concise formulation.
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 destructive mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns (success confirmation? updated cart?), error conditions, or behavioral implications. Given the complexity of cart manipulation and the lack of structured safety information, the description should provide more operational context.
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 both parameters clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
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 ('remove') and target resource ('item from your DoorDash cart'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'add_to_cart' or 'list_carts', but the verb 'remove' provides inherent differentiation. This is clear but lacks explicit sibling comparison.
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 (like needing a cart ID from 'list_carts'), when removal is appropriate versus modifying quantities, or what happens if the item doesn't exist. Without any usage context, the agent must infer everything from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for restaurants and food on DoorDash
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (e.g. 'pizza', 'sushi', 'McDonald\'s') |
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. While 'Search' implies a read-only operation, the description doesn't specify whether this requires authentication, has rate limits, returns paginated results, or what format the results take. For a search tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.
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 extremely concise at just 7 words: 'Search for restaurants and food on DoorDash'. It's front-loaded with the core purpose, contains zero wasted words, and efficiently communicates the essential information in a single, clear 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 lack of annotations and output schema, the description is incomplete for a search tool. It doesn't explain what the search returns (restaurant listings? menu items? availability?), whether authentication is required, how results are structured, or any limitations. For a tool that presumably returns complex search results, this minimal description leaves too many contextual questions unanswered.
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 input schema has 100% description coverage, with the single 'query' parameter clearly documented as 'Search query (e.g. 'pizza', 'sushi', 'McDonald\'s')'. The description doesn't add any additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate when the schema does the heavy lifting.
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: 'Search for restaurants and food on DoorDash'. It specifies the verb ('Search') and resource ('restaurants and food'), and identifies the platform ('DoorDash'). However, it doesn't explicitly differentiate this search tool from potential sibling tools like 'get_store_menu' or 'list_carts', which might also involve restaurant/food 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 when this search tool should be used instead of 'get_store_menu' (which might retrieve specific menu details) or 'list_carts' (which might show cart contents). There's no context about prerequisites, timing, or exclusions for using this search functionality.
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_cartget_store_menulist_cartslogin_checkorder_historyremove_from_cartsearch_restaurantsEach tool has a clearly distinct purpose with no overlap: cart management (add/remove/list), menu/restaurant lookup (get_store_menu/search_restaurants), session checking (login_check), and order history. The descriptions make it easy for an agent to select the right tool for specific tasks like browsing versus ordering.
The tools mostly follow a consistent verb_noun pattern (e.g., add_to_cart, get_store_menu, list_carts), with all using snake_case. The minor deviation is 'login_check' which uses a noun_verb structure instead of verb_noun, but this is a small inconsistency that doesn't significantly impact readability or predictability.
With 7 tools, this server is well-scoped for DoorDash operations, covering key actions like browsing, cart management, and order tracking. Each tool earns its place without redundancy, making it manageable for agents while providing comprehensive functionality for the domain.
The tool set covers core DoorDash workflows: browsing (search_restaurants, get_store_menu), cart management (add/remove/list), session handling (login_check), and order review (order_history). A minor gap is the lack of a tool to place an order or checkout from the cart, which could limit end-to-end automation, but agents can still perform most tasks effectively.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI food ordering across Canada — 17,000+ restaurants, 89 cities, real UberEats + DoorDash.
Directory of APIs, merchants, and tools AI agents can actually use.
Web data tools for AI agents: pages as markdown, search, maps, commerce, jobs, AI answers.
AI-native restaurant discovery: verified/menu-indexed/discovered tiers + signed allergy-safety data.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SpunkySarb/doordash-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
