doordash-dashpilot-mcp

Official

Overview Schema Source Related Servers Discussions Admin

dispatch_delivery

Destructive

Immediately dispatch a DoorDash delivery by quoting and accepting in one step. Confirm the fee and ETA first, since dispatching assigns a Dasher and bills your Drive account.

Instructions

Dispatch a delivery immediately (quote + accept in one step): a Dasher is assigned and the delivery is billed by DoorDash to your Drive account. MOVES MONEY: quote first with get_delivery_quote, show the user the fee and ETA, and dispatch only after their explicit confirmation. The request goes straight to DoorDash, signed with your local key. Parameters are identical to get_delivery_quote.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "external_delivery_id": "<external_delivery_id>",
      "pickup_address": "<pickup_address>",
      "dropoff_address": "<dropoff_address>",
      "dropoff_phone_number": "<dropoff_phone_number>",
      "order_value": "<order_value>"
    },
    "name": "dispatch_delivery"
  }
}

Input Schema

Name	Required	Description	Default
`tip`	No
`order_value`	Yes
`pickup_address`	Yes
`dropoff_address`	Yes
`contactless_dropoff`	No
`pickup_instructions`	No
`dropoff_instructions`	No
`dropoff_phone_number`	Yes
`external_delivery_id`	Yes
`pickup_business_name`	No
`pickup_reference_tag`	No
`dropoff_contact_given_name`	No
`dropoff_contact_family_name`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 4, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds critical context the annotations cannot convey: this MOVES MONEY, bills the Drive account, and is signed with the local key and sent to DoorDash. It stops short of stating reversibility (whether cancel_delivery can unwind it) or any rate/idempotency caveats, which would round it out.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences, front-loaded with the action and the money warning, then the required workflow. Every clause carries information (one-step semantics, billing, confirmation gate, signing, param parity).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, money-moving tool with 13 undocumented parameters and no output schema, the description covers the most dangerous aspects (irreversibility implied by money movement, confirmation requirement, quote-first prerequisite). The remaining gap is parameter meaning, which is only deflected to a sibling tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 13 parameters, including 5 required ones such as order_value and external_delivery_id. The description compensates only by pointing to get_delivery_quote ('Parameters are identical'), forcing a cross-tool lookup rather than explaining fields like order_value units or the tip default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (dispatch a delivery) and immediately clarifies the semantics: quote + accept in one step with a Dasher assigned and billed to the Drive account. This distinguishes it clearly from siblings like schedule_delivery, accept_quote, and dispatch_due_deliveries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly prescribes the workflow: quote first with get_delivery_quote, show the user the fee and ETA, and dispatch only after explicit confirmation. It names the prerequisite tool and the gating condition, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server