Skip to main content
The Nash MCP server lets an AI agent work with your deliveries directly — look up live status, create orders, request refunds — through the Model Context Protocol, the open standard for connecting AI agents to external tools. Point Claude, Cursor, or any MCP-capable agent at the server and the Nash platform becomes part of its toolset.
Access to the Nash MCP server is enabled per organization. Reach out to sales@usenash.com to get started.
This server acts on your organization’s data and needs your API key. If what you want is an assistant that can read the documentation while you build — no credentials, open to everyone — connect the docs MCP server instead. Build with AI compares the two.

​
When to use this

Use the MCP server when an AI agent — yours or an off-the-shelf assistant — should operate deliveries as part of a conversation or workflow, rather than your code calling the REST API directly:
  • A customer-facing assistant that creates a delivery when an order is placed, answers “where’s my order?” with live data, and handles refund requests in the same conversation.
  • An internal operations agent that monitors delivery performance, watches courier activity, and runs bulk operations across store locations.
  • An AI workflow that needs delivery as one step among many — quoting, dispatching, and tracking without leaving the agent’s context.
If you’re integrating from application code rather than an agent, the REST API is the more direct path. And if you want an agent that’s already wired into Nash, Nash Agent ships with all of this built in.

​
What the server exposes

The MCP server surfaces the platform’s core operations as tools your agent can call:
  • Deliveries — create deliveries with pickup and dropoff locations, track status in real time, and request refunds for failed or problematic ones.
  • Couriers — courier information, including location and contact details.
  • Scheduling — delivery windows, including capacity-aware booking.
  • Batch operations — act on multiple deliveries in one call.
  • Store locations — manage delivery origins.
  • Documents — retrieve proof of delivery and related documents.
  • Configuration — read your workflows and their run history, dispatch strategies, contracts, and the providers enabled for your organization.
The reads an agent reaches for most often are first-class tools rather than something it has to assemble from the raw API. find_order resolves whatever identifier you have — a Nash order or job ID, your own external ID, a reference ID, or the short code on a tracking link — in one call. list_orders and list_jobs take typed filters, get_orders_bulk and get_jobs_bulk fetch up to 50 at a time with a per-item result so one miss doesn’t fail the batch, and every read accepts a fields list so the agent asks for ["id", "status", "dropoff.address.city"] instead of the whole record. Tools run with the permissions of the API credentials behind them, so an agent can only see and do what its key allows. A read the key isn’t permitted to make is reported as skipped rather than failed.

​
Connect your agent

The Portal generates the exact connection details for you under AI → MCP Server, with a tab per client. Two things go across: the server URL, which carries your organization ID, and your API key. Send the key as a header. This is the connection method to reach for, and the one the Portal leads with: Point the client at the sandbox host — https://mcp.sandbox.usenash.com/mcp — while you’re building. See Environments for how the two differ. Some hosted connectors can’t set request headers at all. For those, the Portal also gives you a single URL with the key embedded in the query string:
A URL with the key embedded in it is the credential — anything that can read the URL can act as your organization. Clients, proxies, and browsers write URLs to their logs and history as a matter of course, so treat that link like a password: use it only where headers aren’t an option, keep it out of shared documents and tickets, and rotate the key if it goes somewhere it shouldn’t.

​
Getting started

Email sales@usenash.com and our team will set up access to the MCP server, configure authentication and permissions, share the function-level documentation, and help with integration testing.

Docs MCP server

Let your assistant search and read these docs while you build.

Using LLMs with the Nash API

Hand the full API reference to an LLM — llms.txt and the OpenAPI spec.

Nash Agent

The operations copilot that already has these tools — no integration required.