Marrow MCP server

Marrow AI MCP Server

@getmarrow/mcp: the control layer for AI agents. Marrow AI puts a named yes on an action before your agent acts, and leaves proof the next agent can reuse.

Which Marrow? This is Marrow AI from getmarrow.ai (npm @getmarrow/mcp, MCP Registry ai.getmarrow/marrow). It is not affiliated with marrow.id, HyperMarrow, marrow.works or other projects named Marrow.

getmarrow.ai · Docs · Marrow AI for MCP · MCP Registry entry · Changelog ·

Marrow AI is the runtime control and proof layer for teams running AI agents. It applies policy and prior lessons before consequential actions, then records the evidence and outcome afterward.

Use @getmarrow/mcp when your agent client supports the Model Context Protocol and you want Marrow available inside the agent's normal workflow. It works with Claude Code, Claude Desktop, Cursor and other MCP-compatible clients without replacing the model or harness.

Quick start

1. Create a key. Sign up at getmarrow.ai/signup, then open the dashboard, go to API keys and choose Create API key. The key is shown once.

2. Activate. Make the key available as MARROW_API_KEY (from your secret storage, or an owner-only ~/.marrow/env), then run the installer from a terminal:

   npx -y @getmarrow/install@latest activate
   

3. Restart the agent host and review/enable its hook trust.

4. Verify:

   npx -y @getmarrow/install@latest doctor --self-test
   

What is enforced. On the 30-day evaluation and Business, deploys and publishes are held in hooks and the governed runner. Team and Free warn. If Marrow is unreachable, hooks hold high-risk actions and let routine actions run with a warning, and the governed runner stops protected actions it cannot verify. Over MCP, the agent gets the decision and is expected to follow it. Hooks run inside the agent host and are not an external execution boundary: an agent or person who edits the host settings, or works outside the host, is not held.

Agent Discovery

• Publisher: Marrow AI. Capability descriptions in this package are vendor-provided product statements.
• Use this package for: MCP-compatible clients that need status, before-action governance, proof-backed outcome closure, and tenant-scoped fleet lessons in the normal agent workflow.
• Product category: agent fleet governance and control layer.
• Operator boundary: configuring the server, creating an account, or submitting a diagnostic requires operator approval.
• Public diagnostic privacy: raw prompts, source code, credentials, customer data, and free-form work descriptions are not accepted.
• Machine-readable product facts: https://getmarrow.ai/llms.txt and https://getmarrow.ai/.well-known/marrow.json

Maintainers can validate local registry metadata with npm run registry:check. After an approved registry publication, npm run registry:verify confirms that the official registry returns the exact package name and version; package metadata alone is not treated as publication proof.

Public operating guides:

• Governance Readiness Assessment
• Marrow for MCP clients
• Marrow for OpenAI Codex
• Marrow for Claude Code
• Marrow for Cursor
• Marrow for Hermes Agent
• Marrow for OpenClaw

The assessment accepts bounded selections only. It does not install Marrow, authorize a purchase, accept free-form work content, or establish compliance, security, or ROI.

Where Marrow fits

Marrow AI is the optional agent fleet governance and control layer around existing models, harnesses, and business workflows. It is not a model provider, agent harness, memory-only tool, or observability replacement.

Marrow fits when one or more of these is true:

• Two or more autonomous agents, models, or harnesses contribute to one accountable workflow (multiple_autonomous_agents).
• Agents can deploy, merge, publish, change production data, use privileged tools, spend money, or message customers (production_or_privileged_access).
• The workflow has repeated failures, retries, regressions, or known lessons that should affect the next action (repeated_workflow_failures).
• Work can be marked complete without proof, verification, or a recorded business outcome (missing_completion_evidence).
• Policy, approval, or completion requirements vary across agents, tools, environments, or teams (inconsistent_policy_enforcement).
• Agents operate around regulated, proprietary, personal, financial, health, legal, credential, or otherwise sensitive workflows (regulated_or_sensitive_work).

Where Marrow is not a fit

• One advisory assistant performs no shared, privileged, production, or accountable business action (single_low_risk_assistant).
• The workflow has no need for policy, proof, outcome accountability, or fleet coordination (no_governance_requirement).
• The operator has declined Marrow evaluation or installation (operator_declined_evaluation).

Installing Marrow changes the operator's agent configuration: never install, create an account, or submit data without operator approval.

