Sapiom MCP

@sapiom/mcp

The local developer MCP server for Sapiom. It runs on your machine over stdio under the server name sapiom-dev. Today it gives a coding agent the tools to scaffold, test, deploy, and inspect Sapiom agents, and to put a web app behind a live sandbox URL or a durable App Link; the namespace leaves room for other developer tooling later.

Not the capability surface. This is _not_ the remote "Sapiom" MCP (the

hosted connector with sapiom_sandbox_*, scrape, search, … capability tools).

sapiom-dev exposes no direct capability tools. Its local check and Local

Run path uses stubbed capabilities without Sapiom capability spend; deploys,

cloud builds, production runs, signals, and schedules operate Sapiom cloud

state and may be metered. See

the two Sapiom MCP servers for which to use when.

Install

No global install — run it on demand with npx:

{

"mcpServers": { "sapiom-dev": { "command": "npx", "args": ["-y", "@sapiom/mcp"], }, }, }

In Claude Code:

claude mcp add sapiom -- npx -y @sapiom/mcp

Configuration

The server targets the production environment by default. Override it with the SAPIOM_ENVIRONMENT environment variable:

{

"mcpServers": { "sapiom-dev": { "command": "npx", "args": ["-y", "@sapiom/mcp"], "env": { "SAPIOM_ENVIRONMENT": "staging" }, }, }, }

• production (alias prod) → app.sapiom.ai / api.sapiom.ai — the default.
• staging (alias dev) → app.sapiom.dev / api.sapiom.dev.

Both resolve from built-in presets, so no config file is required. A custom target can be defined in ~/.sapiom/credentials.json (the server prints the expected shape if it encounters an unknown environment name).

The API key only travels over https://, or plain http:// to a loopback host (localhost, *.localhost, 127.0.0.1, [::1]). A custom target on any other http:// host is refused before the request is sent. On a trusted private network, set SAPIOM_ALLOW_INSECURE_HTTP=1 in the server's env.

Authentication

The first networked call (link, deploy, run, inspect, signal) needs a Sapiom API key. Run `sapiom_authenticate` and the server opens a browser login flow, then caches the resulting key per environment in ~/.sapiom/credentials.json. After that, tools work without re-authenticating. sapiom_status reports who you're authenticated as; sapiom_logout clears the cached credentials.

The local authoring tools (scaffold, check, run_local) need no Sapiom authentication. scaffold may query npm for current dependency versions; check imports the definition; and run_local executes the author's ordinary local code. Only ctx.sapiom.* calls are replaced by stubs, so direct network, filesystem, environment, and process effects in author code remain real.

Tools

A typical loop: scaffold → write step code → run_local until green → link → deploy → run → inspect.

For a web app rather than an agent: sandbox_configure → sandbox_preview while iterating (a throwaway URL that dies with the sandbox) → app_publish once the link needs to be permanent or shared. app_publish reads the same sapiom.json sandbox resource, uploads the source as a stored text-only bundle (≤ 10 MiB), and returns a durable https://apps.sapiom.ai/{org}/{slug} URL that wakes the app on demand — republishing the same slug updates it in place. See the sapiom-sandbox-preview skill for the routing rules.

Once a link exists, app_list, app_settings and app_delete manage it without leaving the terminal. Webhooks are off by default: app_settings { slug, webhooksEnabled: true } turns them on, after which third parties POST to https://apps.sapiom.ai/{org}/{slug}/hook/ (the /hook prefix is stripped and the body forwarded byte-exact, so Slack/Stripe/GitHub signature checks run inside the app). These settings need the org.write permission — publish authority alone is not enough — and a refusal comes back as a message naming the permission and the fields, for the agent to relay rather than retry.

The agent map

sapiom_dev_map returns the map Agent Studio draws, computed from code on every call; nothing about agents or edges is stored. Pass a project folder (root, default the working directory) and optionally a git ref (HEAD, a branch, a commit) to draw that version:

{ "root": "~/agents/support-desk", "ref": "HEAD" }

The scan finds every folder with a sapiom.json or a defineAgent and reads:

• Edges, agent to agent, each with the file and line that proves it: agents.run / agents.launch (launch), schedules.create on another agent (timer), and events.emit matched to the agents an event type triggers (event). A target counts when the code makes it knowable: a literal, a const (local or imported), every value of a const map indexed at run time, a zod .default() on the input field the call reads, or a process.env key set in sapiom.json. Anything else is listed under unresolved.
• Systems: connected components over those edges. Agents that only share a vault key, database or connector are not joined; the shared resource shows in each agent's shared list. Name a system in a committed .sapiom/map.json: { "systems": [{ "agent": "intake", "name": "Support desk" }] }.
• Steps from agents check (needs the agent's dependencies installed).
• Triggers and deploy state from the signed-in account, plus a fleet.json's declared triggers. Signed out, platform says so and the map still draws.
• `changedSinceRef`: the agent's folder differs from ref (from HEAD when drawing the working copy).

To map agents you describe yourself, without scanning, pass agents:

{

"agents": [ { "slug": "intake", "emits": [{ "eventType": "ticket.opened" }] }, { "slug": "triage", "triggers": [{ "kind": "event", "eventType": "ticket.opened" }], "calls": [{ "to": "notify", "kind": "launch" }] }, { "slug": "notify", "resources": ["connector:slack"] } ] }

Each agent takes slug and optionally path, description, deployed, steps ({ entry, steps: [{ id }], transitions: [{ from, to, kind }] }), calls ({ to, kind: "launch" | "signal" | "timer", evidence? }), emits, triggers and resources. The same systems rule applies.

Labels. Signed in, the tool asks Jev (jev-1.13.0, one batched decisions.evaluate call) for each described agent's role (intake, worker, orchestrator, reporter, monitor or utility) and for the label of each launch or event edge (hands work to, feeds data to or monitors). A label appears only when its probability p is at least 0.8. Answers are cached in /.sapiom/cache/map-labels.json (ignored by git from inside the folder; in memory for a described map), keyed by a hash of the question's facts, so an unchanged agent is never re-asked and its label never flips. In a scanned project, when an agent changes, the label it showed stays unless the new answer differs and clears 0.8. Signed out, with platform: false, or when Jev fails or takes over 5 s, the map comes back with labels: "unavailable" and is otherwise the same.

How capabilities fit in

Agents authored here call Sapiom capabilities — sandboxes, repositories, coding agents, search, storage, content generation — through @sapiom/tools (ctx.sapiom.*). run_local resolves those calls from stubs; deploy and production run cross into authenticated cloud operations and can be metered. This MCP never grows a per-capability tool of its own — capabilities live in @sapiom/tools and the remote sapiom MCP. See the positioning doc for the full policy.

Send