Surfit Ships MCP — Action Governance for Claude Desktop, Claude Code, and Any Compatible Client

Why MCP matters

Model Context Protocol is the standard Anthropic introduced for connecting agents to external tools. In the months since it launched, MCP has become the default integration surface for Claude Desktop, Claude Code, Cursor, Cline, and a growing list of clients. If you're running a Claude-based agent that needs to take real actions on real systems, MCP is increasingly how those actions get exposed.

That makes MCP the right place for governance to enter the picture. If every tool the agent uses comes through MCP, then a single MCP server placed correctly can govern every action that agent ever takes — across every system, with no per-system integration work for the developer.

That's what we shipped today.

One config block

For Claude Desktop, the entire integration is this:

{
  "mcpServers": {
    "surfit": {
      "url": "https://mcp.surfit.ai/mcp",
      "headers": {
        "Authorization": "Bearer sk_surfit_YOUR_KEY"
      }
    }
  }
}

Save the file. Restart Claude. Seven Surfit tools appear in the agent's toolbox: surfit_x_post, surfit_slack_send, surfit_github_action, surfit_aws_action, surfit_gmail_send, surfit_notion_action, surfit_outlook_send. The agent uses these instead of hitting Slack's API or GitHub's API directly. Every call is scored by the Wave engine, then either auto-executed or held for approval based on real-time risk.

The configurations for Claude Code, Cursor, and Cline are essentially the same. The full setup guide is here.

What changes architecturally

The thing that changes when you add Surfit to your MCP config isn't just that there's a governance layer in front of your agent's actions. The thing that changes is where the production credentials live.

Before Surfit: the agent's runtime holds the Slack token, the GitHub PAT, the AWS keys. When the agent decides to act, it uses those credentials directly. If the agent is wrong, confused, prompt-injected, or compromised, the credentials are right there — and so is everything they unlock.

After Surfit: the agent's runtime holds only a Surfit API key. The Slack token, GitHub PAT, and AWS keys live in Surfit's encrypted credential store. The agent proposes an action through Surfit; Surfit decides whether it should run; Surfit executes using credentials the agent never sees.

That separation is the whole governance model. The Wave engine is what makes the decisions intelligent — it scores every action 1 to 5 based on system, content, destination, agent history, and cross-system patterns — but the architectural foundation is the credential split. The agent literally cannot bypass Surfit, because the only path to a live system runs through it.

What Wave evaluation looks like in a Claude session

When Claude calls a Surfit tool through MCP, the response comes back as plain text the agent can reason about. Two examples from a real session:

Action executed. Surfit Wave 2. ID: x-12790e2f. (x / post_tweet)

Wave 2 is standard risk — the action ran, it's logged, the audit trail is preserved. Claude sees that it succeeded and continues with whatever it was doing.

Action held for human approval. Surfit Wave 5. ID: gmail-21d6667b.
Approver will review and either approve or reject.
You will not see the action complete until it is approved.

Wave 5 is critical risk. The action did not execute. An approver gets notified through the Surfit dashboard and can approve, reject, or modify before anything reaches Gmail. Claude sees clearly that the action is pending — it knows not to retry, not to assume it succeeded, not to chain another action that depends on it.

This is the kind of feedback an agent actually needs to behave correctly under governance. Most existing approaches either let the agent do whatever it wants or block it silently with no useful signal. Surfit gives the agent a clear, structured response it can reason about.

What this enables

Three things that weren't really possible before today:

Governed agent development on a personal laptop. Any developer using Claude Code or Cursor to build an agent can now develop against governed actions on day one. They don't need to wire up custom tool handlers. They don't need to integrate an SDK. The governance layer is just there, available to any agent they build.

Claude Desktop as a safe production-action surface. Claude Desktop is increasingly used not just for chat but for taking real actions through MCP. Connecting it to Surfit means a Claude Desktop user can let the agent take operationally important actions — sending emails, posting to Slack, modifying infrastructure — with the same kind of governance an enterprise would expect.

Multi-vendor agent governance through one layer. Surfit's MCP server doesn't care which model is on the other end. It works with Claude, but also with any other MCP-compatible runtime. As more inference providers ship MCP support — and they will — Surfit becomes the cross-vendor governance layer that sits above all of them.

What's next

Today's release is the HTTP-transport version of the Surfit MCP server. Coming soon: scoped multi-tenant credential injection so individual agents can have per-task credentials issued at runtime, additional system integrations beyond the current seven, and direct integrations into popular agent frameworks (LangChain, CrewAI, AutoGen) for teams that aren't on the Claude family.

If you're building an AI agent that takes real actions on real systems, this is the layer you should be testing against. Setup takes about 60 seconds, and the first month is on us.

Connect Surfit to your Claude-based agent in 60 seconds.

Read the setup guide

Most agent infrastructure pitches itself on what the agent can do. Surfit pitches itself on what the agent can no longer do without you knowing about it. Different problem. Different layer. Live today, on your Claude.