modelcontextprotocol / rust-sdk

简体中文 RMCP An official Rust Model Context Protocol SDK implementation with tokio async runtime. > **Migrating to 1.x?** See the migration guide for breaking changes and upgrade instructions. This repository contains the following crates: • rmcp: The core crate providing the RMCP protocol implementation - see rmcp • rmcp-macros: A procedural macro crate for generating RMCP tool implementations - see rmcp-macros For the full MCP specification, see modelcontextprotocol.io. Table of Contents • Usage • Resources • Prompts • Sampling • Roots • Logging • Completions • Notifications • Subscriptions • Examples • OAuth Support • Related Resources • Related Projects • Development Usage Import the crate Third Dependencies Basic dependencies: • tokio • serde Json Schema generation (version 2020-12): • schemars Build a Client Start a client Build a Server Build a transport Build a service You can easily build a service by using or . Start the server Interact with the server Once the server is initialized, you can send requests or notifications: Waiting for service shutdown --- Resources Resources let servers expose data (files, database records, API responses) that clients can read. Each resource is identified by a URI and returns content as text or binary (base64-encoded) data. Resource templates allow servers to declare URI patterns with dynamic parameters. **MCP Spec:** Resources Server-side Implement , , and optionally on the trait. Enable the resources capability in . Client-side Notifications Servers can notify clients when the resource list changes or when a specific resource is updated: Clients handle these via : **Example:** (server), (client) --- Prompts Prompts are reusable message templates that servers expose to clients. They accept typed arguments and return conversation messages. The macro handles argument validation and routing automatically. **MCP Spec:** Prompts Server-side Use the , , and macros to define prompts declaratively. Arguments are defined as structs deriving . Prompt functions support several return types: • -- simple message list • -- messages with an optional description • -- either of the above, with error handling Client-side Notifications **Example:** (server), (client) --- Sampling Sampling flips the usual direction: the server asks the client to run an LLM completion. The server sends a request, the client processes it through its LLM, and returns the result. **MCP Spec:** Sampling Server-side (requesting sampling) Access the client's sampling capability through : Client-side (handling sampling) On the client side, implement . This is where you'd call your actual LLM: **Example:** (server), (client) --- Roots Roots tell servers which directories or projects the client is working in. A root is a URI (typically ) pointing to a workspace or repository. Servers can query roots to know where to look for files and how to scope their work. **MCP Spec:** Roots Server-side Ask the client for its root list, and handle change notifications: Client-side Clients declare roots capability and implement : Clients notify the server when roots change: --- Logging Servers can send structured log messages to clients. The client sets a minimum severity level, and the server sends messages through the peer notification interface. **MCP Spec:** Logging Server-side Enable the logging capability, handle level changes from the client, and send log messages via the peer: Available log levels (from least to most severe): , , , , , , , . Client-side Clients handle incoming log messages via : Clients can also set the server's log level: --- Completions Completions give auto-completion suggestions for prompt or resource template arguments. As a user fills in arguments, the client can ask the server for suggestions based on what's already been entered. **MCP Spec:** Completions Server-side Enable the completions capability and implement the handler. Use to inspect previously filled arguments: `rust use rmcp::{ErrorData as McpError, ServerHandler, model::*, service::RequestContext, RoleServer}; impl ServerHandler for MyServer { fn get_info(&self) -> ServerInfo { ServerInfo { capabilities: ServerCapabilities::builder() .enable_completions() .enable_prompts() .build(), ..Default::default() } } async fn complete( &self, request: CompleteRequestParams, _context: RequestContext , ) -> Result { let values = match &request.r#ref { Reference::Prompt(prompt_ref) if prompt_ref.name == "sql_query" => { match request.argument.name.as_str() { "operation" => vec!["SELECT", "INSERT", "UPDATE", "DELETE"], "table" => vec!["users", "orders", "products"], "columns" => { // Adapt suggestions based on previously filled arguments if let Some(ctx) = &request.context { if let Some(op) = ctx.get_argument("operation") { match op.to_uppercase().as_str() { "SELECT" | "UPDATE" => { vec!["id", "name", "email", "created_at"] } _ => vec![], } } else { vec![] } } else { vec![] } } _ => vec![], } } _ => vec![], }; // Filter by the user's partial input let filtered: Vec = values.into_iter() .map(String::from) .filter(|v| v.to_lowercase().contains(&r _...truncated for preview_