Sapiom MCP overview

Sapiom MCP connects Claude Code or Codex to Sapiom’s agent-authoring and operations lifecycle. You describe an outcome in ordinary language; your coding agent reads the project, chooses the appropriate Sapiom tools, constructs their inputs, and explains the result.

It is not a direct capability gateway. Sapiom capabilities such as Search, Browser Automation, Compute, and Data are authored as typed ctx.sapiom.* calls and make real requests only inside a Sapiom-managed production agent run. Local Run replaces those calls with stubs.

Sign in before project work

Authenticate the Sapiom MCP connection before creating, editing, checking, locally running, cloning, deploying, or operating a project. Scaffold, check, and Local Run still execute on your machine after sign-in; authentication does not move local source or local execution into hosted infrastructure.

One interface, three names

You can see three identifiers for the same connection:

Identifier	Example	What it means
Client alias	sapiom-project	The local label in Claude Code or Codex configuration. You choose and inspect this name.
Package	@sapiom/mcp	The npm package the coding-agent client starts as a local stdio process.
Exact tool	sapiom_dev_agents_check	A wire-level operation exposed by that process. Tool approval and allowlists use exact tool names.

The alias does not rename the server or its tools. Start with an outcome prompt; use exact identifiers only for an approval rule, deterministic automation, or troubleshooting.

What happens where

Action	After Sapiom sign-in, where it runs	Hosted state or usage
Scaffold or configure a project	Your machine	Writes local files; setup can contact npm. No capability request.
Check	Your machine	Bundles and imports author code. No capability request.
Local Run	Your machine	Executes author code with ctx.sapiom.* stubbed. No Sapiom capability spend.
Clone or link	Your machine plus Sapiom services	Reads or creates organization-owned repository or agent identity.
Deploy	Local packaging plus Sapiom build infrastructure	Uploads the current working tree and creates a potentially metered cloud build.
Production run	Sapiom-managed runtime	Starts a real run; capabilities used by its steps can create metered usage.
Inspect, signal, or schedule	Sapiom services	Reads or changes production execution and trigger state.
Released web-app preview tools	Local configuration plus direct hosted preview infrastructure	Present in 0.12.10 for inventory completeness, but not a supported public workflow while direct preview execution bypasses the agent-run capability boundary.

Local author code remains ordinary code. A check can run top-level module effects, and Local Run can make real filesystem, subprocess, network, or third-party SDK calls outside ctx.sapiom.*.

Tool map by job

The released @sapiom/[email protected] package exposes 20 public tools:

Job	Exact tools	Start here
Sign in, inspect the connection, or sign out	sapiom_authenticate, sapiom_status, sapiom_logout	Connect and authenticate
Create a bundled starter or clone existing source	sapiom_dev_agents_scaffold, sapiom_dev_agents_clone	Create from a template
Validate and test locally	sapiom_dev_agents_check, sapiom_dev_agents_run_local	Build, then Test locally
Link and deploy	sapiom_dev_agents_link, sapiom_dev_agents_deploy	Deploy
Start and inspect production runs	sapiom_dev_agents_run, sapiom_dev_agents_inspect	Run in production, then Inspect
Deliver a signal	sapiom_dev_agents_signal	Use signals
Preview, create, inspect, or cancel triggers	sapiom_dev_agents_cron_preview, sapiom_dev_agents_schedule, sapiom_dev_agents_schedule_inspect, sapiom_dev_agents_schedule_cancel	Schedule
Identify released web-app preview tools	sapiom_dev_sandbox_configure, sapiom_dev_sandbox_check, sapiom_dev_sandbox_preview	Agent-project workflows explains why direct use is not supported.
Send user-approved product feedback	sapiom_send_feedback	Agent-project workflows

The complete tool reference gives every input, constraint, return contract, side effect, and expected failure. Its input tables are generated from the released server’s runtime schemas rather than copied by hand.

The usual lifecycle

authenticate
    ↓
scaffold or clone → check → Local Run
                           ↓
                        link → deploy → production run → inspect
                                                          ↕
                                                        signal

Schedules attach to an already-deployed agent and start future production runs. The released web-app preview sequence is documented for identification only until its direct hosted execution is aligned with the same agent-run boundary.

Connect and authenticate Register the supported local connection, verify it, and sign in.

Work with agent projects Use outcome prompts for creation, testing, deployment, operations, released-tool identification, and feedback.

Browse all tools Read generated inputs and reviewed behavior for every released public tool.