Mirror of https://github.com/modelcontextprotocol/experimental-ext-interceptors — Status: Experimental. This repository provides a multi-language reference implementation of the proposed interceptor extension for the Model Context Protocol (MCP), as descr
  • C# 73.8%
  • Go 25.7%
  • TypeScript 0.2%
  • Python 0.2%
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Peder Holdgaard Pedersen 28ada74189
C# SDK: multi-server interceptor chain orchestration per SEP (#18)
Addresses the third item of #15 ("Chain orchestrator only supports one
MCP server").

> **Stacked on #17** — this PR targets that branch because it builds on
the per-phase `PriorityHint` resolution introduced there. After #17
merges, the base will be switched to `main` (or it can be retargeted now
and rebased).

## What changed

The SEP's chain execution pattern requires: discover via
`interceptors/list` on one or more servers → merge & sort all
interceptors into a single chain by `priorityHint` (ascending,
alphabetical tie-break) → invoke each interceptor on the server that
hosts it (mutations sequential with payload chaining, validations
parallel) → aggregate one result. The SDK previously ran each client's
entire chain sequentially, so a `-1000` mutation on server 2 ran after a
`+1000` mutation on server 1, and each server's validations only saw its
own server's mutations.

- **Orchestrator** (`InterceptorChainOrchestrator`, internal): now
operates on chain entries — descriptor + invoker routing to its host —
mirroring the SEP's `ChainEntry`, with one global sort across all
filtered entries. The stable sort preserves caller-supplied server order
for exact ties.
- **New public API** (`InterceptorChain` / `InterceptorChainEntry`):
`DiscoverAsync` lists from every server in parallel (fail-closed: any
list failure throws rather than silently dropping a server's
interceptors), instance `ExecuteAsync` runs prebuilt entries (a future
caching seam), and a one-shot static `ExecuteAsync(servers, params)`
does discover + execute.
- **`InterceptorChainRunner`** (used by the gateway and
`InterceptingMcpClient`): one merged chain instead of the per-client
sequential loop. The single-client `client.ExecuteChainAsync(...)`
extension keeps its signature and delegates to the same path (still 1
list + N invokes).
- Duplicate interceptor names across servers are not deduplicated — each
entry invokes on its own host (results may share an `InterceptorName`;
documented).

## Behavior changes for multi-client gateways

- Interceptors from all servers form one globally-ordered chain
(previously server 1's full chain ran before server 2's).
- Validations from all servers run as one parallel batch against the
payload after **all** mutations.
- Sinks run once per phase for the merged chain (previously once per
client).
- `TimeoutMs` bounds the whole merged chain, not each per-client
sub-chain.
- Any server's `interceptors/list` failure fails the chain up-front
(fail-closed).
- Cost per phase: M parallel `interceptors/list` calls + N
`interceptor/invoke` calls.

## Testing

`dotnet test` from `csharp/sdk/`: 97 passing (was 87 after #17). New
coverage:
- Orchestrator: global priority ordering across servers, alphabetical
tie-break across servers, payload chaining across servers in one
mutation pass, all-server validations seeing the post-mutation payload,
duplicate names invoking once per host.
- `InterceptorChainTests` (real in-memory servers): discovery merge with
server attribution, merged execution order, fail-closed discovery,
single-client path equivalence.
- Gateway: two interceptor servers where the second hosts the
lower-priority mutation — the backend receives the globally-ordered
payload (fails under the old sequential runner).

Closes #15.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
2026-08-06 17:22:33 +02:00
.githooks Implement Go interceptor chain (#4) 2026-04-29 15:29:25 +01:00
.github/workflows Implement Go interceptor chain (#4) 2026-04-29 15:29:25 +01:00
conformance Initial project structure for MCP interceptors (#3) 2026-01-26 17:54:37 +00:00
csharp/sdk C# SDK: multi-server interceptor chain orchestration per SEP (#18) 2026-08-06 17:22:33 +02:00
docs Introduce InterceptorOverrides in the chain execution model (#24) 2026-07-17 10:55:21 +01:00
go/sdk Align capability key to SEP-2133 extensions format (#25) 2026-07-06 10:29:21 +01:00
python/sdk Import revised sep and update the sep number (#21) 2026-06-16 05:16:21 +01:00
typescript/sdk Import revised sep and update the sep number (#21) 2026-06-16 05:16:21 +01:00
.gitignore Implement Go interceptor chain (#4) 2026-04-29 15:29:25 +01:00
LICENSE Update license from MIT to Apache 2.0 2026-01-23 21:44:11 +00:00
README.md docs: link the Interceptors Working Group charter in README (#26) 2026-06-18 17:31:46 +02:00

MCP Interceptors (Experimental Extension)

Status: Experimental. This work is for prototyping and feedback only, and is not an accepted or official MCP extension.

This repository provides a multi-language reference implementation of the proposed interceptor extension for the Model Context Protocol (MCP), as described in SEP-2624.

Charter: modelcontextprotocol.io/community/working-groups/interceptors — the Interceptors Working Group's mission, scope, leadership, and active work items.

Implementations

Language Directory Package Status
C# csharp/sdk/ ModelContextProtocol.Interceptors In Progress
Go go/sdk/ github.com/modelcontextprotocol/ext-interceptors/go/sdk Planned
Python python/sdk/ mcp-ext-interceptors Planned
TypeScript typescript/sdk/ @ext-modelcontextprotocol/interceptors Planned

CI/CD

This monorepo uses path-based CI workflows to efficiently test only what changes:

How It Works

  1. Language-specific workflows (csharp.yml, python.yml, go.yml, typescript.yml)

    • Only trigger when their language directory or workflow file changes
    • Run all tests, linting, and checks for that language
  2. Status check workflow (status-check.yml)

    • Runs on every PR to verify required checks passed
    • Determines what needs to pass based on which files changed
    • This is the only required check in branch protection

Examples

  • Change python/sdk/file.py → Only Python CI runs → PR requires Python checks to pass
  • Change both Go and TypeScript files → Both CIs run → PR requires both to pass
  • Change only README.md → No language CIs run → PR can merge immediately

Forcing All Checks

To run all language checks regardless of changed files:

  • In a PR: Comment /test all (only works for repo owners/members/collaborators)
  • Manually: Use GitHub Actions UI or CLI to trigger individual workflows

Adding New Required Checks

  1. Add your check to the appropriate language workflow (e.g., python.yml):

    python-security-scan:
      name: "Security Scan"
      runs-on: ubuntu-latest
      steps:
        - name: Run security checks
          run: # your commands here
    
  2. Update the status check in .github/workflows/status-check.yml:

    const requiredChecks = {
      python: [
        'Python CI / Linting',
        'Python CI / Unit Tests (3.10)',
        // ... existing checks ...
        'Python CI / Security Scan'  // ← Add your new check
      ],
    
  3. Submit PR - Your new check is now required for all relevant changes!

License

Apache License 2.0 - See LICENSE file for details

Resources