Adds Peder's Dev Summit talk (Context Middleware for MCP: From
Enterprise Needs To Protocol Extension) to the README
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
## Summary
Fixes the open **critical** code scanning alert
(`actions/code-injection/critical`) in
`.github/workflows/status-check.yml`.
The "Get PR number" step interpolated `${{
github.event.workflow_run.head_branch }}` directly into a `run:` shell
script. A PR author controls their own branch name, so a branch named
`rce$(...)` executes arbitrary commands on the runner — which holds a
`GITHUB_TOKEN` with `statuses: write` and `checks: write`. This is a
live target: PR #32's branch name is a working injection payload against
this exact line.
## Fix
Move the branch name (and the other two templated values in the step)
into `env:` and reference them as quoted shell variables. GitHub Actions
template expansion no longer touches the script body, so
attacker-controlled input can't break out of the string.
No behavior change for legitimate runs.
## Not addressed here
The other open alert — critical vitest advisory (Dependabot #4) — is
already covered by open PR #14, so it's intentionally left out of this
PR.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
<!-- Provide a brief summary of your changes -->
## Motivation and Context
The SEP-2624 spec defines interceptor modes as "active" | "audit". This
change aligns the Go SDK's interceptor `Mode` value with the SEP spec.
## How Has This Been Tested?
- go test ./... from go/sdk — all packages pass (chain, extension,
integrations/gomiddleware).
- gofmt -l . — clean.
- go vet ./... — clean.
## Breaking Changes
Yes:
- The exported constant interceptors.ModeEnforce is removed and replaced
by interceptors.ModeActive. Callers referencing ModeEnforce must rename.
- The serialized mode value changes from "enforce" to "active". Any
config expecting "enforce" must be updated.
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [x] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [x] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
Signed-off-by: monikaicampbell <mcampbell350@bloomberg.net>
## Summary
Bumps the MCP C# SDK dependency from 1.1.0 to 2.1.0 across all 9
projects and aligns the implementation with the 2.x surface and the
2026-07-28 spec — not just a version bump.
### Compile fixes
- Removed the gateway's `Capabilities.Tasks = null` suppression and its
test: the experimental Tasks API was removed from SDK core in 2.0 (moved
to a separate, wire-incompatible `ModelContextProtocol.Extensions.Tasks`
package).
- Added `ResolveInputRequestsAsync` (new abstract MRTR member on
`McpClient`) overrides to the test doubles. MRTR forwarding is
deliberately out of scope for this PR; the gateway's server reports
`IsMrtrSupported == false`.
- Deleted all `MCPEXP001` pragmas — `ServerCapabilities.Extensions`
(which carries `io.modelcontextprotocol/interceptors`) is stable in 2.x.
`MCPEXP002` subclassing pragmas are kept.
### Spec deprecations (SEP-2577 / SEP-2575)
- The gateway intentionally keeps proxying `logging/setLevel` and
`resources/subscribe` for down-level clients/backends, with targeted
`MCP9005` suppressions.
- On negotiated `2026-07-28` connections the SDK rejects these methods
at the session layer (replaced by per-request `_meta` log levels and
`subscriptions/listen`), so the affected tests now pin `protocolVersion:
"2025-06-18"` through a new fixture parameter — making them genuine
down-level-compatibility tests.
### Defensive hardening
- `Tool.inputSchema` is required and validated on deserialization in
2.x. The gateway's `ListToolsHandler` now fetches the backend
`tools/list` result as raw JSON and runs
`GatewayProxyConfigurator.EnsureToolInputSchemas` before and after the
interceptor chain, coercing missing/invalid schemas to the spec-default
`{"type":"object"}` so down-level backends and schema-stripping
interceptors can't fail the request.
### Tests & docs
- New tests: end-to-end schema-stripping coercion,
`EnsureToolInputSchemas` unit cases, and `2026-07-28` protocol-version
negotiation through the gateway (implicitly exercising
`server/discover`).
- `CLAUDE.md` gains an "SDK 2.x / spec 2026-07-28 notes" section;
`ARCHITECTURE_PHASES.md` no longer lists `Tasks` as a mirrored
capability.
## Test plan
- [x] `dotnet build` — 0 errors, 0 warnings (library, tests, all 7
samples)
- [x] `dotnet test` — 105/105 passing (was 98: −1 removed Tasks test, +8
new)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: Ola Hungerford <olahungerford@gmail.com>
<!-- Provide a brief summary of your changes -->
Update the Go interceptor SDK to use
`github.com/modelcontextprotocol/go-sdk` v1.7.0 custom method APIs and
remove the vendored Go SDK copy. This shouldn't update the behaviours,
but addding following functions.
Changed public/user-facing interfaces:
extension.Extension.Install now returns an error:
```
// before
ext.Install(mcpServer)
// after
if err := ext.Install(mcpServer); err != nil {
return err
}
```
New helper added:
```
extension.RegisterSendingMethods(client *mcp.Client) error
```
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
Pick up MCP Go SDK 1.7.0. This provides upstream custom method support,
so the local vendored SDK copy is no longer needed.
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
- `go test -v ./...`
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
```go
if err := ext.Install(mcpServer); err != nil {
return err
}
```
The Go SDK module now requires Go 1.25 via
github.com/modelcontextprotocol/go-sdk v1.7.0.
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [x] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
LocalChain now registers interceptor custom sending methods internally.
Manual remote chain setup should call
`extension.RegisterSendingMethods(client)` before connecting the MCP
client session used with chain.AddMCPServer.
Signed-off-by: Ukjae Jeong <jeongukjae@gmail.com>
<!-- Provide a brief summary of your changes -->
Ensure Go audit-mode interceptors remain non-blocking when validator or
mutator invocation returns an error.
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
SEP says audit-mode interceptors MUST NOT block execution regardless of
results. The Go SDK already avoided blocking on audit-mode validation
findings, but validator/mutator handler or RPC errors could still abort
unless `FailOpen` was set.
This change makes audit mode consistently non-blocking for invocation
errors as well, matching the existing C# orchestrator behavior where
`isAudit || failOpen` allows execution to continue.
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
Added focused Go chain tests covering audit-mode validator and mutator
errors.
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
None. This only relaxes audit-mode error handling to match SEP
semantics.
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
C# already treats audit-mode invocation failures as non-blocking. This
aligns the Go chain behavior with that implementation and SEP audit-mode
semantics.
Signed-off-by: Ukjae Jeong <jeongukjae@gmail.com>
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>
Addresses the first two items of #15 (the chain-orchestrator
multi-server item follows in a separate PR).
## `mode`: keep `"active"`, add `"audit"` round-trip coverage
> **Update:** an earlier revision of this PR renamed `mode` from
`"active"` to `"enforce"`, following a SEP **draft**. The now-current
revised SEP-1763 ([PR
#2624](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2624))
defines `mode?: "active" | "audit"` with default `"active"` — so
`"active"` was correct all along. @jeongukjae flagged this; the rename
has been reverted (commit 58edf2c). The C# SDK's wire value `"active"`
matches the SEP and the TypeScript SDK.
`InterceptorMode` keeps members `Active` (wire `"active"`, default) and
`Audit` (wire `"audit"`). Added a deserialization test alongside the
existing serialization test so both wire forms are covered.
## `priorityHint`: support `number | { request?, response? }`
The SDK only supported a plain `int`. This adds a `PriorityHint`
protocol type whose converter accepts both wire forms and preserves them
on round-trip (a number stays a number, an object stays an object).
Chain ordering now resolves the effective priority per phase exactly as
the SEP's `resolvePriority` algorithm (unset → 0, alphabetical tie-break
unchanged).
- `Interceptor.PriorityHint` is now `PriorityHint?`; an implicit
conversion from `int` keeps existing code compiling.
- `[McpServerInterceptor]` gains `RequestPriorityHint` /
`ResponsePriorityHint` (mutually exclusive with the scalar
`PriorityHint`), following the official SDK's backing-field pattern for
optional attribute values.
- Behavior note: attribute-discovered interceptors with no priority set
now omit `priorityHint` from the wire instead of emitting `0` —
semantically identical per the SEP default, and consistent with the
existing default-skipping for `Mode`/`FailOpen`.
## Testing
`dotnet test` from `csharp/sdk/`: all passing, including new coverage
for both `priorityHint` wire forms, partial objects, unknown-key
tolerance, phase-dependent mutation ordering (the SEP's
pii-redactor/compressor example), the attribute conflict error, and both
`mode` wire values.
Part of #15.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
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>
Both SDKs now use Capabilities.Extensions with key
"io.modelcontextprotocol/interceptors". Previously C# used the short key
"interceptors" and Go used Capabilities.Experimental. SEP capability
example updated to match.
https://modelcontextprotocol.io/seps/2133-extensions
---------
Signed-off-by: Ukjae Jeong <jeongukjae@gmail.com>
This change adds an ExecutionHandler hook to the Go chain orchestrator,
allowing direct callers to wrap each interceptor/invoke RPC call. The
handler can inspect and modify invoke params before execution, inspect
results after execution, override the effective mode per-invocation, or
short-circuit execution entirely. The change is fully
backwards-compatible and requires no SEP/protocol modifications.
---------
Signed-off-by: Ukjae Jeong <jeongukjae@gmail.com>
The SEP spec and C# SDK use hooks (plural, JSON array) but the Go SDK
had hook (singular, single object). This meant the wire formats were
incompatible — Go would send `{"hook": {...}}` while everything else
expects `{"hooks": [...]}`.
Signed-off-by: Ukjae Jeong <jeongukjae@gmail.com>
Re-implementation of C# interceptors SDK with clearer focus on
server-side / gateway interceptors.
Fixes a lot of issues with the existing implementation.
Still more boilerplate than I'm happy with, but this is better than what
was there. Will refine further in later PRs.
<!-- Provide a brief summary of your changes -->
Route `interceptors/list` and `interceptor/invoke` through the receiving
middleware chain so that middleware installed (audit, etc.) fires for
interceptor protocol methods the same way it does for standard MCP
methods.
## Motivation and Context
<!-- Why is this change needed? What problem does it solve? -->
Before this change, custom JSON-RPC methods were dispatched via a
separate code path that bypassed receiving middleware entirely. This
meant any middleware an operator installed would silently not apply to
the interceptor protocol endpoints.
The fix adds `AddReceivingCustomMethod[P, R, T]` as a package-level
generic function to the vendored go-sdk/mcp package. Custom methods
registered through it are stored in a per-server customMethods map and
merged into `receivingMethodInfos()`, so `defaultReceivingMethodHandler`
dispatches them exactly like built-in methods. External types satisfy
the sealed `Params`/`Result` interfaces by embedding the
`ParamsBase`/`ResultBase` types exported from the mcp package.
## How Has This Been Tested?
<!-- Have you tested this in a real application? Which scenarios were
tested? -->
Existing test suites and new ones for verifying middleware paths.
## Breaking Changes
<!-- Will users need to update their code or configurations? -->
no.
## Types of changes
<!-- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [x] My code follows the repository's style guidelines
- [x] New and existing tests pass locally
- [x] I have added appropriate error handling
- [x] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
The changes to `vendor/go-sdk/mcp/server.go` are intentionally minimal
and carry a `NOTE` comment acknowledging they are additions to the
upstream SDK needed for this reference implementation.
---------
Signed-off-by: Ukjae Jeong <jeongukjae@gmail.com>
## Summary
- Rename `interceptors/mcpserver/` → `interceptors/extension/`,
replacing the `Server` wrapper with a lightweight `Extension` that can
install itself on any `*mcp.Server`
- Remove the stored `*mcp.Server` field — `Extension` is now a pure
interceptor container with no server reference
- Add `Install(server)` method to register JSON-RPC methods and init
middleware on a given server
- Update `LocalChain(ctx)` → `LocalChain(ctx, server)` to accept the
server as a parameter
- Remove `MCPServer()`, `Run()`, and `NewStreamableHTTPHandler()`
wrapper methods — users interact with `mcp.Server` directly
- Update all examples, tests, and documentation to use the new API
## Why
`mcpserver.Server` pretended to *be* the server — it had `Run()`,
`NewStreamableHTTPHandler()`, etc. — but it could never cover the full
`*mcp.Server` API, so users constantly needed `MCPServer()` to unwrap
it.
`Extension` doesn't pretend to be the server. It's a pure interceptor
container that can install itself on any server (or multiple servers)
on the fly. No stored server reference, no wrapping, no delegation
surface to maintain.
### Before
```go
mcpServer := mcp.NewServer(...)
srv := mcpserver.NewServer(mcpServer)
srv.AddInterceptor(v)
chain, err := srv.LocalChain(ctx)
```
### After
```go
mcpServer := mcp.NewServer(...)
ext := extension.New()
ext.AddInterceptor(v)
ext.Install(mcpServer)
chain, err := ext.LocalChain(ctx, mcpServer)
```
Signed-off-by: Kurt Degiorgio <kdegiorgio@bloomberg.net>
Establishes a multi-language monorepo structure for MCP interceptors
with Python and TypeScript SDKs alongside the existing Go
implementation. Implements an efficient CI/CD system that only tests
what changes.
#### 🏗️ SDK Scaffolding
- **Python SDK** (`python/sdk/`): Modern Python package using
`pyproject.toml`, aligned with official MCP Python SDK patterns
- **TypeScript SDK** (`typescript/sdk/`): ESM-based package structure,
compatible with official MCP TypeScript SDK
- **Monorepo structure**: Consistent `{language}/sdk/` pattern across
all implementations
#### 🚀 CI/CD Pipeline
- **Path-based workflow triggering**: Only runs CI for languages that
actually changed
- Change Python → only Python CI runs
- Change multiple languages → only those CIs run
- **Status check workflow**: Single required check that dynamically
validates based on changes
- **Comment triggers**: Maintainers can run all checks with `/test all`
PR comment
