Free tool

REST API to MCP Server in Rust

What it actually takes to expose a REST API as an MCP server in Rust — the SDK, a working tool, and the part that decides whether an agent uses it correctly.

Official SDK modelcontextprotocol/rust-sdk (rmcp)
Install
cargo add rmcp
A working MCP tool in Rust 
#[derive(Debug, Deserialize, JsonSchema)]
struct GetOrderArgs {
    /// The order id to look up
    order_id: String,
}

#[tool_router]
impl MyServer {
    #[tool(description = "Look up one order by its id and return its current status.")]
    async fn get_order(&self, Parameters(args): Parameters<GetOrderArgs>)
        -> Result<CallToolResult, McpError> {
        Ok(CallToolResult::success(vec![Content::text(fetch_order(&args.order_id).await)]))
    }
}
Test what you built Generate tools from an OpenAPI spec

It runs. Nobody else can see that.

A working server is where the effort ends and the selling starts. Point MCP Showcase at it and get a live playground your customers can try, with documentation generated for every tool.

Start for Free Explore the MCP server directory

How it works

link
Install the SDK

Shown above, along with whether it is officially maintained or a community project — which matters more in some languages than others.

play_circle
Wrap one endpoint

Start with a single tool, not your whole API. Tool definitions are sent to the model on every request, and selection accuracy falls as the list grows.

checklist
Test it before you connect an agent

Run the deployed URL through the MCP Inspector to confirm the handshake completes and the tools appear as you intended.

The Rust SDK

cargo add rmcp — modelcontextprotocol/rust-sdk (rmcp), officially maintained.

Async runtime and schema derivation are both explicit

rmcp is built on Tokio and derives schemas via schemars, so both the runtime and the schema derivation are choices you make rather than defaults you inherit. Expect more setup than Python for the same server, and expect the compiler to catch the schema mistakes the other SDKs discover at runtime.

Wrapping a REST endpoint

An MCP server is a thin layer over code you already have. Each tool needs three things: a name, a description saying what it does and when to choose it, and an input schema. The Rust SDK handles the protocol; what you write is the mapping from those arguments to your existing HTTP call.

Start with one endpoint rather than your whole API. Tool definitions are re-sent to the model on every single request, so each one is a permanent context cost, and the model's ability to pick correctly falls as the list grows. Eight well-described tools beat eighty.

The part that is not about Rust

Whatever language you use, the descriptions decide whether the agent behaves. They are read by the model, not by your colleagues, and a tool described in three words gets called by guesswork. You can check yours with the MCP schema linter, and see what the list costs per request with the token calculator.

Related tools and guides

A working server is half the job

Once it runs, the remaining problem is that nobody can tell what it does. A prospect cannot read your Rust source and will not install a client to find out. MCP Showcase points at the same URL and produces a live playground with generated documentation for every tool, so evaluating your server takes a click.

Frequently asked questions

Wrap each endpoint you want an agent to reach in a tool: a name, a one-sentence description of what it does and when to use it, and an input schema. The Rust SDK handles the protocol; what you write is the mapping from tool arguments to your existing HTTP call.

No, and this is the most common mistake. Tool definitions are re-sent on every single request, so eighty endpoints is eighty descriptions in the context window of every turn — and the model's ability to pick the right one drops sharply as the list grows. Start with the few an agent genuinely needs.

The badge above the code says which. Where there is no official SDK, community options vary in how closely they track the spec — check when the library last followed a protocol revision, particularly around transports, before you build on it.

Streamable HTTP for anything deployed. Clients increasingly try it first and some no longer fall back to the older HTTP+SSE transport, which shows up as a client that simply cannot see your server rather than as an error.

You cannot tell by reading your own code, because you already know what the tools do. Run the server through the schema linter: it checks the descriptions and input schemas the way a model reads them and flags the ones that would make an agent guess.

More free MCP tools

MCP Inspector Online

Paste an MCP server URL and see every tool, resource and prompt it exposes, with full schemas and the raw request log. Nothing to install.
MCP Server Tester

Check that your MCP server actually works. Paste the URL and get a pass/fail report on the connection, the handshake, the transport and the tools it advertises.
MCP Security Scanner

Before you point an agent at an MCP server, see what it is asking for. Graded A–F on transport, authentication, tool-poisoning markers and dangerous parameters.
MCP Token Calculator

Tool definitions are sent on every request, not once. Paste your MCP server URL to see how many tokens that is, which tools are the heaviest, and what it costs.
See all free tools