Interceptors Working Group Meeting - Sep 29th, 2026 #3401

Repo: [modelcontextprotocol/experimental-ext-interceptors](https://github.com/modelcontextprotocol/experimental-ext-interceptors)

Discord: [#interceptors-wg](https://discord.com/channels/1358869848138059966/1474446054291279933)

Antitrust Reminder

At the start of each meeting, we remind all participants that we must comply with the [MCP Antitrust Policy](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/ANTITRUST.md). 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

Agenda

• Action items from the last meeting, including feedback from the impromptu interceptors discussion in Amsterdam
• See also follow up items from here: Interceptors Working Group Meeting - August 18th, 2026 #3266 (some are still WIP as of today)

Attendees

(from transcript speakers)

• Kurt Degiorgio
• Ola Hungerford
• Clare Liguori
• Ukjae Jeong
• Monika Campbell

Discussion

Amsterdam feedback (relayed by Clare)

• Two points came out of the impromptu Amsterdam meeting:
  1. Scope interceptors to MCP events only. LLM completions are not very standardized, so standardizing a completion event type would be a big challenge and does not make much sense in an MCP extension.
  2. Reconsider whether list-based interceptor discovery is needed at all, versus an invoke-interceptor API where the chain of interceptors inside a server is a server implementation detail from the client's point of view.
• Attribution from Amsterdam: Kurtis Van Gent was most concerned about single-server chaining; DSP was most concerned about keeping it MCP-specific. Sambhav was also present.

Scoping to MCP events

• Agreed: interceptors are tied to MCP JSON-RPC. The event set does not need to be hardcoded; any MCP JSON-RPC message qualifies, including messages from extensions.
• Kurt: agrees with not specifically listing completions; this makes sense and should reduce confusion.

Discovery vs. invoke-only, and chaining

• Kurt: dropping list-based discovery is a larger change to the current SEP, which treats interceptors as MCP primitives that can be discovered and invoked.
• Clare: the Amsterdam framing is like Kubernetes admission webhooks. A client can still have a list of endpoints and call multiple servers, with validating checks in parallel and mutating checks sequential. How many checks a given server runs, and which ones, is server implementation specific, which takes that complexity away from the client. The concern was about sub-server-level chaining; the client calling multiple interceptors in a specific order still makes sense.
• Kurt: the original thinking was an ecosystem of interceptors where calling and chaining them is the caller's responsibility. In an enterprise deployment the client is itself a server, calling a set of interceptors in a specific way. Confirmed with Clare that the client decides the order of servers it calls. Kurt: the SEP can be framed that way.
• Kurt asked to prioritize cleaning up the chaining references in the SEP, since they are confusing a lot of people.

Open PRs on the working group repo

• Ola: a couple of PRs are still open on the WG repo. Proposal: merge those, then create new changes on top.

Custom events, extensions, and hooks

• Monika asked whether custom events remain a supported use case. Example: DevX use cases triggered by an event in an AI tool like Claude, using interceptors to scan payloads sent to LLMs. This does not involve calling an MCP server.
• Kurt: the official spec targets MCP events; anything outside that has to fall under the extension framework. That doesn't mean you can't intercept anything else.
• Clare: in Amsterdam, even as an official extension the preference was to restrict it to MCP. DSP's suggestion was that LLM completions sound more like a standardized hook for agent frameworks to call, and MCP may not be the right place for that use case. The agent plugins group, which Clare is part of, is working on standardized hooks including pre/post tool use and completions.
• Ola and Clare on the distinction: hooks are something like a bash script that runs alongside the harness; an agent plugin runs locally. Interceptors can be deployed remotely.

Decisions

• Interceptors are scoped to MCP JSON-RPC events, including extension messages (Kurt and Clare; no objections).
• Merge the currently open WG repo PRs first, then build the next changes on top.
• Discovery model (list-based vs. invoke-only) is deferred until the group hears the full Amsterdam conclusion.

Action Items

• Group: Merge the open PRs on the working group repo, including removing chaining references from the SEP (changes everyone is already on board with)
• Group: confirm with Sambhav what the Amsterdam discussion concluded, then adapt the SEP accordingly