Integrates with DoorDash to enable food delivery ordering through AI agents. Supports searching for restaurants by cuisine or food type, browsing menus with item details and prices, adding items to cart, placing orders with delivery addresses and special instructions, and tracking orders with real-time status updates.
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., "@@striderlabs/mcp-doordash Find Thai restaurants near me for delivery."
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.
Order food delivery via DoorDash using AI agents
Part of Strider Labs — action execution for personal AI agents.
Add this to ~/.openclaw/config.json or your Claude Desktop config:
{
"mcpServers": {
"doordash": {
"command": "npx",
"args": ["-y", "@striderlabs/mcp-doordash"]
}
}
}Restart Claude.
Tell Claude: "Order Thai food from nearby for delivery today"
Your agent can now place orders. That's it.
Related MCP server: DoorDash MCP Server
npm install @striderlabs/mcp-doordashOr with npx directly:
npx @striderlabs/mcp-doordash🔍 Search restaurants by name, cuisine, or food type
📜 Browse menus with full item details and prices
🛒 Add to cart with quantity and special instructions
💳 Place orders with confirmation step
📍 Track orders with real-time status updates
🔐 Persistent sessions - stay logged in across restarts
🔄 Automatic MFA - handles multi-factor authentication
📱 Per-user credentials - encrypted session storage
Component | Version | Status |
MCP SDK | ^1.0.0 | ✅ |
Node.js | 18+ | ✅ |
Claude Desktop | Latest | ✅ |
Claude (API) | claude-3.5-sonnet+ | ✅ |
Anthropic SDK | ^0.20+ | ✅ |
Weekly downloads: 395 (Apr 10-17, 2026) — #1 Strider Labs connector (+24% growth)
Status: ✅ Live in production
Reliability: 85%+ task completion rate
Discovery: npm, Claude Plugins, mcpservers.org, ClawHub, PulseMCP
Claude Plugins: Search "Strider Labs" in Claude
mcpservers.org: Strider Labs DoorDash
Full Strider Labs: github.com/striderlabsdev/striderlabs
Your agent can use these capabilities:
// Search for restaurants
restaurants = search_restaurants({
location: "San Francisco, CA",
cuisine: "Thai",
max_delivery_time: 30
})
// Browse a restaurant's menu
menu = get_restaurant_menu({
restaurant_id: "thai-place-downtown",
search: "Pad Thai"
})
// Place an order
order = place_order({
restaurant_id: "thai-place-downtown",
items: [
{ item_id: "pad_thai", quantity: 1 },
{ item_id: "spring_rolls", quantity: 2 }
],
delivery_address: "123 Main St, San Francisco, CA",
special_instructions: "Extra lime on the side"
})
// Track delivery
status = track_order({ order_id: order.order_id })Each user has encrypted, persistent credentials
Automatic OAuth token refresh
MFA handling (SMS/email)
Sessions survive agent restarts
85%+ task completion rate
Automated UI change detection (connectors update when DoorDash changes)
Fallback paths for failures
24/7 monitoring + alerting
# Optional: Use a specific DoorDash account
DOORDASH_EMAIL=your-email@example.com
DOORDASH_PASSWORD=your-password # Highly recommend using .env file# Clone the repo
git clone https://github.com/striderlabsdev/mcp-doordash
cd mcp-doordash
# Install dependencies
npm install
# Start the server
npm start
# Your agent can now connect to localhost:3000This connector uses browser automation (Playwright) to interact with DoorDash, because DoorDash doesn't have a public API. Here's why that's safe and reliable:
User-controlled: Your agent only accesses your own DoorDash account
Session-based: We store your login session securely, not your password
Change-aware: We detect DoorDash UI changes and alert immediately
Fingerprinting: We use realistic browser profiles to avoid bot detection
Rate-limited: We respect DoorDash's infrastructure with appropriate delays
Credentials stored encrypted in your local .env or secure vault
Sessions isolated per user
No data sent to third parties
MIT Licensed — audit the code yourself
We welcome contributions! Areas of interest:
Bug reports and fixes
Feature requests (new restaurants, cuisines, etc.)
Performance improvements
Documentation enhancements
See CONTRIBUTING.md for guidelines.
MIT — Free to use, modify, and distribute. See LICENSE for details.
Built by Strider Labs — Making AI agents actually useful.
Add a menu item to the cart. Must be on a restaurant page first (use doordash_menu).
| Name | Required | Description | Default |
|---|---|---|---|
| itemName | Yes | Name of the menu item to add | |
| quantity | No | Quantity to add (default: 1) | |
| restaurantId | Yes | The restaurant ID | |
| specialInstructions | No | Special instructions for the item (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only mentions the prerequisite but omits side effects (e.g., cart state changes, error handling, idempotency). For a mutation tool, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The action and prerequisite are front-loaded, making it easy to scan. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with 4 parameters and no output schema. The description lacks details on success/failure behavior, error conditions (e.g., item unavailable), and interaction with cart state. Sibling tools (checkout, cart) hint at broader workflow, but this is not addressed.
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 describes each parameter adequately. The description adds no additional semantic value beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('add a menu item to the cart') and resource, distinguishing it from siblings like doordash_menu (view menu) and doordash_cart (view cart). The verb 'add' and noun phrase are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a prerequisite: 'Must be on a restaurant page first (use doordash_menu).' This guides the agent to the correct prior tool. No explicit when-not-to-use or alternatives, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if user is logged in to DoorDash. Returns login status and instructions if not authenticated. Call this before any other DoorDash operations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses the behavior: checking login status and returning instructions if not authenticated. Could be more specific about what 'instructions' entails, but sufficient for a simple auth check.
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: first states purpose, second gives usage guideline. Extremely concise with no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple auth check with no parameters and no output schema, the description covers purpose and usage context adequately. It mentions return value (login status and instructions) and prerequisite nature. Could be more detailed about the instructions, but overall complete enough.
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?
No parameters (0), so baseline is 4. Description adds no parameter info because none exist; schema coverage is 100% (empty schema). No need for additional semantics.
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 checks login status and returns instructions if not authenticated. It distinguishes itself from siblings by being a prerequisite check, contrasted with operations like doordash_add_to_cart or doordash_checkout.
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?
Explicitly says 'Call this before any other DoorDash operations,' providing clear when-to-use guidance. It doesn't mention when not to use alternatives, but the context makes it obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear stored DoorDash session cookies. Use this to log out or reset authentication state.
| 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 full burden. It discloses the action (clearing cookies) but lacks details on side effects, such as whether user sessions are immediately invalidated or if re-authentication is required.
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 short, front-loaded sentences with no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description fully explains its purpose and usage. No gaps remain for the intended use case.
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, and schema coverage is 100% empty. The description adds meaning by explaining what the tool accomplishes (logout/reset), which is helpful despite no param details.
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: clearing stored DoorDash session cookies to log out or reset authentication state. It uses a specific verb ('clear') and distinguishes from sibling tools like doordash_auth_check.
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 explicitly says 'Use this to log out or reset authentication state.' It provides clear context for when to use, though it does not mention exclusions or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View current cart contents, including items, quantities, and totals.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly indicates a read-only operation (view) without side effects. However, it omits details like authorization needs or potential staleness, though these are less critical for a simple view.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key purpose, no wasted words. Efficient and clear.
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 view tool with no parameters and no output schema, the description is complete enough. It covers what the tool shows (items, quantities, totals). Could add context about cart persistence or user association, but not essential.
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?
No parameters exist, and schema coverage is 100%. Description correctly adds no parameter info because none are needed.
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 resource (cart contents). It lists specific aspects (items, quantities, totals) and distinguishes from sibling tools like doordash_add_to_cart (modify) and doordash_checkout (action).
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 when to use (to view cart) but does not explicitly mention when not to use or provide alternatives. Given sibling tools hint at context, but no clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Proceed to checkout and optionally place the order. Set confirm=false to preview order details, confirm=true to actually place the order.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | Set to true to actually place the order, false to just preview |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral distinction between preview (confirm=false) and placing the order (confirm=true). With no annotations, this is adequate for a single-parameter tool, though it does not mention side effects like cart clearing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded, and every word adds value. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what the preview returns, but it does not. The tool's behavior is clear, but completeness suffers from missing return value details.
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% and description restates the schema's explanation of the 'confirm' parameter without adding new information. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Proceed to checkout and optionally place the order.' It distinguishes from sibling tools (e.g., doordash_add_to_cart, doordash_cart) by focusing on the checkout action.
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 explicit usage guidance: 'Set confirm=false to preview order details, confirm=true to actually place the order.' It clearly explains the two modes without requiring additional context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for restaurants on DoorDash. Can search by restaurant name, food type, or cuisine.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (restaurant name, food type, or cuisine) | |
| cuisine | No | Filter by cuisine type (e.g., 'pizza', 'chinese', 'mexican') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior fully. It only mentions search capabilities but omits return format, pagination, effects (e.g., read-only), or error behavior. Insufficient for an agent to understand side effects.
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, no filler, directly states purpose and capabilities. Efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite simple tool, description lacks essential details like expected output (list of restaurants?), limitations (e.g., max results), or any post-search steps. No output schema exists to compensate, so description should address this 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 parameter descriptions. The description restates the searchable fields but does not add new semantics beyond what the schema provides. 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?
Clearly states 'Search for restaurants on DoorDash' with specific verb and resource, and lists searchable attributes (name, food type, cuisine). Distinguishes from sibling tools like doordash_menu and doordash_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 on when to use this tool vs alternatives (e.g., doordash_menu). Does not mention prerequisites or typical workflow. Simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the delivery address for DoorDash orders. Must be set before searching for restaurants.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Full delivery address (e.g., '123 Main St, San Francisco, CA 94102') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only states it sets an address without disclosing any behavioral traits like state changes, idempotency, or side effects.
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 that is front-loaded with the purpose, but it could be expanded slightly without losing conciseness.
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 single parameter and no output schema, the description is adequate but lacks details like return behavior or error conditions, which could help the 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?
The parameter 'address' is fully described in schema with an example, and the description adds only the usage context, providing marginal extra 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 the verb 'Set' and the resource 'delivery address for DoorDash orders', distinguishing it from sibling tools like doordash_search or doordash_menu.
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 explicitly says 'Must be set before searching for restaurants', providing clear when-to-use guidance, though it doesn't mention what happens if not set or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Track the status of an order. Shows delivery progress, estimated time, and dasher info if available.
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | No | Order ID to track (optional - defaults to most recent active order) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It reveals outputs (progress, time, dasher info) but omits constraints like whether it is read-only, error handling for invalid order IDs, or any side effects. The default behavior for optional orderId is noted, but overall transparency 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 two concise sentences, front-loaded with the core action and immediately detailing what is shown. Every word adds value, with no redundancy.
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 (one optional parameter, no output schema, no annotations), the description is largely complete. It explains what the tool does and the default behavior. However, it could improve by noting the return format or potential errors, but this is minor given the 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 coverage is 100% and the description adds meaningful context: 'optional - defaults to most recent active order', which clarifies default behavior. This adds value beyond the schema's type/description fields.
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: tracking an order's status. It specifies the information provided (delivery progress, estimated time, dasher info), which distinguishes it from sibling tools like doordash_cart or doordash_checkout.
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 gives no guidance on when to use this tool versus alternatives, nor are any exclusions or prerequisites mentioned. Usage is vaguely implied but not explicitly contextualized.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.4.4doordash_add_to_cartdoordash_auth_checkdoordash_auth_cleardoordash_cartdoordash_checkoutdoordash_menudoordash_searchdoordash_set_addressdoordash_track_orderEach tool covers a distinct step in the DoorDash workflow (auth, address, search, menu, cart, checkout, tracking) with no overlapping functionality.
All tools are prefixed with 'doordash_' and use a consistent verb or verb_noun pattern (e.g., auth_check, add_to_cart, track_order).
With 9 tools covering the essential order lifecycle, the count is well-scoped for a delivery service integration.
Covers auth, address, search, menu, cart actions, checkout, and tracking. Missing a tool to remove items from cart, but core ordering flow is complete.
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.
Discover and book businesses via AI agents.
Concierge for AI agents: takes action in the physical world — book, order, register, resolve.
Run your restaurant from an AI client: orders, menu, reports, refunds, payouts and staff.
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-doordash'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
