Model Context Protocol Rust SDK

The Model Context Protocol (MCP) implements a secure OAuth 2.1-compliant authorization flow. The process follows these steps:

1. Resource Metadata Discovery: The client probes the server for WWW-Authenticate parameters (including resource_metadata URL and scope).
2. Protected Resource Metadata: The client fetches resource server metadata (RFC 9728).
3. AS Metadata Discovery: The client discovers authorization server metadata via RFC 8414 and OpenID Connect endpoints.
4. Client Registration: The client may dynamically register itself or use a URL-based Client ID.
5. Scope Selection: Scopes are selected based on a hierarchy: WWW-Authenticate > PRM > AS metadata > caller defaults.
6. Authorization Request: An authorization URL is built using PKCE (S256) and RFC 8707 resource parameters.
7. Authorization Code Exchange: The code is exchanged for an access token.
8. Token Usage: Tokens are used via AuthClient or AuthorizedHttpClient.
9. Token Refresh: The SDK automatically uses refresh tokens, forwarding previously granted scopes to ensure compatibility with providers like Azure AD v2.
10. Scope Upgrade: If a 403 insufficient_scope error occurs, the SDK computes the scope union and re-authorizes with upgraded scopes.

The following table summarizes the current state of feature documentation and examples within the rust-sdk. Use this to identify which features have robust support (PASS) versus those that may lack guidance (FAIL/PARTIAL).

Fully Documented Features (PASS)

• Tools: Listing and calling tools, including text results.
• Elicitation: Form mode.
• Transports: stdio (client and server) and Streamable HTTP (client and server).
• Schema: JSON Schema 2020-12 support.

Partially Documented Features (PARTIAL)

• Resources: Listing, reading text, and templates.
• Prompts: Listing, getting simple prompts, and getting prompts with arguments.
• Sampling: Creating messages.
• Completions: Resource and prompt arguments.
• Progress: Progress notifications.
• Elicitation: Enum values.

Experimental Features (INFO)

• Tasks: get, result, and cancel (Note: these are experimental and may change).

Note: Many core features like binary resource reading, image/audio tool results, subscriptions, roots, logging, and cancellation are currently undocumented.

The rmcp library supports stateless Streamable HTTP automatically for the 2026-07-28 protocol.

To serve legacy clients (< 2026-07-28) without sessions, set with_legacy_session_mode(false) in StreamableHttpServerConfig. You can also use with_json_response(true) to allow simple request/response tools to reply with a single application/json body instead of an SSE stream.

Note: Because the service is stateless, the service_factory runs per request. Shared state (like DB pools) should be captured in the closure via a Clone handle.

use rmcp::transport::streamable_http_server::{
    StreamableHttpService, StreamableHttpServerConfig,
    session::local::LocalSessionManager,
};

let config = StreamableHttpServerConfig::default()
    .with_legacy_session_mode(false) // stateless for legacy versions too
    .with_json_response(true);       // plain JSON replies for simple tools

let service = StreamableHttpService::new(
    || Ok(Counter::new()),           // a fresh handler per request
    LocalSessionManager::default().into(),
    config,
);

// `StreamableHttpService` is a Tower service — mount it on any router.
let router = axum::Router::new().nest_service("/mcp", service);