MCP Proxy
How SatGate proxies MCP tool calls — session management, upstream routing, and tool discovery.
What is the MCP Proxy?
The MCP Proxy is SatGate's core component for AI agent governance. It speaks the Model Context Protocol (MCP) — the same protocol that Cursor, Claude Code, and other AI tools use to discover and call tools.
Your agent connects to SatGate instead of directly to your tool servers. SatGate authenticates the agent, discovers tools from upstream servers, and proxies every tool call — adding cost tracking, budget enforcement, and audit logging along the way.
Request flow
Agent (Cursor) │ ├─ SSE Connect ──→ SatGate MCP Proxy │ │ │ ├─ Validate macaroon token │ ├─ Extract tenant_id caveat │ ├─ Load tenant upstreams (cached 60s) │ ├─ Connect to upstreams (parallel) │ └─ Discover tools from all upstreams │ ├─ tools/list ───→ Return merged tool list │ (all upstreams + built-in ping) │ ├─ tools/call ───→ Route to correct upstream │ │ │ ├─ Check budget (if enforcement enabled) │ ├─ Forward call to upstream │ ├─ Deduct credits from budget │ ├─ Publish event to event pipeline │ └─ Return result to agent │ └─ keepalive ────→ Refresh session TTL (every 15s)
Session management
Each agent connection creates an SSE session. Sessions are tracked and refreshed by keepalive events. The MCP Monitor on the dashboard shows active sessions in real-time.
Session lifecycle events (session_connect, session_close, session_keepalive) are published to the event pipeline for the dashboard to consume.
Multi-upstream routing
Tenants can have multiple upstream MCP servers. The proxy connects to all of them in parallel for fast tool discovery. Upstream configs are hot-reloaded — add or remove upstreams without restarting.
When an agent calls a tool, the proxy routes the call to whichever upstream advertised that tool. If an upstream goes down, the proxy auto-reconnects with exponential backoff.
Built-in tools
Every SatGate proxy includes a ping tool — a zero-cost health check that agents can call to verify their connection is working. It requires no upstream and always returns immediately.
Event pipeline
Every significant event is published to the event pipeline:
tool_call— agent called a tool (name, cost, duration)budget_spend— credits deducted from budgetbudget_exhausted— budget hit zeroauth_failure— invalid or expired tokensession_connect/session_close— session lifecycle
The enterprise gateway subscribes to these events and pushes them to dashboard clients via WebSocket.
Limit what a tool can do
A token can allow a tool by name. Some MCP servers put their whole API behind one tool, so allowing the tool also allows every write. A limit narrows a tool by its arguments: the call goes through only if its arguments match a shape you allowed. Anything else is refused before it reaches the upstream, and nothing is charged.
Example: the Wix MCP tool CallWixSiteAPI takes a method and a url. When you pick the tool in the agent-token form, choose the Read only limit. The token then allows:
GETto an address on www.wixapis.comPOSTto a www.wixapis.com address ending in/query,/searchor/count(these read)
A DELETE, a PATCH, or a POST anywhere else gets a TOOL_ARGUMENT_DENIED refusal that names the tool and the field (method or url). It never repeats the value the agent sent.
Rules you can write: a field equals one of a list of strings, a number is at most (or at least) a limit, a URL is on a host and a path, or a field is absent. A holder who delegates a token can only add limits; every limit on a tool must pass, so a child never gets more than its parent. A limit only applies to the tool it names. ExecuteWixAPI and SearchWixAPISpec run scripts that can chain any call, so the Wix read-only limit leaves them out of the key altogether. The Robinhood order cap allows limit orders up to a share count at up to a price a share, or market orders up to a dollar amount. Check what a preset allows before you rely on it: it is a list of calls, not a promise about what the upstream does with them.