Azure Functions Now Supports Model Context Protocol: What This Means for Your AI Agents
Azure Functions Now Supports Model Context Protocol: What This Means for Your AI Agents
TL;DR Microsoft has moved its Model Context Protocol (MCP) support for Azure Functions to General Availability, signaling a shift toward standardized, identity-secure agentic workflows. For .NET engineers, this means you can now build production-grade AI agents that safely access enterprise data without reinventing the security wheel.
The Problem: Why MCP Matters Right Now
If you’ve been building AI agents in 2025, you’ve hit the same wall everyone else has: connecting your LLM to real enterprise systems without either (a) leaking credentials or (b) building custom auth logic for every tool integration. Anthropic’s Model Context Protocol (MCP), a “USB-C for AI” that lets AI agents talk to the external tools like databases, search engines, and APIs, proved the missing connective tissue and is quickly becoming the standard. OpenAI and Microsoft have publicly embraced MCP, and Anthropic recently donated it to the Linux Foundation’s new Agentic AI Foundation, which aims to help standardize open source agentic tools. Translation: this is no longer a nice-to-have. It’s infrastructure.
What’s New: Azure Functions MCP Support (GA)
By integrating native OBO authentication and streamable HTTP transport, the update aims to solve the ‘security pain point’ that has historically prevented AI agents from accessing sensitive downstream enterprise data. Here’s what that means in practice:
Language Support
The MCP extension, which entered public preview in April 2025, now supports .NET, Java, JavaScript, Python, and TypeScript, while a new self-hosted option lets developers deploy existing MCP SDK-based servers without code changes.
Security Built-In
No more passing API keys around.
By integrating native OBO (On-Behalf-Of) authentication and streamable HTTP transport, the update aims to solve the security pain point that has historically prevented AI agents from accessing sensitive downstream enterprise data.
Your Azure Functions can authenticate as the user calling the agent, not as a shared service principal.
Implementation: Getting Started with .NET
If you’re building in C# or .NET, here’s the shape of what you’ll do:
// 1. Create an MCP server in Azure Functions
[FunctionName("MyMcpServer")]
public async Task Run(
[HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = "mcp")] HttpRequest req,
ILogger log)
{
// MCP handles the protocol handshake
// Your function logic accesses Azure resources via managed identity
var client = new SecretClient(
new Uri("https://myvault.vault.azure.net/"),
new DefaultAzureCredential()); // OBO auth built-in
var secret = await client.GetSecretAsync("my-secret");
// Return tool response to agent
}
Nested arrays and complex types must be serialized as comma-separated strings when integrating with Azure AI Foundry, and programmatic tool approval using require_approval=”never” is necessary for production workflows since UI-based approvals don’t persist in automated deployments.
Cost & Scaling Considerations
This is where Azure Functions shine for agentic workloads: The Flex Consumption plan provides automatic scaling based on demand with a pay-per-execution billing model and scale-to-zero economics. When MCP tools sit idle, costs drop to zero while maintaining fast wake-up times. However, there’s a latency trade-off. The Premium plan supports “always-ready” instances that remain pre-initialized, eliminating cold-start latency, which is critical for mission-critical tools where initialization delays can cause SSE connection timeouts and poor agent response times. Quick decision tree:
- Flex Consumption: Bursty, cost-optimized agent tools (e.g., occasional data lookups). Best for dev/test.
- Premium: Always-on tools where agent latency matters (e.g., real-time chat assistants). Budget ~$250–$500/month per instance.
Why This Matters for Your Stack
Microsoft introduced: Semantic Kernel (SK) → tools for orchestrating prompts, memories, and plugins using C# or Python · Microsoft Extensions for AI (MEAI) → unified abstractions for interacting with models (e.g., IChatClient) Now you can wire those abstractions directly to secure, scalable Azure Functions via MCP. No more custom HTTP clients or OAuth plumbing. The Microsoft Foundry resource type provides a superset of capabilities compared to the Azure OpenAI resource type. It gives you access to a broader model catalog, agents service, and evaluation capabilities.
The Bigger Picture
With MCP reducing the friction of connecting agents to real systems, 2026 is likely to be the year agentic workflows finally move from demos into day-to-day practice. This GA release is Microsoft’s bet that .NET developers will lead that transition. And with OBO auth, managed identity, and scale-to-zero pricing baked in, it’s a credible one.
Further reading
https://www.infoq.com/news/2026/01/azure-functions-mcp-support/
https://devblogs.microsoft.com/dotnet/generative-ai-with-large-language-models-in-dotnet-and-csharp/
https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/upgrade-azure-openai?view=foundry-classic
https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/unlocking-hugging-face-gated-models-in-microsoft-foundry/4485722
https://techcrunch.com/2026/01/02/in-2026-ai-will-move-from-hype-to-pragmatism/
https://devblogs.microsoft.com/all-things-azure/the-realities-of-application-modernization-with-agentic-ai-early-2026/