Repo: modelcontextprotocol/experimental-ext-interceptors Discord: #interceptors-wg

Antitrust Reminder

At the start of each meeting, we remind all participants that we must comply with the MCP Antitrust Policy. Discussion must remain focused on technical standards and avoid:

Competitively sensitive information (pricing, customer lists, market strategies) Non-technical business discussions
Any coordination that could be construed as anti-competitive

Interceptor Working Group Meeting - August 18th, 2026

MCP Event page: https://meet.modelcontextprotocol.io/2026/08/mcp-interceptors-working-group-gG4oM3MVyTYO

Agenda

• Tentative WG roadmap (Peder)
• Core maintainer questions on the SEP (Clare)

Attendees

• Kurt Degiorgio, Clare Liguori, Ola Hungerford, Ukjae Jeong, Sambhav Kothari, Peder Holdgaard Pedersen, Monika Campbell

Discussion

• Core maintainer engagement. First meeting with a core maintainer (Clare) attending. Following the wider roadmap discussion, WG leads are expected to bring regular updates to the core maintainers. Peder, Ola, and Sambhav will present the problem statement, the work done so far, and adoption to the core maintainers.
• Roadmap. Peder drafted a six-item roadmap from the open work items (feedback was due before the 18th). Agreed changes: move the end-to-end demo and reference client integrations (item 5) ahead of conformance testing and multi-language support; add verified adoption to the graduation criteria; fold a problem statement into item 1. Link to Discord thread
• Where interceptors run. It was not clear from the SEP what hosts the interceptors/list and interceptor/invoke methods, what calls them, or why they exist instead of client/server config. Answer: an interceptor is a standalone MCP server, at the same level as tools, invoked over an MCP transport (stdio or Streamable HTTP). Configuration lives on the client or server side; execution is always out of process. No in-process interceptor use case has come up; none of Bloomberg's run in process. The SEP's "first-party / in-process" wording and the sequence diagrams (which read as the client calling itself) say otherwise and will be fixed.
• Interceptor servers vs tool servers. Consensus that a server should not host both tools and interceptors. The interceptor server sits beside the proxy, gateway, or client that invokes it; the proxy talks directly to the tool servers. The SEP should say this (SHOULD NOT co-host) and describe the expected deployment architecture.
• Configuration. The SEP puts configSchema in the list response and config on every invoke; the reason is statelessness. Both models should work: a server started with static config, or config passed per call. The server declares which settings are configurable and their defaults; the client may override; a server may expose no settings at all. Clare raised cases where per-invoke config fits poorly: expensive setup that needs warm-up or caching, and platform teams that want a static configuration with only a few client-facing knobs.
• Enterprise enforcement. Clare's example scenario: a security team configures a guardrail interceptor once and requires every MCP server and client in the company to invoke it without changing the configuration. Two separate problems: which knobs are exposed, which the interceptor provider controls; and universal application, which the platform owner achieves by injecting the interceptor at a sidecar, gateway, or proxy in front of every server so that end clients cannot opt out. Enforcement is a deployment property rather than a protocol property; the SEP should describe the pattern.
• Identity. What identity does a proxy use to call a remote interceptor server? For a third-party moderation service, a service credential configured in the proxy. Clare's mortgage-loan-processor case needs the end user's identity for authorization limits. Bloomberg preserves dual identities (workload plus on-behalf-of user). This is a general MCP authorization problem, probably representable with OAuth claims or grant types and the enterprise auth work, and one reason the SEP reuses MCP rather than a separate protocol.
• SEP structure. Sambhav proposed removing implementation detail (JSON-RPC shapes, orchestration) from the SEP into a reference-implementation document so the SEP reads as concepts first. Clare asked for a Rationale entry on the in-process vs out-of-process trade-off (extra process, stdio-plus-stdio for local clients, network time, versus portability), and for real-world deployment scenarios enumerated: client, proxy, server, interceptor server, how they communicate, and the transports. Sambhav noted the SEP has diverged from the current implementations.
• LLM message event type. Intercepting LLM calls is a common interceptor use case (modifying context, e.g. fact injection into the system prompt) and the point where the SEP goes beyond MCP primitives; the event-type set is open by design. Harnesses do not need to change: their existing hooks (a shell command returning output and an exit code) can call interceptor/invoke through an adapter, which also allows the logic to run in infrastructure rather than on employee machines. Many enterprises in the wild handle PII on LLM traffic at an LLM gateway, in process and vendor-specific, and the interface is standardizing on open responses; ideally a gateway like LiteLLM would call out to an MCP interceptor server. Sambhav: gateways cover enterprise-wide policies; agent-specific mutators need a client-side hook when you do not control the harness. Clare wants this on the core maintainer calendar and discussed in Amsterdam; no consensus yet.

Action Items

• Peder, Ola, Sambhav: update the roadmap (reorder item 5, adoption graduation criterion, problem statement) and present problem statement, progress, and adoption to the core maintainers
• Sambhav: move implementation detail out of the SEP into a reference-implementation document
• Sambhav: add deployment architecture and the interceptor-server vs tool-server separation to the SEP
• Sambhav: replace the sequence diagrams
• Clare: Rationale entry on in-process vs out-of-process trade-offs
• Group: enumerate real-world deployment scenarios (client, proxy, server, interceptor server, transports)
• Group: get on the core maintainer calendar; prepare Amsterdam material
• Group: LLM message event type discussion with the core maintainers

Post-meeting: out-of-process wording, the SHOULD NOT co-host rule, and config default semantics are in experimental-ext-interceptors#43; chain removal (7/23 action) is in #44.