How the Stow MCP Server Works: The Architecture Behind AI Permissions
When Claude makes a request through Stow, it doesn't talk directly to Gmail. It talks to a purpose-built MCP server that enforces a policy stack before a single byte hits the target API.
Model Context Protocol (MCP) is the interface that lets AI agents call external tools. When Claude uses MCP to send an email or read a GitHub issue, it's making a structured tool call to a server that handles the actual API interaction. Stow's MCP server is the policy and audit layer that sits in that position — every Claude tool call routes through it before touching your services.
The Full Request Lifecycle
When Claude makes a tool call through Stow, here's what happens from the moment the request arrives to the moment it completes:
MCP Tool Call Received
Claude sends a structured JSON tool call to the Stow MCP endpoint. The call includes the tool name (e.g., gmail-send-message) and its parameters.
Authentication Verified
The request's Bearer token (OAuth) or agent credentials (SSE) are verified against the JWKS endpoint using RS256/ES256 asymmetric key pairs. Invalid tokens are rejected immediately.
Risk Engine Evaluation
The Risk Engine calculates a score based on action severity, network fingerprint comparison against the Security Baseline, and request pattern analysis.
Policy Engine Check
The Policy Engine looks up the specific operation against your permission configuration. Blocked operations are rejected. Approval-required operations are queued.
HttpBroker Execution
If both engines pass, the HttpBroker retrieves your service's OAuth token (from encrypted storage), constructs the target API request, and executes it.
Response Sanitization
The service API response is received, stripped of payload content (Zero-Retention policy), and metadata is extracted.
ExecutionRequest Committed
The completed request — status, risk score, agent, tool, timestamp, network signals — is written to the database. Payload content is not written.
Response Returned
The sanitized result is returned to Claude. The AI receives what it needs to continue the conversation — it doesn't receive any credentials or raw API tokens.
Two Authentication Paths
Stow supports two authentication mechanisms depending on the agent type:
OAuth Bearer (Claude Desktop, ChatGPT)
The agent authenticates via a standard OAuth flow. The user authorizes the connection in their browser, and Stow issues a Bearer token. No credentials are handled manually. The Claude Desktop connector URL is just https://mcp.stowprotect.com — OAuth handles the rest.
SSE with Agent Credentials (Cursor)
The agent connects via Server-Sent Events using an agent_id and agent_secret embedded in the SSE URL. Credentials are generated in the Stow dashboard and pasted into the Cursor MCP config. The secret is used to verify the connection and establish the Security Baseline.
The HttpBroker: No Credentials Leave the Server
The HttpBroker is the component that actually makes the API call to your connected service. When Claude requests to read your Gmail, the HttpBroker:
- Retrieves your encrypted Google OAuth token from the Stow credential store
- Constructs the appropriate Gmail API request
- Makes the request server-side, with your token never exposed to Claude
- Receives the response and passes it through Zero-Retention sanitization
- Returns only the sanitized data to the MCP layer
This means Claude never has direct access to your service credentials. It can use the capabilities of your connected services — read an email, post a message — but it cannot extract or reuse the tokens that enable those capabilities.
Why MCP as the Interface
MCP is an open standard, which means Stow works with any MCP-compatible AI agent — Claude, Cursor, ChatGPT, and any future agent that adopts the protocol. The tool definitions (what operations are available, what parameters they accept) are served by Stow and consumed by the agent, which means:
- The agent discovers capabilities dynamically — no hardcoded tool lists
- Adding a new service integration in Stow makes it immediately available to all connected agents
- Permission changes take effect immediately — no agent restart or reconfiguration required
What Happens During an Approval Hold
When the Policy Engine determines a request requires approval, the MCP server returns a holding response to the agent — a structured response indicating the request is pending. The agent knows the operation is in flight but not yet complete.
The request is stored in the approval queue. When you approve it through the Stow dashboard (or via an alert notification link), the HttpBroker executes the operation and the Activity Log entry is updated from pending_approval to executed. The agent receives the result asynchronously.
Stow Security Team
April 19, 2026