Commit graph experimental-ext-interceptors/.github/workflows
Author SHA1 Message Date
Ola Hungerford
2f66b9b4af
ci: prevent shell injection in status-check workflow (#39)
## 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>
2026-08-21 16:06:34 +01:00
Ukjae Jeong
8704137635
Go SDK: Upgrade MCP SDK and remove vendored copy (#35)
<!-- 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>
2026-08-12 14:48:17 -07:00
Kurt Degiorgio
c9900f02ab
Implement Go interceptor chain (#4)
## Summary

Implements the Go SDK for MCP interceptors — validation and mutation
middleware for any MCP server.

The framework treats interceptors as first-class MCP primitives: they
are registered on an MCP server, discoverable via `interceptors/list`,
and invocable via `interceptor/invoke` — the same JSON-RPC pattern as
tools, prompts, and resources. A chain engine orchestrates execution
across one or more interceptor servers, and an optional go-sdk
middleware integration applies interceptors automatically on every
matching request/response.

## Architecture

**Three-layer design:**

1. **`interceptors`** — Protocol-agnostic core. Defines interceptor
types (validators, mutators), metadata, invocation, wire types, and
results. Zero MCP dependencies.

2. **`interceptors/mcpserver`** — MCP server integration. Wraps
`mcp.Server` to register `interceptors/list` and `interceptor/invoke` as
custom JSON-RPC methods and advertise interceptor capabilities during
`initialize`.

3. **`interceptors/chain`** — Chain engine. Orchestrates execution
across N interceptor servers with trust-boundary-aware ordering,
priority-based mutation sequencing, parallel validation, audit-mode
isolation, and fail-open/fail-closed semantics.

4. **`interceptors/integrations/gomiddleware`** — Optional go-sdk
middleware. Installs on `mcp.Server` via `AddReceivingMiddleware()` to
automatically run the interceptor chain on every matching
request/response.

**Key design decisions:**

- **Trust-boundary ordering** — request phase: validate → mutate;
response phase: mutate → validate. Validation always guards the boundary
crossing.
- **Wire-level invocation** — the chain calls `interceptor/invoke` over
the MCP transport (even in-process via `LocalChain()`), so local and
remote interceptor servers use the same interface.
- **Audit-mode isolation** — audit-mode mutators compute transformations
without applying them. Only audit mutators pay the serialization cost.
- **Concurrency** — validators run in parallel; mutators run
sequentially in priority order.

### Package Structure

| Package | File | Responsibility |
|---------|------|----------------|
| `interceptors` | `interceptor.go` | Enums, Metadata, Interceptor
interface, Validator/Mutator structs, handler types, Invocation |
| `interceptors` | `wire.go` | Wire types: ListParams/Result,
InvokeParams/Result, InterceptorInfo, event/method constants |
| `interceptors` | `priority.go` | Priority with phase-aware resolution
and JSON marshaling |
| `interceptors` | `doc.go` | Package documentation with examples |
| `interceptors/chain` | `chain.go` | Chain engine: discovery,
filtering, sorting, execution orchestration |
| `interceptors/chain` | `result.go` | ExecutionResult, AbortInfo |
| `interceptors/chain` | `doc.go` | Sub-package documentation |
| `interceptors/mcpserver` | `server.go` | MCP server wrapper,
interceptor registry, capability advertisement, `LocalChain()` |
| `interceptors/mcpserver` | `rpc.go` | `interceptors/list` and
`interceptor/invoke` JSON-RPC handlers |
| `interceptors/mcpserver` | `doc.go` | Sub-package documentation |
| `integrations/gomiddleware` | `middleware.go` | go-sdk `Middleware`
that runs the chain on every request/response |
| `integrations/gomiddleware` | `errors.go` | Abort-to-JSONRPC error
conversion |
| `integrations/gomiddleware` | `doc.go` | Sub-package documentation |

### Documentation

- `doc/DESIGN.md` — architecture, execution model, integration with
go-sdk
- `doc/CONFORMANCE.md` — SEP conformance status
- `doc/PERFORMANCE.md` — per-request cost model

### Examples

- `examples/validator` — blocks dangerous tool calls, demonstrates
`WithContextProvider`
- `examples/mutator` — tags tool responses with audit trail

## Vendor: go-sdk v1.4.0 with custom method support

Vendors `go-sdk` with minimal extensions for custom JSON-RPC methods:

- `Server.AddCustomMethod` — registers a handler that bypasses the typed
pipeline
- `ClientSession.CallCustom` — sends raw JSON-RPC calls for custom
methods

These changes are generic (not interceptor-specific) and enable any MCP
extension to define its own JSON-RPC methods.

## TODO

- More integration tests
- Unit tests
- Support wildcards for event interception (separate PR)

---------

Signed-off-by: Kurt Degiorgio <kdegiorgio@bloomberg.net>
2026-04-29 15:29:25 +01:00
Peder Holdgaard Pedersen
45f9e0ef27
C# Implementation (#2)
C# implementation of SEP-1763

---------

Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-27 23:53:44 +00:00
Kurt Degiorgio
20974b6fa0
Initial project structure for MCP interceptors (#3)
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
2026-01-26 17:54:37 +00:00