Skip to main content

​
MCP Servers

Most StateSet services ship a Model Context Protocol 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?

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.
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.
For a remote server from Claude Desktop, which speaks stdio only, bridge it with mcp-remote:

​
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:

​
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.

​
Building your own

If you want to expose your own service to StateSet agents rather than consume ours, see the MCP Integration Guide, which walks through implementing a server and client from scratch.