Skip to main content

​
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.
  • 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

​
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