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.
* feat: add type-safe elicitation schema support (#465)
Implement type-safe schema definitions for MCP elicitation requests,
replacing generic `JsonObject` with strongly-typed primitive schemas
per the [MCP 2025-06-18 specification](https://spec.modelcontextprotocol.io/specification/2025-06-18/server/elicitation/).
Features:
- Type-safe schema hierarchy (`StringSchema`, `NumberSchema`, `IntegerSchema`, `BooleanSchema`)
- Builder pattern with fluent API and 20+ convenience methods
- Build-time validation ensuring required fields exist in properties
- Private fields enforcing invariants through validated constructors
- Comprehensive validation support (range, length, format, enums)
- Typed property methods for cleaner schema construction
Benefits:
- Compile-time type safety prevents invalid schema construction
- 60-70% reduction in boilerplate through convenience methods
- Enforces MCP specification requirement for primitive-only properties
- Better IDE autocomplete and type inference
- Runtime validation catches schema errors early
Breaking changes:
- `CreateElicitationRequestParam.requested_schema` changed from `JsonObject` to `ElicitationSchema`
- `ElicitationSchemaBuilder::build()` now returns `Result` instead of direct value
Fixes#465
* fix: fix RMCP compliance
* feat: add conversion methods to ElicitationSchema
Add from_json_schema() and from_type() methods to ElicitationSchema
for easier type-to-schema conversion. This addresses feedback about
improving ergonomics when working with generated schemas.
Also make all struct fields public for better flexibility.
* chore: change `StringFormat` to enum
* fix(oauth): attach bearer token to all streaming http requests
* fix(typo): fix an unrelated typo
There was an errant typo in the CHANGELOG that is breaking CI
Many MCP Servers use client_name for a variety of things including:
* Whitelisting
* Logos
* Copy shown directly on the page
* etc
As a result, it's important for MCP Clients to be able to override the client name.
