MCP-native spend controls: why agent tools need a payment firewall

The Model Context Protocol (MCP) is becoming the standard for how AI agents discover and call tools — from Claude Code and Cursor to open-source agent frameworks. Every MCP tool that touches money (an API key, a cloud provision, a payment endpoint) needs a spend gate that lives outside the model. Here's the architecture and the integration.

The problem: MCP tools are trust-optimistic

When an agent connects to an MCP server, it gets a list of tools. Each tool has a name, a description, and an input schema. There's no field for "this tool costs money" or "max calls per hour." The model reads the description and decides — there's no constraint layer between discovery and execution.

This is how the PocketOS DB deletion happened: an MCP tool exposed destructive capabilities, the agent's context said "perform a cleanup," and 9 seconds later the production database was gone. The tool was correctly described. The guardrail wasn't.

The sipi.bot MCP integration

sipi.bot registers as an MCP server — just like any other tool provider — but the tool it exposes is the firewall evaluation endpoint. An agent calls spend_guard before any spend-call. The tool returns APPROVED, BLOCKED, or FLAGGED. On BLOCKED, the agent gets a readable reason and stops.

The beauty of MCP-native: any agent framework that speaks MCP (Claude Code, Cursor, LangChain via MCP adapter, CrewAI) gets the firewall as a standard tool — no SDK, no special integration. Connect the MCP server, add the tool to the agent's tool list, and every spend-call is gated.

We support MCP natively — see the framework integrations directory for LangChain, CrewAI, OpenAI Agents SDK, Vercel AI SDK, and raw HTTP/CLI. Every integration wraps the same firewall endpoint, and the eval gym (53/53) validates them all.