rust-mcp-schema

Library Featured

Type-safe implementation of the Model Context Protocol in Rust, designed to reduce errors and accelerate development with powerful utilities.

Checked Β· Sources

Downloads
107,187
Dependents
19
Stars
79
Forks
5
Contributors
2
Commits
133
Latest release
2.0.0 Β·

About

From the project README Β·

Description

Model Context Protocol (MCP) Schema for Rust

A type-safe Rust implementation of the official Model Context Protocol (MCP) schema, supporting all official MCP Protocol versions:

  • 2026-07-28 (default)
  • 2025-11-25
  • 2025-06-18
  • 2025-03-26
  • 2024-11-05
  • draft

The MCP schemas in this repository are automatically generated from the official Model Context Protocol, ensuring they are always up-to-date and aligned with the latest official specifications.


Note: This crate only provides an implementation of the MCP schema.

If you are looking for a high-performance, asynchronous toolkit for building MCP servers and clients, checkout rust-mcp-sdk. Focus on your app's logic while rust-mcp-sdk takes care of the rest!


Contents:

  • Features

  • How can this crate be used?

  • Schema Versions

    • How to switch between different schema versions?
    • How are Schemas generated?
  • What is schema_utils?

  • What does the schema_utils do?

  • Usage Examples

    • Detecting a CallToolRequest Message on an MCP Server
    • Creating a CallToolResult Response on an MCP Server
    • Detecting a CallToolResult Response Message in an MCP Client
  • Usage Examples (Without Utilizing schema_utils)

    • Detecting a CallToolRequest Message on an MCP Server (without schema_utils)
  • Contributing

Read the full README

Features

  • 🧩 Type-safe implementation of the MCP protocol specification.
  • πŸ’Ž Auto-generated schemas are always synchronized with the official schema specifications.
  • πŸ“œ Includes all official released versions : 2026-07-28, 2025-11-25, 2025-06-18, 2025-03-26, 2024-11-05 and draft version for early adoption.
  • πŸ›  Complimentary schema utility module (schema_utils) to boost productivity and ensure development integrity.

How can this crate be used?

This Crate provides Rust implementation of the official Model Context Protocol (MCP) schema.

Model Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools. Whether you’re building an AI-powered IDE, enhancing a chat interface, or creating custom AI workflows, MCP provides a standardized way to connect LLMs with the context they need.

This crate includes the schema with serialization / deserialization support via serde_json, along with a minimal implementation of the necessary traits for structs and enums. This helps in creating and using various MCP messages such as requests, responses, notifications, and errors.

This crate could be used for developing an MCP Server or MCP Client in Rust. For more information on the MCP architecture, refer to the official documentation.


Check out rust-mcp-sdk , a high-performance, asynchronous toolkit for building MCP servers and clients which is based on rust-mcp-schema. Focus on your app's logic while rust-mcp-sdk takes care of the rest!


Schema Versions

This repository provides all official released versions the schema , including draft version, enabling you to prepare and adapt your applications ahead of upcoming official schema releases.

How to switch between different schema versions?

By default, the latest version of the MCP Protocol schema is enabled.

Each schema version has a corresponding Cargo feature that can be enabled in your project's Cargo.toml.

Multiple schema versions may be enabled concurrently if needed. Non-default versions are available under explicitly named modules, for example:

  • rust_mcp_schema::mcp_2025_06_18
  • rust_mcp_schema::mcp_2025_11_25

πŸ“Œ Note: the three most recent schemas (2026_07_28, 2025_11_25 and draft) are also re-exported at the crate root and are therefore mutually exclusive β€” enable at most one of them at a time. Older versions (2025_06_18, 2025_03_26, 2024_11_05) are module-only and can be combined with any one of them.

Example: enable 2025-06-18 version of the schema:

# Cargo.toml
rust-mcp-schema = { version: 2.0.0 , default-features = false, features=["2025_06_18"] }

