| Filename | Latest commit message | Latest commit date |
|---|---|---|
434ccb7812* fix(auth): pass WWW-Authenticate scopes to DCR registration request
When an MCP server returns a 401 with `WWW-Authenticate: Bearer scope="..."`,
the scopes are parsed but never included in the Dynamic Client Registration
(DCR) request. Per RFC 7591, the DCR request should include a `scope` field
so the authorization server knows what scopes the client intends to use.
Servers that enforce scope-matching between registration and authorization
will reject the flow without this.
Changes:
- Add optional `scope` field to `ClientRegistrationRequest` with
`skip_serializing_if` for backward compatibility
- Update `register_client()` to accept scopes parameter and include
them in the DCR request body and returned `OAuthClientConfig`
- Thread scopes from `AuthorizationSession::new()` into both
`register_client()` call sites
- Re-export `oauth2::TokenResponse` trait so consumers can extract
scopes from token responses
- Add serialization tests for the new `scope` field
* refactor(auth): change register_client to accept &[&str] instead of &[String]
Avoids unnecessary Vec<String> allocation in callers that already have &[&str].
* fix(auth): make ClientRegistrationRequest crate-private
* refactor(auth): stop re-exporting oauth2 TokenResponse trait
* style(auth): merge TokenResponse into grouped oauth2 import
Fix nightly rustfmt check by consolidating the separate
`use oauth2::TokenResponse` into the existing `use oauth2::{...}` block.
|
||
| .. | ||
| src | ||
| tests | ||
| build.rs | ||
| Cargo.toml | ||
| CHANGELOG.md | ||
| README.md | ||
rmcp
The official Rust SDK for the Model Context Protocol. Build MCP servers that expose tools, resources, and prompts to AI assistants — or build clients that connect to them.
For getting started, usage guides, and full MCP feature documentation (resources, prompts, sampling, roots, logging, completions, subscriptions, etc.), see the main README.
Feature Flags
| Feature | Description | Default |
|---|---|---|
server |
Server functionality and the tool system | ✅ |
client |
Client functionality | |
macros |
#[tool] / #[prompt] macros (re-exports rmcp-macros) |
✅ |
schemars |
JSON Schema generation for tool definitions | |
auth |
OAuth 2.0 authentication support | |
elicitation |
Elicitation support |
Transport features
| Feature | Description |
|---|---|
transport-io |
Server-side stdio transport |
transport-child-process |
Client-side stdio transport (spawns a child process) |
transport-async-rw |
Generic async read/write transport |
transport-streamable-http-client |
Streamable HTTP client (transport-agnostic) |
transport-streamable-http-client-reqwest |
Streamable HTTP client with default reqwest backend |
transport-streamable-http-server |
Streamable HTTP server transport |
TLS backend options (for HTTP transports)
| Feature | Description |
|---|---|
reqwest |
Uses rustls — pure Rust TLS (recommended default) |
reqwest-native-tls |
Uses platform-native TLS (OpenSSL / Secure Transport / SChannel) |
reqwest-tls-no-provider |
Uses rustls without a default crypto provider (bring your own) |
Transports
The transport layer is pluggable. Two built-in pairs cover the most common cases:
| Client | Server | |
|---|---|---|
| stdio | TokioChildProcess |
stdio |
| Streamable HTTP | StreamableHttpClientTransport |
StreamableHttpService |
Any type that implements the Transport trait can be used. The IntoTransport helper trait provides automatic conversions from:
(Sink, Stream)or a combinedSink + Stream(AsyncRead, AsyncWrite)or a combinedAsyncRead + AsyncWrite- A
Workerimplementation - A
Transportimplementation directly
License
This project is licensed under the terms specified in the repository's LICENSE file.