<!-- 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>
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>
