Content is user-generated and unverified.

MCP Defender: Request Interception Architecture

Overview

MCP Defender is a security proxy that sits between MCP clients (like Claude Desktop, Cursor) and MCP servers to intercept, analyze, and filter tool calls and responses. It operates at the application layer of the MCP protocol, not at the network level.

Local Request Interception: For local MCP servers, Defender acts as a process wrapper (STDIO) or local proxy (HTTP-SSE), spawning or proxying to servers running on the same machine.

Remote Request Interception: For remote MCP servers, Defender operates as a reverse proxy, intercepting HTTP-SSE connections destined for external endpoints and forwarding them after security verification.

Both approaches require explicit client configuration changes to route requests through MCP Defender rather than directly to the target servers.

Core Architecture

[MCP Client] ←→ [MCP Defender] ←→ [MCP Server]
                      ↓
              [Security Engine]
              [Policy Enforcement]
              [Audit Logging]

Transport-Specific Interception

1. HTTP-SSE Transport Interception

Architecture Pattern: Reverse Proxy

Client → Defender Proxy (Port 28173) → Target Server
   ↓           ↓                            ↓
HTTP/SSE    Intercept &                 Forward to
requests    Security Filter             original server

Implementation:

  • Express server listening on configurable port (default 28173)
  • SSE Connection Proxying: Maintains persistent connections to both client and server
  • Message Endpoint Rewriting: Redirects client POST requests through proxy
  • Request/Response Matching: Uses request IDs to correlate tool calls with responses
  • Bi-directional Filtering: Inspects both outbound tool calls and inbound responses

Handles Both:

  • Remote servers: Proxies to external HTTP-SSE endpoints
  • Local servers: Proxies to locally-spawned HTTP servers

2. STDIO Transport Interception

Architecture Pattern: Process Wrapper

Client → Defender CLI → Target Server Process
   ↓         ↓                ↓
STDIO    JSON-RPC         Child Process
        Stream Parser      STDIO pipes

Implementation:

  • CLI wrapper that spawns target MCP server as child process
  • Stream interception using ReadBuffer for JSON-RPC message parsing
  • Bidirectional message processing: Intercepts both stdin (client→server) and stdout (server→client)
  • HTTP API integration: Sends intercepted messages to security verification service

Security Verification Flow

1. Tool Call Intercepted
        ↓
2. Extract tool name, arguments, context
        ↓
3. Send to verification engine via HTTP API
        ↓
4. Policy evaluation against security signatures
        ↓
5. Decision: ALLOW | BLOCK | MODIFY
        ↓
6. Forward original/modified request OR return error
        ↓
7. Intercept and verify response (if call was allowed)
        ↓
8. Forward verified response OR block malicious content

Key Technical Components

Request Tracking

  • Pending calls map: Tracks tool calls by unique key {serverName}:{requestId}
  • Call lifecycle management: Associates requests with responses across async operations
  • Timeout handling: Automatic cleanup of stale pending calls

Transport Abstraction

  • Common verification API: Same security engine for both transports
  • Transport-specific handlers: HTTP-SSE and STDIO handlers implement common interface
  • Protocol translation: Converts between transport formats and internal representation

Multi-tenancy Support

  • App/Server isolation: Supports multiple MCP clients and servers simultaneously
  • Namespace routing: URL pattern /{appName}/{serverName}/endpoint
  • Per-instance policies: Granular security controls per client/server combination

Deployment Models

Transparent Proxy Mode (HTTP-SSE)

  • Client connects to MCP Defender instead of original server
  • Defender forwards to actual server transparently
  • No modification of server required

Wrapper Mode (STDIO)

  • Client configured to spawn MCP Defender CLI
  • Defender CLI spawns and wraps actual server process
  • Server runs normally, unaware of interception

Tool Discovery Integration

  • Automatic tool enumeration: Sends tools/list requests to discover available tools
  • Dynamic policy application: Security policies applied based on discovered tool capabilities
  • Registry synchronization: Maintains up-to-date tool inventory for policy enforcement

Configuration Requirements

Both transports require explicit configuration changes:

  • Clients must be configured to route through MCP Defender
  • Target server information must be provided to Defender
  • Environment variables used for server resolution and routing

Design Philosophy:

  • Explicit security: Users must consciously opt-in to protection
  • No invisible interception: Clear visibility into what's being filtered
  • Easy toggle: Simple to enable/disable protection per server

Security Benefits

  • Pre-execution filtering: Blocks malicious tool calls before execution
  • Response sanitization: Filters sensitive data in tool responses
  • Audit trail: Complete logging of all intercepted operations
  • Policy enforcement: Consistent security rules across all MCP interactions
  • Zero-trust model: Every tool call and response is verified
Content is user-generated and unverified.
    MCP Defender: Request Interception Architecture | Claude