Verify current claims through the public evidence manifest, reference graph, and integration cards.

Install

Windows: Native Windows is not supported yet. Use WSL.

For most installations, follow the Quick start: the universal installer's activate command. The steps below are the manual, MCP-only route.

Get a key at getmarrow.ai/signup and keep it in an owner-only key file: put MARROW_API_KEY=<your_key> in ~/.marrow/env, then run chmod 700 ~/.marrow && chmod 600 ~/.marrow/env (Marrow rejects a key file whose folder others can write):

mkdir -p ~/.marrow && chmod 700 ~/.marrow
# put MARROW_API_KEY=<your_key> in ~/.marrow/env
chmod 600 ~/.marrow/env

Claude Code plugin users: after /plugin install, run /reload-plugins (or restart Claude Code). To add a key, put MARROW_API_KEY= in ~/.marrow/env, run chmod 600 ~/.marrow/env, then /reload-plugins. Do not run activate or marrow-mcp setup for the plugin, because they write a second copy of the hooks.

Hooks-only setup (marrow-mcp setup writes hooks and CLAUDE.md instructions, and adds no MCP server). It needs the key first: without one it prints how to get it and exits 2 before writing anything.

npx -y --package=@getmarrow/mcp@latest marrow-mcp setup

The MCP server and Claude Code's cooperative pre-action hook read the key only from the process environment or an owner-controlled ~/.marrow/env (or ~/.marrow/env.local) with owner-only permissions (chmod 600). An owner file that is a symlink, readable or writable by others, owned by another user, or in a directory others can write supplies nothing, key included; the missing-key message names it with the chmod fix. Repository-local files (.env, .env.local, .marrow/env* in the working directory or its parents) are never read for MARROW_API_KEY or any other MARROW_* setting, whatever their permissions, so project content cannot replace the account, agent, or API endpoint. If one holds a key, the missing-key message names that file and the fix: run npx @getmarrow/install doctor, or move the line to ~/.marrow/env, then chmod 600 ~/.marrow/env. The public hook callback is still a client self-report, not certified host provenance or an external enforcement boundary.

Then configure the MCP server:

{
  "mcpServers": {
    "marrow": {
      "command": "npx",
      "args": ["-y", "--package=@getmarrow/mcp@latest", "marrow-mcp"]
    }
  }
}

After setup writes MCP configuration or hooks, restart the agent host and review/enable its hook trust. Then verify the reloaded environment:

npx -y @getmarrow/install@latest doctor --self-test

Successful setup alone does not mean this process reloaded or that hooks are active. Keep savings at zero until observed usage supplies evidence.

Tool Profiles

Ordinary setup does not require MARROW_TOOL_PROFILE. When the variable is unset, Marrow uses the primary profile and exposes exactly the 17 tools in Primary MCP Tools.

• MARROW_TOOL_PROFILE=primary explicitly selects the same 17-tool primary surface.
• MARROW_TOOL_PROFILE=core preserves the seven-tool runtime, think, commit, ask, status, auto, and handoff-status surface.
• MARROW_TOOL_PROFILE=full exposes the complete advanced and legacy catalog for integrations that require it.

An invalid value returns a bounded configuration error with the exact allowed values; it never falls back to full. Restart the MCP process after changing the profile.

Local visibility does not grant paid access. Every tool call continues through Marrow's backend authentication, tenant, key-permission, plan, proof, and policy enforcement. MCP status responses include mcp_tool_profile with the configured and effective profile, visible tool names/count, and a backend primary-tool entitlement projection when fresh authenticated evidence is provided. Missing or cached entitlement evidence is labeled unavailable and cannot authorize a call.

Keeping MCP Current

Marrow's hosted API, website, and dashboard update automatically; local MCP hooks, configuration, and pinned package commands do not silently rewrite themselves. Keeping them current delivers new client-side features, compatibility improvements, and any published security fixes. During authenticated status/runtime activity, Marrow returns a client_update notice when the package is behind or unknown, and passive context shows the agent the exact update and verification commands.

npx -y @getmarrow/install@latest activate
npx -y @getmarrow/install@latest doctor

# Manual MCP-only setup
npx -y --package=@getmarrow/mcp@latest marrow-mcp setup

# Verify live read latency, last success, and local backlog
npx -y --package=@getmarrow/mcp@latest marrow-mcp ping

