Free tool

REST API to MCP Server in C#

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

Official SDK modelcontextprotocol/csharp-sdk
Install
dotnet add package ModelContextProtocol
A working MCP tool in C# 
[McpServerToolType]
public static class OrderTools
{
    [McpServerTool, Description("Look up one order by its id and return its current status.")]
    public static async Task<string> GetOrder(
        IOrderService orders,
        [Description("The order id to look up")] string orderId)
        => await orders.FetchAsync(orderId);
}
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 C# SDK

dotnet add package ModelContextProtocol — modelcontextprotocol/csharp-sdk, officially maintained.

Attributes plus dependency injection

Tools are marked with attributes and resolved through the standard .NET DI container, so a tool can take injected services as parameters alongside its model-supplied arguments. That is convenient and it is also the easiest way to accidentally expose an internal service through a tool signature -- check what is actually reachable from each one.

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 C# 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 C#

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 C# 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 C# 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