modelcontextprotocol/rust-sdk
Watch
1
0
Fork
You've already forked rust-sdk
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2
rust-sdk/crates/rmcp
History
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Stefano Amorelli 7824bfdada
 feat(auth): accumulate client-side scopes during step-up authorization (#888) 
SEP-2350 [1] clarifies that scope accumulation is a client-side
responsibility: during re-authorization the client requests the union of
its previously requested scopes and the newly challenged scopes, because
servers report only the scopes needed for the current operation in
403 / insufficient_scope challenges (RFC 6750 §3.1), not the union of
everything granted so far.

select_base_scopes returned a single source, so a 403 challenge replaced
the previously requested scopes instead of widening them, dropping prior
permissions across step-up rounds. I make it union the previously
requested scopes, the WWW-Authenticate challenge, and the protected
resource metadata scopes (RFC 9728), treating each server-reported set as
an operational requirement for the current operation rather than an
exclusive directive; AS metadata and caller defaults only seed the
request when nothing has been requested or challenged yet.

exchange_code_for_token treats an explicit scope list as authoritative,
so a server may still narrow the grant. When the server omits scope it
has granted exactly what the client requested (RFC 6749 §5.1), so the
grant has to fall back to the scopes requested in this round, not the
previously granted set; otherwise a step-up that the server confirms by
omitting scope would silently drop the just-added permission and the
client would loop on the same 403. The widened request was not persisted
anywhere the exchange could read it, so I record it on
StoredAuthorizationState per authorization (defaulting empty for states
stored before this field existed) and resolve the grant from there. This
addresses review feedback [2] that the earlier fallback returned the
previous grant rather than the request. Deduplication preserves
first-seen order for stable, testable output. Tests cover multi-round
accumulation, dedup, resource-metadata unioning, and grant resolution
when the response omits scope. Implements [3].

[1]: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/draft/basic/authorization.mdx#L682
[2]: https://github.com/modelcontextprotocol/rust-sdk/pull/888#pullrequestreview-4454854582
[3]: https://github.com/modelcontextprotocol/rust-sdk/issues/877

Signed-off-by: Stefano Amorelli <stefano@amorelli.tech>
2026-07-16 15:47:52 -04:00
..
src feat(auth): accumulate client-side scopes during step-up authorization (#888) 2026-07-16 15:47:52 -04:00
tests feat!: add server discovery and negotiation (SEP-2575) (#973) 2026-07-16 13:47:30 -04:00
build.rs chore: add pre-commit hook for conventional commit verification (#619) 2026-01-14 16:01:28 -05:00
Cargo.toml fix: bound streamable HTTP memory usage (#970) 2026-07-14 15:05:07 -04:00
CHANGELOG.md chore: release v2.2.0 (#953) 2026-07-08 13:24:21 -04:00
README.md feat: add local feature for !Send tool handler support (#740) 2026-03-11 17:22:56 -04:00

README.md

rmcp

Crates.io Documentation

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:

  1. (Sink, Stream) or a combined Sink + Stream
  2. (AsyncRead, AsyncWrite) or a combined AsyncRead + AsyncWrite
  3. A Worker implementation
  4. A Transport implementation directly

License

This project is licensed under the terms specified in the repository's LICENSE file.