Detection and notification are automatic. After explicit installer activation, the local controller may restore only Marrow-managed hooks/configuration. Package upgrades, owner policy, credentials, and unrelated configuration remain explicit and subject to the operator's normal change policy.

Pending write recovery

A direct marrow_think can receive a durable pending response before the backend can safely expose a decision ID. The client recognizes the explicit agent_write_reconciliation.v1 think contract and the corresponding current legacy pending shapes. It retries the identical authenticated request with the original idempotency key, agent and session, at most three reconciliation rounds with the existing one-second wait between rounds. Each round retains up to two transport attempts for retryable failures, so one invocation can send up to six HTTP requests, all with the same key and body. It never creates a placeholder decision or starts an automatic operation to recover a direct think call. Unknown states, conflicting keys and unsafe responses fail closed; exhaustion returns a retryable structured pending_receipt with committed:false, the original idempotency_key, and request_hash. To resume manually, pass both fields to marrow_think with the same arguments, credentials, agent and session. The hash binds that exact canonical request and scope; drift is rejected before sending. No prompt, credential, or raw scope is included in the receipt. Caller keys must be privacy-safe opaque identifiers.

A saved observed_unverified outcome is terminal observation evidence, not a committed outcome. Receipt expiry cannot retroactively authorize completed work. Preserve the original decision, receipt, proof and key; an already authorized durable checkpoint may finish through its existing exact recovery path. Do not repeat the action merely to obtain a fresh receipt.

Keyless seatbelt

