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
Ukjae Jeong eebd2ac6a2
Introduce InterceptorOverrides in the chain execution model (#24)
Introduce InterceptorOverrides in the chain execution model to separate
interceptor capability (server-declared) from execution policy
(invoker-declared).

## Why

The SEP currently locks all execution policy (failOpen, priorityHint,
mode) into the interceptor's own definition. This means:
- If an interceptor declares `failOpen: false` but is known to be flaky
in your deployment, you can't make it fail-open without changing the
server
- If you want the same interceptor in audit mode in staging but active
in production, there's no mechanism
- If you want to restrict an interceptor to only `tools/call` even
though it declares support for `tools/call` + `llm/completion`, you have
to invoke it and hope the chain filters correctly
- Priority is fixed by the author, so platform teams can't reorder
interceptors for their deployment topology

In short: the chain interface had no policy layer, making it impractical
for real-world multi-environment deployments.

## Changes

1. New "Capability vs Policy" subsection explaining the two-layer model
2. New `InterceptorOverrides` interface (failOpen, priorityHint, mode,
timeoutMs, hooks)
3. ChainEntry gains `overrides?: InterceptorOverrides`
4. `resolvePriority()` updated to check overrides first
5. Orchestration steps updated — new step 2 "Resolve Policy"
6. New example showing overrides in action (priority override, mode
promotion, fail-open for fragile interceptor)
7. New rationale entry (Design Decision 4) explaining why both layers
exist

Signed-off-by: Ukjae Jeong <jeongukjae@gmail.com>
Co-authored-by: Kurt Degiorgio <Degiorgio@users.noreply.github.com>
2026-07-17 10:55:21 +01: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 Align capability key to SEP-2133 extensions format (#25) 2026-07-06 10:29:21 +01: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