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
