Your First MCP Server in .NET — From Zero to Hello Tool

 

Hello Sitecorian Community! 👋

Before building anything Sitecore-specific, I needed to understand MCP from the ground up. Jumping straight to a Sitecore integration without that foundation would mean debugging two things at once — the Sitecore layer and the MCP layer. That is a reliable recipe for confusion.

So step one was this: build the smallest possible working MCP server in .NET, connect it to GitHub Copilot, and see a single tool call succeed. That mental model turned out to be everything that followed.

The guide I followed was Microsoft’s official quickstart:
📘 Create a minimal MCP server using C# — Microsoft Learn

Understanding the project structure first

Before diving into the steps, it helps to understand what a .NET MCP server project actually contains. The template generates four key files:

MyFirstMcpServer — scaffolded projectProgram.csDefines the app as an MCP serverSets transport type (stdio / http)RandomNumberTools.csSample tool — returns a randomnumber between min / max valuesserver.jsonDefines how and where the serveris published (NuGet)[ServerName].httpHTTP transport only — defaulthost address for remote server

The four files generated by the MCP Server App template. Program.cs and the tools file are the two you'll spend most time in

Prerequisites

• .NET 10.0 SDK — required; the MCP project templates won’t install on earlier versions
• Visual Studio Code
• C# Dev Kit extension for VSCode (ms-dotnettools.csdevkit)
• GitHub Copilot extension for VSCode (GitHub.copilot)
• A NuGet.org account — only if you want to publish; skip for local experiments

Note: The Microsoft.McpServer.ProjectTemplates package is currently in preview. It works well, but always check the official docs for the latest before you start.

Step-by-step setup

Step-by-step setup

1. Install the MCP Server project templateOpen a terminal and run:

dotnet new install Microsoft.McpServer.ProjectTemplates

This adds the MCP Server Apptemplate to your .NET tooling. You won’t see it in the project list until this step is done. .NET 10.0 SDK or later is required.

2. Create the project in VSCode

Open VSCode and bring up the Command Palette (Ctrl+Shift+P on Windows/Linux, Cmd+Shift+P on Mac). Type .NET: New Project and select it. In the template list that appears, search for

MCP Server App and select it. Choose a location, give your project a name — I used MyFirstMcpServer — and press Enter.

3. Choose your template optionsYou’ll be prompted to configure:

• Framework: Select .NET 10
• Transport type: Choose stdio(local process) for your first experiment. It communicates via standard input/output and needs no web hosting setup. 
• Choose http only if you need a remotely accessible server
• Native AOT / Self-contained: Leave as defaults for now

4. Read the scaffolded code before changing anything

VSCode opens your new project. Spend five minutes reading through Program.cs and RandomNumberTools.cs before modifying anything. The template gives you a working server with a sample tool already registered. That structure — the attribute decoration, the description, the method signature — is the pattern you will repeat for every tool you build later.

5. Connect Copilot and test a tool call 

Open GitHub Copilot in VSCode and switch it to Agent mode. 

Click the tool icon at the bottom of the Copilot panel. Your MCP server should appear in the list of available tools. If it doesn’t, restart VSCode and try again. Once it appears, type a prompt that exercises the sample tool. Copilot will ask permission to run it — click Continue. When you see the tool execute and return a result inside the Copilot response, you have done it.

6. Update PackageId if publishing to NuGet (optional)

If you want to publish your server as a NuGet package, update the <PackageId> in your .csproj to something unique:

<PackageId>YourNuGetUsername.SampleMcpServer</PackageId>

Not required for local use.

What the transport types actually mean

stdio transportLocal process, stdin/stdoutIDE / Copilot.exe✓ No web server needed✓ Simplest to get started — Local machine onlyhttp transportRemote web serviceIDE / CopilotHTTP API✓ Shareable across a team✓ Works remotely — Needs hosting setup

stdio vs http transport. For a first experiment, stdio is the right choice. Switch to http when you need to share the server across a team or access it remotely

Three things this exercise taught me

Tools are the entire model. An MCP server is a collection of tools. Each tool has a name, description, typed inputs, and a return value. The AI model reads those descriptions to decide which tool to call. That is the whole protocol — no magic underneath.

The transport layer is a deployment decision, not a logic decision. stdio vs http changes how clients connect to your server. The tools themselves work identically in both modes. Start with stdio locally; reach for http when you need remote access or team sharing.

Clear descriptions drive reliable routing. In the sample tool, the description is short and precise. I learned the hard way later that vague descriptions cause the AI to call the wrong tool or ignore it entirely. Write descriptions as if you are explaining to a teammate what this function does and when exactly to use it.

Quick tip: after getting the sample tool working, try modifying the RandomNumberTools.cs description to something vague, then ask Copilot the same prompt. You will see immediately how much description quality affects routing reliability.

Till then, Happy Sitecoring! 😊