Two MCP servers
Nash exposes two MCP servers, and they do different jobs.
The docs MCP server is the one to connect while you build. It lets Claude, Cursor, VS Code, or any MCP client search and read the current docs, so the assistant writing your
POST /orders call is reading the same request schema you are.
The Nash MCP server is the one to connect when an agent should act: create a delivery when an order lands, answer “where’s my order?” with live status, request a refund in the same conversation. It runs with your API key’s permissions and is enabled for your organization by our team.
A coding agent doing a Nash integration benefits from both — the docs for how the platform works, the Nash server for trying calls against your sandbox as it goes.
Machine-readable references
Not every assistant can connect to an MCP server. For the ones that take pasted context, links, or fetched URLs, the whole documentation is published in formats built for models:
The menu at the top of every page offers the same things one page at a time: copy it as Markdown, open it in Claude, or connect the docs MCP server to Cursor or VS Code.
Using LLMs with the Nash API covers how to prompt with these, and what to keep out of the prompt.
An agent that’s already wired in
If what you want is an operations agent that knows Nash, and you’d rather not build one, Nash Agent ships with the platform. It has the same tools the Nash MCP server exposes, runs inside the Portal, and can be reached over chat channels or embedded in your own product.Where to start
Docs MCP server
Connect your assistant to the docs. No credentials, one URL.
Nash MCP server
Give an agent the tools to run deliveries with your API key.
Nash Agent
The operations copilot that needs no integration at all.