{"id":56474,"date":"2025-04-16T13:30:00","date_gmt":"2025-04-16T20:30:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=56474"},"modified":"2025-04-16T13:26:57","modified_gmt":"2025-04-16T20:26:57","slug":"build-mcp-remote-servers-with-azure-functions","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/build-mcp-remote-servers-with-azure-functions\/","title":{"rendered":"Build MCP Remote Servers with Azure Functions"},"content":{"rendered":"

You can’t run to the grocery store these days without hearing about the Model Context Protocol (MCP)! Well, I hope the grocery store is your safe haven from AI, but the fact is that MCP is one of the hottest and most talked about topics in software development. And I’m going to keep talking about it because I want to show you a brand new experimental preview feature of Azure Functions that takes a ton of work out of creating remote MCP Servers and brings all the goodness of Azure Functions to the equation too.<\/p>\n

\ud83d\udce5 Get the code!<\/a><\/div><\/p>\n

What’s MCP anyway?<\/h2>\n

The Model Context Protocol is nothing more than a specification that makes it easier for AI applications to talk to tooling of some sort.<\/p>\n

And generally speaking, that tooling will provide\/expose some core business functionality. Like maybe an API of sorts that stores and returns data from Azure Blob Storage.<\/p>\n

So here’s the situation: you’re going to have a chat interface of some sort that uses an LLM. How do you get it so that when the LLM is responding to a prompt it knows to invoke the tooling? That’s where MCP comes in.<\/p>\n

But MCP is a spec – and that means you have to implement it yourself. And plumbing code is no fun. So that’s what I’m really<\/em> here to show you today, how to create a remote MCP server using Azure Functions.<\/p>\n

Remote vs local MCP servers<\/h3>\n

You may have noticed I’m being very intentional to specify remote MCP server<\/em>. And there’s a reason for that.<\/p>\n

Right now the most common scenario that involves MCP is a client running locally, like VS Code or Claude Desktop, that has an extension that acts the MCP client (think GitHub Copilot for VS Code) that uses an LLM to call a MCP server also running locally. The MCP server is usually hosted in a Docker container.<\/p>\n

But it gets old pretty quickly to install the same MCP server locally everywhere you may need it. Much less making sure people on your team have the same version installed – it’s like taking care of a desktop app.<\/p>\n

Remote MCP servers run remotely. As long as the endpoint supports server-side events (SSE), you’re good to go.<\/p>\n

Azure Functions remote MCP servers<\/h2>\n

Azure Functions is an event-based serverless product. To me, the defining feature of Functions is its ability to seamlessly integrate with other Azure services just be adding attributes to the function definition.<\/p>\n

For example, if you want to write to a blob in Azure Storage just decorate your function definition with [BlobOutput(blobPath)]<\/code> and whatever value you return from the function gets written to the blob specified in blobPath<\/code>.<\/p>\n

The Functions team recently released an experimental preview that turns a function app into a MCP Server via a [MCPToolTrigger]<\/code> attribute. So now it’s amazingly simple to build an MCP server by using the straightforward development experience of Azure Functions and<\/em> you still get all the great Azure integration you’ve come to expect too!<\/p>\n

Let’s explore an Azure Functions MCP server<\/h3>\n

Instead of doing a file->new sample, let’s start from one that’s already ready to go and explore its defining characteristics. Head over to the Remote MCP Functions Sample<\/a> repo to fork\/clone\/download or just follow along with the code.<\/p>\n

This function app lets users highlight text in the editor of VS Code and ask GitHub Copilot to save it with a name. You can then retrieve it using the name you saved it as.<\/p>\n

First things first. If you open up the FunctionsMcpTool.csproj<\/strong> you’ll see that there’s a NuGet package called Microsoft.Azure.Functions.Worker.Extensions.Mcp<\/strong>. This is the one that adds all the MCP-ness to the Function app.<\/p>\n

Now checkout Program.cs<\/strong>. See the line builder.EnableMcpToolMetaData()<\/code>? That’s going to expose the metadata of each function, like name and description, to the client so the LLM is able to figure out when to invoke it.<\/p>\n

Head on over to SnippetsTool.cs<\/strong>. There are 2 functions here. SaveSnippet<\/strong> adds text as a blob to Azure Storage. And the other, GetSnippet<\/strong> returns the text stored in the blob.<\/p>\n

Let’s see how to save some text as a blob:<\/p>\n

[Function(nameof(SaveSnippet))]\r\n[BlobOutput(BlobPath)]\r\npublic string SaveSnippet(\r\n    [McpToolTrigger(SaveSnippetToolName, SaveSnippetToolDescription)]\r\n        ToolInvocationContext context,\r\n    [McpToolProperty(SnippetNamePropertyName, PropertyType, SnippetNamePropertyDescription)]\r\n        string name,\r\n    [McpToolProperty(SnippetPropertyName, PropertyType, SnippetPropertyDescription)]\r\n        string snippet\r\n)\r\n{\r\n    return snippet;\r\n}<\/code><\/pre>\n
Let’s explain this a bit as there’s a lot of constants being passed in to the properties.<\/p>\n