Interceptors Charter

​

Group Type

Working Group

​

Mission Statement

The Interceptors Working Group exists to standardize how context operations are intercepted, validated, and transformed at key points in the agentic lifecycle. This covers MCP-defined operations such as tool invocations, resource access, prompt handling, sampling, and elicitation, as well as any other operation that shapes agent context — including LLM completions and custom application-specific workflows. The ecosystem is developing a sprawling landscape of sidecars, proxies, and gateways for cross-cutting concerns that are largely non-reusable and non-interoperable, creating an M × N integration problem. The WG will produce specification extensions and reference implementations that define interceptors as a new MCP primitive with two types — validators (inspect and return pass/fail decisions) and mutators (transform context payloads) — discoverable and invocable through MCP’s existing JSON-RPC patterns across deployment models including in-process, sidecar, and remote service.

​

Scope

​

In Scope

• Specification Work: SEPs defining the interceptor primitive — validator and mutator types, lifecycle event hooks for MCP operations (tool calls, resource reads, prompt gets, sampling, elicitation) and extensible to non-MCP context operations (LLM completions, custom workflows), trust-boundary-aware execution model, priority-based chain ordering, and audit mode semantics.
• Reference Implementations: Multi-language SDK libraries for building interceptors, sample interceptors (PII redaction, schema validation, audit logging), a common interceptor sidecar/proxy runtime, and a CLI client for interceptor invocation and testing.
• Cross-Cutting Concerns: Transport-level interception points, gateway-based deployment patterns, and interplay with routing and policy layers (see Related Groups).
• Documentation: Specification sections covering interceptor authoring, deployment models (in-process, sidecar, remote service), chain configuration, and migration guidance from ad-hoc middleware approaches.

​

Out of Scope

• Client-specific hook implementation details (e.g., Claude Code’s internal hook execution engine) — the WG standardizes the protocol-level interface, not host internals.
• Transport-layer wire format or session model changes (owned by the Transports WG).
• General-purpose middleware or proxy infrastructure beyond what the MCP protocol requires.

​

Related Groups

• Transports WG — interceptors operate on MCP message flows whose delivery behavior depends on the transport; coordination needed on transport-level interception points.
• Gateways IG — gateways are a key deployment model for interceptors; coordination needed on gateway-based interceptor patterns and shared concerns around routing, policy, and observability.

​

Leadership

​

Authority & Decision Rights

​

Operations

​

Resources

• Experimental extension repository: modelcontextprotocol/experimental-ext-interceptors
• Motivation: SEP-1763

​

Deliverables & Success Metrics

​

Active Work Items

​

Success Criteria

• An accepted SEP defining the interceptor primitive (validators, mutators), lifecycle event hooks, and trust-boundary-aware chain execution.
• Reference implementations in at least two Tier-1 SDKs (Go, C#).
• A common interceptor sidecar runtime enabling platform teams to deploy interceptors without modifying individual MCP servers.
• CLI tooling for interceptor invocation and testing.
• Demonstrated interoperability across deployment models (in-process, sidecar, remote service).

​

Changelog