MCP Connector

TameFlare includes a dedicated MCP connector that parses JSON-RPC 2.0 tools/call messages into structured actions. This gives you per-tool permissions, risk scoring, and structured audit logs for all MCP (Model Context Protocol) traffic.

How it works

MCP uses JSON-RPC 2.0 over two transports:

Production MCP deployments use Streamable HTTP. TameFlare's MCP connector intercepts these requests, parses the JSON-RPC payload, and maps each message to a structured action type.

Action types

The MCP connector parses JSON-RPC messages into three categories:

Tool calls (tools/call)

The most security-relevant MCP message. The connector extracts the tool name from params.name and maps it to mcp.tools.<tool_name>.

Tool discovery (tools/list)

Discovery requests are parsed as mcp.tools.list. These are low risk - the agent is asking what tools are available, not executing one.

Other JSON-RPC methods

Any other JSON-RPC method (e.g., initialize, resources/read, prompts/get) is parsed as mcp.rpc.<method>.

Risk scoring

The MCP connector uses heuristic risk scoring based on tool name patterns:

Risk levels feed into policy evaluation. You can write policies that require approval for high-risk tool calls while allowing low-risk reads.

Setup

1. Add an MCP connector

In the dashboard gateway wizard, add an MCP connector:

• Set the target domains (e.g., mcp-server.example.com)
• Paste the MCP server auth token into the credential vault

All POST requests to these domains with Content-Type: application/json containing JSON-RPC 2.0 payloads are parsed by the MCP connector.

2. Set permissions

In the gateway wizard's Access Rules step, configure per-tool permissions:

• Allow all tool calls: mcp.tools.* → Allow
• Block destructive tools: mcp.tools.delete_* → Deny
• Require approval for deployment: mcp.tools.deploy_* → Require Approval
• Allow discovery: mcp.tools.list → Allow

3. Run your agent

tf login
tf init --list
tf run -- python mcp_agent.py

All MCP Streamable HTTP traffic is now intercepted, parsed into structured actions, and enforced against your permissions.

What MCP traffic looks like

A tools/call request on the wire:

POST /mcp HTTP/1.1
Content-Type: application/json
Accept: application/json, text/event-stream
 
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "create_pull_request",
    "arguments": {
      "repo": "acme/backend",
      "title": "Fix auth bug",
      "head": "fix-auth",
      "base": "main"
    }
  }
}

The MCP connector:

1. Detects the JSON-RPC 2.0 payload
2. Extracts method → tools/call and params.name → create_pull_request
3. Maps to action type mcp.tools.create_pull_request
4. Scores risk as medium (contains "create")
5. Buffers the request body and restores it for downstream forwarding (no data loss)
6. Checks permissions for this gateway + connector + action
7. Injects credentials from the vault if allowed
8. Logs the structured action in the traffic log

Permission patterns

The wildcard matching system works with MCP action types:

Example: governed MCP workflow

1. Create a gateway in the dashboard with an MCP connector for github-mcp.internal.com
2. Set access rules:
   • mcp.tools.read_* → Allow
   • mcp.tools.list_* → Allow
   • mcp.tools.search_* → Allow
   • mcp.tools.create_* → Require Approval
   • mcp.tools.delete_* → Deny
   • mcp.tools.list → Allow
3. Run the agent:

tf init --list    # Select the gateway
tf run -- python agent.py

Traffic log output:

14:32:01 | code-agent | mcp.tools.list          | ALLOW | 12ms
14:32:02 | code-agent | mcp.tools.read_file     | ALLOW | 45ms
14:32:04 | code-agent | mcp.tools.create_issue  | HOLD  | waiting...
14:32:18 | code-agent | mcp.tools.create_issue  | ALLOW | 89ms (approved)
14:32:20 | code-agent | mcp.tools.delete_branch | DENY  | 1ms

Capabilities

FAQ

How is this different from the generic HTTP connector?

The generic connector parses actions by HTTP method only (generic.post, generic.get). The MCP connector parses the JSON-RPC payload to extract the tool name, giving you mcp.tools.create_pull_request instead of generic.post. This enables per-tool permissions and meaningful audit logs.

What about stdio-based MCP servers?

stdio is process-level IPC (stdin/stdout), not network traffic. TameFlare's proxy cannot intercept it. For production MCP deployments, use Streamable HTTP transport - it's the recommended production transport and is fully governed by TameFlare.

Can I use TameFlare with Claude Desktop / Cursor MCP?

If your MCP server uses Streamable HTTP transport and your agent routes through tf run, yes. If the MCP connection is stdio-only (local subprocess), TameFlare cannot intercept it. Many MCP servers support both transports - configure yours to use Streamable HTTP for production.

Does the connector handle SSE responses?

Yes. MCP servers can respond with Server-Sent Events for streaming. TameFlare tunnels SSE responses transparently - the enforcement happens on the inbound request, not the response stream.

What happens if the request body isn't valid JSON-RPC?

Non-JSON-RPC requests to MCP connector domains fall through to a generic action type (mcp.rpc.unknown). The request is still logged and subject to permissions.

Next steps

• Connectors - all 8 built-in connectors
• Writing Policies - create rules for MCP tool calls
• Integration Guide - connecting your agent to TameFlare
• Kill Switch - emergency stop for MCP traffic