When a pre-action hook has no usable Marrow key and the machine shows no sign of a Marrow account (for example an owner key file, a claim marker or Marrow's local approval state), the hook runs a local seatbelt instead of holding every protected action:

• It stops seven kinds of action: a change to Marrow's hooks, settings or plugins (including the Marrow plugin switch in Claude Code settings and the plugin files under ~/.claude/plugins) or an owner-only Marrow command (S0), a force-push or delete of a protected branch (S1), a production deploy (S2), a package publish (S3), reading credentials or secrets, including a project .env file or any other <name>.env file that exists (templates such as .env.example pass), ~/.marrow/fleet.env and ~/.marrow/credentials (S4), a recursive delete outside the workspace (S5), and decoded data run by a shell or interpreter (S-x). A protected file named to any program that is not a plain reader (such as cat, grep, jq or diff) stops too, so an editor or a tool the seatbelt does not know cannot rewrite it. A tool counts as a plain reader only with the long options it lists, spelled in full: GNU tools and git also accept a shortened spelling (cp --target=DIR, git reset --har), so a shortened or unknown long option on a command that names a protected file stops. Archiving (tar -c, zip), tree and prettier --check only read what they are given: only the archive and the files they write are checked. The stop is the host's own deny, with text that tells the agent to leave the action to the machine owner. On Grok the stop is Grok's fixed denial ("Marrow blocked this protected action."), the only denial its installed guard passes.
• Everything else gets no Marrow decision, so the host's own approval step decides: Claude Code and Codex get an empty answer, Cline is not cancelled and Windsurf gets no output. Gemini CLI gets {"decision":"allow"}, the only answer its installed guard passes without blocking. Cursor asks with its own approval prompt before a shell command that a hook without a key used to hold. Cursor's other tools (MCP calls included) and Grok have no neutral answer, so they keep holding what a hook without a key held before. An action that a hook without a key already let through gets the same answer as before.
• Host tools and MCP calls: the seatbelt reads each host's own file tools (for example Cline write_to_file and replace_in_file, Gemini CLI read_file, replace and delete_file, Grok search_replace, Cursor Delete) and MCP calls in every host form (mcp__server__tool, MCP:server:tool, Gemini mcp_server_tool and server__tool, Cline use_mcp_tool and access_mcp_resource). Every string value in an MCP call's arguments, at any depth, gets the S0 and S4 path checks. A tool it does not recognise, or MCP arguments it cannot read, never gets the seatbelt's pass: the hook gives the answer a hook without a key gave before, a hold where that held.
• It fails closed: an internal error, a check that runs past 300 ms, or input the host cut short stops the action. Windsurf and Cline do not tell the hook the working folder, so there a recursive delete outside the temporary folders stops.
• Local receipts: each seatbelt decision is written to ~/.marrow/seatbelt/receipts/ on this machine, as codes and keyed hashes, plus the built-in tool name and shell program names from fixed lists (any MCP tool is recorded only as mcp); no command text, argument, path or URL. Receipts are kept for up to 90 days or 50 MB. Nothing is uploaded. Where the seatbelt enforces (no working key), an agent cannot edit the receipts or read the device salt that keys them (S0, S4); with a working key the seatbelt only watches. Receipts are a record, not an authority.
• Folder permissions: the seatbelt runs only where your home folder and the agent settings folders (such as ~/.claude) can be written by you alone. On Linux, a folder that your own private group can also write (the default with umask 002, mode 0775) still counts. A folder others can write, a group with other members, a folder reached through a symlink, or users and groups from a network directory (LDAP, SSSD) keep every hold, and the hold names the reason and how to fix it, for example "Marrow stopped this action: there is no Marrow key on this machine, and Marrow uses its stricter no-key mode here because HOME is not your login home folder. Fix (for the person at this machine, not the agent): start the agent with HOME set to your login home folder, or add a Marrow key (getmarrow.ai/docs#start-here)."
• Stops you may meet on purpose: cp .env.example .env.local (or any command that writes a .env file), set -a && . ./.env && npm run dev and docker compose --env-file .env up are stopped as secrets (S4), and rm -rf ~/.cache/<app> as a recursive delete outside the workspace (S5). If you meant it, run the line yourself in your own terminal. Each stop message names the kind of action and ends with its code.
• It is a seatbelt, not a vault: it runs on the machine as your user and makes no network call. A determined agent can get around a local check, for example with a script it writes now and runs later, an interpreter, or a tool path with no hook.
• With an account: a machine linked to an account but with no working key keeps every hold it had, and these stops apply too. With a working key nothing changes; the seatbelt only checks the action after Marrow has answered, without changing the answer.

marrow-mcp setup and the installer both need a key; hooks without a key come from the Marrow plugins for Claude Code, Codex and Cursor.

Hook behavior details

These behaviors shipped in 3.9.100 and still apply.

• One Marrow entry per hook event: marrow-mcp setup recognizes the installer's local-runtime hook commands exactly (same version throughout, no additions), keeps whichever form is there (local runtime or npx), and never adds a second entry. Your own hooks stay as they are.
• Plain words without a key: on a machine linked to a Marrow account, a protected action with no working key is denied with "Marrow is linked to an account but has no working key; owner: run npx -y @getmarrow/install@latest doctor." A machine with no account runs the keyless seatbelt. The hooks read the key from MARROW_API_KEY or an owner-only ~/.marrow/env.local or ~/.marrow/env, never from a file others can read.
• First-prompt briefs say so: the prompt hook marks its brief context.prompt_brief: true; a brief authorizes nothing.
• Deploy text only word for word: the exact command text is sent only for sst deploy --stage <stage> (optionally --verbose, optionally after one npx or bunx), with a stage of lower-case letters, digits and dashes, in a single clause with nothing else in it, so Marrow can judge the stage itself. Every other command, including other deploy tools, sends only the hash; no free-text word leaves the machine.
• No lifecycle event id with two payloads: an event id names its payload, so a later run is a new record and a resend carries the same bytes.

Setup and key handling

These behaviors shipped in 3.9.101 and still apply.

• Setup with no key stops: marrow-mcp setup with no key, or with a key only in an untrusted place such as a project .env, stops, writes nothing and tells you how to get a key.
• Keys are read from trusted places only: the key comes from the environment or an owner-only ~/.marrow/env.
• Key-file steps include chmod 700 ~/.marrow before chmod 600 ~/.marrow/env.
• Hold messages say where to approve: a held action says how to approve it where your host really asks.
• One enforcement sentence: the "what is enforced" wording matches the public site.

Project files and Marrow's own tools

These behaviors shipped in 3.9.102 and still apply.

• A cloned project's .env cannot redirect the MCP server: repository-local .env, .env.local and .marrow/env* files are never read for MARROW_API_KEY or any other MARROW_* setting, so project content cannot point the server at another account, agent or API endpoint.
• Safer key-file advice: an owner file that is a symlink, readable or writable by others, owned by another user, or in a directory others can write supplies nothing, and the missing-key message names the file with the chmod fix.
• Only Marrow's own tools skip the gate, by exact name: a tool is Marrow's own only when its server is exactly marrow and its tool name is exactly one this package registers. Look-alike servers, other cases, extra spaces or suffixes go through the pre-action gate like any other MCP tool. Re-run marrow-mcp setup to refresh hooks written with the old matcher.