Example: enable `draft`` version of the schema :

#Cargo.toml
rust-mcp-schema = { version: 2.0.0 , default-features = false, features=["draft"] }

How are Schemas generated?

Schemas are generated from the official schema.ts and schema.json files available in the original Model Context Protocol (MCP) repository.

Using a customized version of typify, along with additional pre-processing and post-processing steps, the schema specifications are transformed into Rust code.

πŸ“Œ Note

The code used to generate schemas from schema.ts and schema.json is not included in this repository. However, I am considering making it available as a CLI tool in the future, allowing developers to generate MCP schemas as Rust code that can be directly integrated into their projects.

What is schema_utils?

The Rust implementations of the MCP schemas in this crate are automatically generated from the official MCP GitHub repository.

mcp_schema.rs provides all the core structures and enums with serialization/deserialization support, allowing you to use them as needed and extend their functionality.

To streamline development, improve compile-time type checking, and reduce the potential for errors, we’ve implemented utility types and functions that offer more strongly-typed objects and implementations, all without modifying the originally generated schema.

Please refer to schema_utils.rs for more details.

πŸ“Œ Note

Using schema_utils is optional. It is enabled by default through the schema_utils Cargo feature and can be used from rust_mcp_schema::schema_utils.

If you prefer not to use schema_utils, you can directly work with the enums and structs provided in mcp_schema.rs, adapting them to your needs and creating your own utility types and functions around them.

Visit Usage Examples (Without Using schema_utils) to see an alternative approach.

What does the schema_utils do?

The official schema defines a unified JsonrpcMessage type that encompasses all messages and notifications within the MCP protocol.

To enhance type safety and usability, schema_utils divides JsonrpcMessage into two distinct categories: ClientMessage and ServerMessage. Each category includes the relevant types for both standard and custom messages.

Please refer to schema_utils.rs and the Usage Examples section for more details.

Usage Examples

:point_right: The following examples focus solely on the serialization and deserialization of schema messages, assuming the JSON-RPC message has already been received in the application as a string.

Detecting a CallToolRequest Message on an MCP Server

The following code snippet demonstrates how an MCP message, represented as a JSON string, can be deserialized into a ClientMessage and how to identify it as a CallToolRequest message.

Note: ClientMessage represents MCP messages sent from an MCP client. The following code demonstrates how an MCP server can deserialize received messages from an MCP client.


pub fn handle_message(message_payload: &str) -> std::result::Result<(), RpcError> {
    // Deserialize message into ClientMessage.
    let message = ClientMessage::from_str(message_payload)?;

    // Check if the message is a Request
    if let ClientMessage::Request(client_request) = message {
        // Requests delegate to the schema-generated `ClientRequest` enum via `ClientJsonrpcRequest::Known`
        if let ClientJsonrpcRequest::Known(ClientRequest::CallToolRequest(call_tool_request)) = client_request {
            // Process the CallToolRequest (and eventually send a CallToolResult back to the client)
            handle_call_tool_request(call_tool_request);
        }
    }
    Ok(())
}

Refer to examples/mcp_server_handle_message.rs for a complete match implementation that handles all possible ClientMessage variants.

Creating a CallToolResult Response on an MCP Server.

In response to a CallToolRequest, the MCP Server is expected to return a CallToolResult message.

This code snippet demonstrates how to create a CallToolResult, serialize it into a string, and send it back to the client via the transport layer.

    // create a CallToolResult object (the builder sets `resultType: "complete"`)
    let tool_result = CallToolResult::text_content(vec![TextContent::new(
        "Sunny, 22Β°C in Paris.".to_string(),
        None,
        None,
    )]);

    // wrap it in a JSON-RPC response envelope addressed to the request's `id`
    let message = ServerJsonrpcResponse::new(RequestId::Integer(0), tool_result.into());

    // Serialize the MCP message into a valid JSON string for sending to the client
    let json_payload = serde_json::to_string(&message).unwrap();

    println!("{}", json_payload);

output:

{
  "id": 0,
  "jsonrpc": "2.0",
  "result": {
    "content": [{ "type": "text", "text": "Sunny, 22Β°C in Paris." }],
    "resultType": "complete"
  }
}
Detecting a CallToolResult Response Message in an MCP Client:
fn handle_message(message_payload: &str) -> std::result::Result<(), AppError> {
    // Deserialize message into ServerMessage.
    // ServerMessage represents a message sent by an MCP Server and received by an MCP Client.
    let mcp_message = ServerMessage::from_str(message_payload)?;

    // Check if the message is a Response type of message
    if let ServerMessage::Response(server_response) = mcp_message {
        // Check if it's a CallToolResult response
        if let ServerResult::CallToolResult(call_tool_result) = &server_response.result {
            // Process the CallToolResult
            handle_call_tool_result(call_tool_result);
        }
    }
    Ok(())
}

Refer to mcp_client_handle_message.rs for a complete match implementation that handles all possible ServerMessage variants.

Usage Examples (Without Utilizing schema_utils)

If you prefer not to use schema_utils, you can directly work with the generated types in your application or build custom utilities around them.

Detecting a CallToolRequest Message on an MCP Server (without schema_utils)

The following code example illustrates how to detect a CallToolRequest message on an MCP server:


fn handle_message(message_payload: &str) -> std::result::Result<(), AppError> {
    // Deserialize the JSON-RPC payload directly into ClientRequest.
    // Its `Deserialize` impl dispatches on the `method` field.
    let client_request: ClientRequest = serde_json::from_str(message_payload).unwrap();

    // Check it's a "tools/call" request
    if let ClientRequest::CallToolRequest(call_tool_request) = client_request {
        // Now that we can handle the message, we simply print out the details.
        println!("CallTool request received!");

        println!("Tool name : {:?} ", call_tool_request.params.name);
        println!("Arguments : {:?} ", call_tool_request.params.arguments);
    }

    Ok(())
}

Contributing

We welcome everyone who wishes to contribute! Please refer to the contributing guidelines for more details.

All contributions, including issues and pull requests, must follow Rust's Code of Conduct.

Unless explicitly stated otherwise, any contribution you submit for inclusion in rust-mcp-schema is provided under the terms of the MIT License, without any additional conditions or restrictions.

Runs on
GPU support unknown
What shows it
  • no dependency or feature matches a backend row
Native code
None found
  • No native code found
Python bindings
No Python binding crate found
License
MIT

Compare with similar projects

Order: strongest tier first, then most downloads, then name, with unmeasured values last. A library counts downloads over 30 days. An app counts binary downloads per release. An app with none counts its crate downloads over 30 days. ML Rust runs this catalogue, so its closest project always gets a row.

rust-mcp-schema beside the projects that share a topic with it
ProjectDownloadsDependentsStarsLatest releaseRuns on (GPU)Native codeLicense
rust-mcp-schema This page Featured

Type-safe implementation of the Model Context Protocol in Rust, designed to reduce errors and accelerate development with powerful utilities.

107,187 downloads over 30 days 19 79 2.0.0 GPU support unknown No native code found MIT
rmcp Featured

Rust SDK for Model Context Protocol

12,149,426 downloads over 30 days 2,400 4,101 3.9.0 GPU support unknown No native code found Apache-2.0
rust-mcp-sdk Featured

An asynchronous SDK and framework for building MCP-Servers and MCP-Clients, leveraging the rust-mcp-schema for type safe MCP Schema Objects.

29,764 downloads over 30 days 51 199 2.0.0 GPU support unknown No native code found MIT

actix-web transport implementations for RMCP (Rust Model Context Protocol)

27,030 downloads over 30 days 5 Not measured 0.13.2 GPU support unknown No native code found MIT
adk-rust Listed

Rust Agent Development Kit - Build AI agents in Rust with modular components for models, tools, memory, and more.

5,419 downloads over 30 days 25 743 2.3.0 CUDA, Metal Binds native code: alsa-sys (feature desktop-audio), audiopus_sys (feature openai-webrtc), cxx (feature livekit), espeak-rs-sys (feature kokoro), libsqlite3-sys (feature sqlite) and 4 more Apache-2.0
axp App Listed

An open protocol that gives AI agents a secure, sandboxed place to run code and use tools β€” with lean context usage. AXP works alongside MCP

Not measured Not applicable 3 Not measured Not measured Not measured Apache-2.0
Why FeaturedIt passes every Featured gate.

What it meets

  • It has 10 active dependents and 10 new dependents in 365 days. Featured needs 11 active dependents or 9 new dependents in 365 days.
  • Active dependents are at 100% of their peak. Featured needs at least 50%.
  • Docs are present. The release commit or a manifest ties the crate to the repository.
  • No vulnerability advisory stays unpatched past the grace window. At least one version is neither a prerelease nor 0.0.x.
  • The last activity is on 22 Aug 2026, 79 days ago. The rules expect an update within 400 days. Dormancy rule

Exact rules: Featured library. The check on applied thresholds version 9.

Every rule outcome, as the check records it
  • expected-interval: version 2.0.0 base 200, doubled for 107187 downloads per month: E = 400 days
  • dormancy: last activity 2026-08-22, 79 days ago, E = 400: active
  • featured: featured: active_users 10, new_adopters 10, former_glory 1

Measurements and sources

Each signal row shows the raw value, its source and the fetch date. The Sources list gathers every distinct source on this page. Movement needs more history.

Sources6 sources
Adoption10 active dependents, 10 new dependents in 365 days1 not measured
Adoption measurements
SignalValueSourceFetchedCounts
Active dependents10crates.io database dumpYes
New dependents (365 days)10crates.io database dumpYes
Peak active dependents10crates.io database dumpYes
Active dependents as a share of the peak1crates.io database dumpYes
Binary downloads per releaseNot measuredYes
MaintenanceLatest human commit: 2 months ago3 not measured
Maintenance measurements
SignalValueSourceFetchedCounts
Latest human commit2026-08-22GitHub repositoryYes
Latest release2026-08-22crates.io database dumpYes
First release2025-02-09crates.io database dumpYes
Latest version2.0.0crates.io database dumpYes
Days the oldest outside issue waits for a reply0GitHub repositoryYes
Maintainer replies over 365 days19GitHub repositoryYes
Repository archivedfalseGitHub repositoryYes
Repository gonefalseGitHub repositoryYes
Release commit or manifest in the repotruecrates.io packageYes
Published docstruecrates.io database dumpYes
Latest release fails cargo checkNot measuredYes
Build check dateNot measuredYes
Build check toolchainNot measuredYes
SecurityUnpatched vulnerabilities: none
Security measurements
SignalValueSourceFetchedCounts
Unpatched vulnerabilities past the grace windownoneRustSec advisory databaseYes
RustSec unmaintained advisorynoneRustSec advisory databaseYes
Deprecation noticenonecrates.io database dumpYes
Deprecated requirementnonecrates.io database dumpYes
Distribution41 releases, 107,187 downloads over 30 days5 not measured
Distribution measurements
SignalValueSourceFetchedCounts
Releases41crates.io database dumpYes
Downloads over 30 days107187crates.io database dumpYes
Binary downloads over the last 3 releasesNot measuredYes
Homebrew installs on request over 365 daysNot measuredYes
Repology repository familiesNot measuredYes
Docker pull growth over 90 daysNot measuredYes
Docker pulls at the growth baselineNot measuredYes
Every version a prereleasefalsecrates.io database dumpYes
Every version 0.0.xfalsecrates.io database dumpYes
Every version yankedfalsecrates.io database dumpYes
Crate deleted from crates.iofalsecrates.io database dumpYes
Repository79 stars, 5 forks, 2 contributors, 133 commits. Stars alone never qualify a project.
Repository measurements
SignalValueSourceFetchedCounts
GitHub stars79GitHub repositoryYes β€” one part of the repository route
GitHub forks5GitHub repositoryYes β€” one part of the repository route
Contributors with a GitHub account2GitHub contributorsYes β€” one part of the repository route
Commits on the default branch133GitHub repositoryNo
Repository's main crate left out of the entrynonecrates.io database dumpYes
Facts that never count
Facts that never count measurements
SignalValueSourceFetchedCounts
LicenseMITcrates.io database dumpNo
Runs on, from listed crates and their direct dependenciesGPU support unknowncrates.io database dumpNo
What shows each backendno dependency or feature matches a backend rowcrates.io database dumpNo
Native code, from listed crates and their dependenciesNo native code foundcrates.io database dumpNo
Python bindings, from direct dependencies of listed cratesNo Python binding crate foundcrates.io database dumpNo
Crates that depend on a listed crate directly19crates.io database dumpNo

Corrections and review history

Report a correction

No correction applies to this entry.

Judgments

A judgment enters only through an approved issue and a merged pull request.

No judgment applies to this entry.