#580 and #556 introduced support for custom notifications,
so this PR takes the next logical step and adds support for custom requests:
- Introduces `CustomRequest` and `CustomResult` model types, wires them into the client/server
request and result unions, and allows `ClientRequest::method()` to return the dynamic method
name.
- Implements serde and meta handling for `CustomRequest` so `_meta` is carried through
extensions; adds default `on_custom_request` handlers that return `METHOD_NOT_FOUND` unless
overridden.
- Updates JSON schema fixtures to include the new request/result shapes and `EmptyObject`
strictness.
- Adds tests for custom request roundtrips and end-to-end client↔server handling.
- Focused integration test in `crates/rmcp/tests/test_custom_request.rs`.
For additional testing, I used this locally to update Codex to use a custom
request instead of a custom notification so that it gets an "ack" from the MCP
server to ensure it has processed the update before sending more messages:
https://github.com/openai/codex/pull/8142.
https://github.com/modelcontextprotocol/rust-sdk/pull/556 introduced support for
custom client notifications, so this PR makes the complementary change, adding
support for custom server notifications.
MCP clients, particularly ones that offer "experimental" capabilities,
may wish to handle custom server notifications that are not part of the
standard MCP specification. This change introduces a new
`CustomServerNotification` type that allows a client to process
such custom notifications.
- introduces `CustomServerNotification` to carry arbitrary methods/params while
still preserving meta/extensions; wires it into the `ServerNotification` union
and `serde` so `params` can be decoded with `params_as`
- allows client handlers to receive custom notifications via a new
`on_custom_notification` hook
- adds integration coverage that sends a custom server notification end-to-end
and asserts the client sees the method and payload
Test:
```shell
cargo test -p rmcp --features client test_custom_server_notification_reaches_client
```
* feat(auth): add cimd support for SEP-991
add cimd support for url-based client ids
Signed-off-by: tanish111 <tanishdesai37@gmail.com>
* test(auth): add unit tests for is_https_url helper
Add test coverage for is_https_url helper to validate HTTPS scheme, non-root paths,
and reject http, javascript, data schemes, and invalid inputs per SEP-991 requirements.
Signed-off-by: tanish111 <tanishdesai37@gmail.com>
* feat(example): add CIMD OAuth server for SEP-991 testing
Implements a new server example (servers_cimd_auth_streamhttp) that
demonstrates CIMD (Client ID Metadata Document) support for URL-based
client IDs. The server validates client_id URLs, fetches and validates
client metadata documents, and provides OAuth 2.0 authorization endpoints
with MCP integration for end-to-end testing.
Signed-off-by: tanish111 <tanishdesai37@gmail.com>
* fix(oauth): add CORS headers to token endpoint
Add CORS headers to token endpoint to allow cross-origin requests from browsers
during OAuth authorization code exchange flow.
Signed-off-by: tanish111 <tanishdesai37@gmail.com>
* refactor: improve is_https_url function and consolidate tests
- Improve is_https_url function formatting and readability
- Merge all test cases into single test_is_https_url_scenarios function
- Add missing test case for "https://" URL
Signed-off-by: tanish111 <tanishdesai37@gmail.com>
* refactor: use map_err instead of match for error handling in auth.rs
Replace the verbose match statement with
map_err for more idiomatic
Signed-off-by: tanish111 <tanishdesai37@gmail.com>
* feat: add client-metadata.json
Add client metadata file for SEP-991 CIMD
authentication support
Signed-off-by: tanish111 <tanishdesai37@gmail.com>
---------
Signed-off-by: tanish111 <tanishdesai37@gmail.com>
SSE transport has been removed from the MCP specification in favor of
streamable HTTP. This removes all SSE-specific transport code:
- Remove `transport-sse-client` and `transport-sse-server` features
- Remove `SseClientTransport` and `SseServer` types
- Remove SSE-specific examples (`counter_sse`, `counter_sse_directly`)
- Migrate auth examples from SSE to streamable HTTP
- Update tests to remove SSE transport usage
- Update documentation
BREAKING CHANGE: The following have been removed:
- `transport-sse-client` feature
- `transport-sse-client-reqwest` feature
- `transport-sse-server` feature
- `SseClientTransport` type
- `SseServer` type
- `sse_client` and `sse_server` modules
Users should migrate to streamable HTTP transport which provides
equivalent functionality. See `StreamableHttpClientTransport` and
`StreamableHttpService` for the replacement APIs.
Ref: https://github.com/modelcontextprotocol/rust-sdk/pull/561#issuecomment-3576551699
MCP servers, particularly ones that offer "experimental" capabilities,
may wish to handle custom client notifications that are not part of the
standard MCP specification. This change introduces a new
`CustomClientNotification` type that allows a server to process
such custom notifications.
- introduces `CustomClientNotification` to carry arbitrary methods/params while
still preserving meta/extensions; wires it into the `ClientNotification` union
and `serde` so `params` can be decoded with `params_as`
- allows server handlers to receive custom notifications via a new
`on_custom_notification` hook
- adds integration coverage that sends a custom client notification end-to-end
and asserts the server sees the method and payload
Test:
```shell
cargo test -p rmcp --features client test_custom_client_notification_reaches_server
```
SSE transport has been removed from newer versions of the MCP spec.
Streamable HTTP is preferred as it is more reliable.
Moves SSE examples to a collapsed details section at the bottom of
the example list and removes them from the 'How to Run' section.
What this enables:
- Clients can accept either Server-Sent Events (SSE) or JSON responses
- Flexible content negotiation based on server preferences
- Improved interoperability with different MCP server implementations
* fix: exclude WASI example from workspace to avoid linker errors on Mac/arm64
Cargo uses the macOS host linker for workspace builds,
but that linker cannot resolve WASI WebAssembly imports
(such as _wasi:cli/run@0.2.x). As a result, including a WASI
crate in the workspace causes builds to fail on macOS systems using arm64.
Solution: Mark the WASI example as non-default by excluding it from the
workspace members. This makes the WASI package optional, so `cargo build`
won't touch it, and it can be built explicitly when needed with:
cargo build -p wasi-mcp-example --target wasm32-wasip2
Signed-off-by: tanish111 <tanishdesai37@gmail.com>
* fix: make WASI example standalone for CI compatibility
Replace workspace inheritance with explicit values in examples/wasi/Cargo.toml
since excluded packages cannot inherit from workspace. This fixes CI manifest
parsing errors when building WASI example explicitly.
Signed-off-by: tanish111 <tanishdesai37@gmail.com>
* fix: exclude examples from default builds using default-members
Only core crates are built by default, preventing WASI linker errors
on macOS while keeping it in workspace for property inheritance.
Signed-off-by: tanish111 <tanishdesai37@gmail.com>
---------
Signed-off-by: tanish111 <tanishdesai37@gmail.com>
auth.rs was using an in-memory expires-at which is only set on initial token exchange.
Instead, this PR switches it to use the expires-at set in the credentials that are passed in.
