> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stateset.com/llms.txt
> Use this file to discover all available pages before exploring further.
# MCP Servers
> Every StateSet service as agent-callable tools — which server to use, how to connect it, and how to scope its access.
# MCP Servers
Most StateSet services ship a [Model Context Protocol](https://modelcontextprotocol.io) server,
so an MCP host — Claude Code, Claude Desktop, Cursor, the Agent SDK — can drive them as native
tools.
Every server is a thin wrapper over the service's own REST API. They hold no state of their own,
which means they stay in lockstep with the API and inherit its authentication and permissions
exactly.
## Which server do I want?
| Service | Server / package | Tools | What an agent can do |
| ------------------------------------------------------- | -------------------------------------------------------------- | ------- | ------------------------------------------------------------------------- |
| [iCommerce](/stateset-icommerce/stateset-icommerce-mcp) | `stateset-commerce` (via `@stateset/cli`) | **719** | Run the whole commerce engine — orders, inventory, finance, manufacturing |
| [EDI](/stateset-edi/mcp-server) | `@stateset/edi-mcp` | 117 | Trading partners, inbound/outbound documents, labels, deductions |
| [Mail](/stateset-mail/mcp-server) | `stateset-mail-mcp` (in-binary) | 26 | Campaigns, profiles, segments, and the agent inbox |
| [Voice](/stateset-voice/mcp-server) | `@stateset/voice-mcp-server` | 24 | Build voice agents, route numbers, place calls, read transcripts |
| [NSR](/stateset-nsr-mcp) | `stateset-nsr-mcp` | 14 | Verified decisions with cited proofs, rules, knowledge base |
| [Sync Server](/stateset-sync-mcp) | built into the server binary | — | Order/inventory sync across 180+ integrations, per tenant |
| [ResponseCX](/stateset-response/response-mcp) | `responsecx` (remote, `POST /api/mcp`) | — | Build and tune CX agents; separately, read analytics |
| [Temporal engine](/next-temporal/mcp-connector) | `stateset-config-connector` (in `engine-api`) | 7 | Read and edit a brand's automation config |
| [Computer Use](/computer-use-mcp) | `@stateset/computer-use-agent-mcp`, plus a local Python server | 9 / 10 | Delegate a whole computer-use task, hosted or local |
| [Sandbox](/stateset-sandbox/stateset-sandbox-mcp) | `shopify`, `shopify-full`, `gorgias`, `recharge` | 40+ | Shopify, Gorgias, and Recharge operations |
Several servers are **built into the service they expose** rather than shipped separately — the
Sync Server, the Temporal engine's `engine-api`, ResponseCX, and Mail. For those there is nothing
extra to deploy: point your host at the running service.
`@stateset/edi-mcp`, `@stateset/voice-mcp-server`, and `@stateset/computer-use-agent-mcp` are
publishable packages that are **not yet on the npm registry** — build them in-repo for now. Each
page notes the `npx` form to switch to once published.
## Two transports
Every server offers one or both:
**stdio** — the host launches the server as a child process. Simplest for desktop clients, and
the tools dispatch in-process with no HTTP round-trip.
```json theme={null}
{
"mcpServers": {
"stateset-edi": {
"command": "node",
"args": ["/absolute/path/to/dist/index.js"],
"env": { "EDI_API_BASE": "https://…", "EDI_API_TOKEN": "…" }
}
}
}
```
**Streamable HTTP** — the host connects to a URL. Use this when the agent runs somewhere other
than the machine hosting the service, or when you want one connection shared by several agents.
```bash theme={null}
claude mcp add stateset-config \
--transport http https://api.workstream.stateset.com/v1/mcp \
--header "Authorization: Bearer "
```
For a remote server from Claude Desktop, which speaks stdio only, bridge it with `mcp-remote`:
```json theme={null}
{
"command": "npx",
"args": ["-y", "mcp-remote", "https://…/mcp", "--header", "Authorization: Bearer …"]
}
```
## Scoping access
This is the part worth getting right before you connect anything.
An MCP server gives an agent whatever the key you hand it can do. Several StateSet servers
expose tools that **move money, contact customers, or mint credentials**:
* **Voice** — `make_call` places a real, billable PSTN call. `create_api_key` mints a tenant
credential.
* **EDI** — outbound document tools send real documents to real trading partners.
* **iCommerce** — 287 write, 47 admin, and 21 delete tools out of 719.
* **Sync Server** — order mutation tools reach live commerce platforms.
Use a **scoped key**, not an admin one, and prefer a per-tenant or per-brand credential so a
mistaken call cannot reach another customer's data.
Server-side controls worth knowing:
| Control | Where |
| ------------------------------- | --------------------------------------------------------------- |
| Per-tenant **read-only mode** | Sync Server — DB-persisted, survives restarts |
| Per-tenant **tool blocklist** | Sync Server — disable individual tools for one tenant |
| Scope-filtered tool lists | ResponseCX — `tools/list` only advertises what the key permits |
| Optimistic concurrency | Temporal config connector — `expected_config_version` on writes |
| Signed single-use confirmations | EDI operator agent mutations |
## A pattern worth copying
The NSR server exists to make other agents safer. Rather than trusting a model's judgement on a
consequential action, route the decision through `nsr_decide` and act only on an `approved`
verdict backed by cited rules. A `refused` verdict is the **correct** outcome — the agent asks
for missing facts or escalates instead of guessing.
Its `verify_before_acting` prompt hands your host exactly that guardrail. See
[NSR MCP Server](/stateset-nsr-mcp).
## Building your own
If you want to expose your *own* service to StateSet agents rather than consume ours, see the
[MCP Integration Guide](/guides/mcp-integration-guide), which walks through implementing a
server and client from scratch.