From Code to Agents: Build Production MCP Servers on Azure Functions

Summary: Building Production-Grade MCP Servers with Azure Functions

This talk is a replay of a lightning session (Microsoft Build 2026) focused on building production-grade MCP servers using Azure Functions. The speaker’s theme is “From Code to Agents”—starting with code and infrastructure, then building AI agents that can act as practical DevOps assistants.

---

Core Problem: AI/Agents Don’t Automatically Reduce Complexity

The speaker frames a key issue: adding AI into production systems does not reduce complexity—it can actually increase it due to:

• More integrations
• More moving parts
• More failure points (i.e., more places where things can break)
• Harder troubleshooting when agents are separated/distributed from existing apps

A major challenge highlighted is that agents can run outside the normal application boundary, which complicates debugging and monitoring, especially if monitoring is weak.

---

Proposed Solution: DevOps Automation with AI Agents

The proposed approach is to use AI agents for DevOps automation—specifically to handle CI/CD failures automatically, with an option for human approval.

Example scenario

If a developer merges a change that breaks CI/CD (e.g., build failure or bad deployment), and admins aren’t watching at odd hours, the system should:

1. Identify the failure
2. Determine the last known good state
3. Create an automated rollback PR to restore production safely

This rollback PR prevents production breakage by reverting to the last successful commit.

---

Architecture Highlights: Azure + MCP + Foundry + DevOps

MCP as the communication contract

MCP (Model Context Protocol) is used as the contract between:

• A reasoning agent (planning and decision-making based on language/conditions)
• A tool agent implemented as a self-hosted MCP server via Azure Functions

Azure Functions as the MCP tool server

The speaker uses Azure Functions with an MCP tool trigger extension to host MCP endpoints.

Azure Functions benefits emphasized

• Flex consumption / pay-as-you-go pricing model (avoids always paying fixed premium)
• .NET isolated functions
• Identity/auth integration using Microsoft Entra ID / Managed Identity, reducing dependence on PATs/shared keys

Microsoft Foundry for the model

The agents rely on Microsoft Foundry (mentioned as the branding for “Microsoft Azure AI / Azure AI services”) to provide the model used by the reasoning agent.

• The demo uses the cheapest model
• The speaker notes models can be selected programmatically (including stronger options)

---

Agent Design: Two-Agent Setup

1) Reasoning Agent

• Uses Microsoft Foundry
• Contains declarative prompts/conditions embedded in code
• Decides:
  • which tool to call
  • how to interpret failures
• Runs in a hosted MCP style

2) Tool Agent (Azure Functions MCP Server)

Exposes three MCP-callable tool methods for the reasoning agent to invoke:

• Get recent deployments (e.g., list deployments/builds; inputs include repo name + branch)
• Diagnose issues (identify build/deployment failures)
• Create rollback PR agent (create a rollback PR for failed deployments)

---

CI/CD Integration and Runtime Flow

Pipeline sources

CI/CD is built around Azure DevOps Pipelines and/or GitHub Actions, though the demo emphasizes Azure DevOps.

What happens on failure

When a build/deploy fails, the tool agent can:

• Find the last successful (“known good”) commit
• Open a rollback PR against that commit
• In production mode, require human-in-the-loop approval before merging

Runtime sequence described

1. The reasoning agent requests the latest failing PR/deployment
2. It calls the MCP server (Azure Functions)
3. The tool agent selects the correct method (diagnose vs rollback)
4. The system creates the rollback PR using diagnosis results

---

Observability

• Local development: Aspire dashboard for logging/tracing/telemetry
• Production: Application Insights

---

Security and Compliance Layers

The speaker emphasizes guardrails and security by design, including:

• Input validation (e.g., rejecting invalid repo/branch inputs)
• Approval policy
  • Demo mode: auto-revert/create PR without human approval
  • Production mode: human approval required
• Transport/identity security
  • Managed Identity scopes for rollback access
• Policies and security review to reduce risky automation
• An integration goal to reduce reliance on PAT tokens

---

Demo Implementation (Rollback “Lawrence” Agents)

A simulated application is built to demonstrate the workflow:

• Front-end UI hosted on Azure App Service
• Back-end implemented as Azure Functions MCP tools and agent orchestration

Demo steps (example flow)

• Detect failure in a specific pipeline/repo/branch (example: Shop API main failing)
• Identify root cause (example: migration timeout due to database changes on the orders table)
• Create a rollback PR (example referenced as “PR number 3”)
• In demo mode, the PR can be configured to be auto-reverted/auto-merged after the review step shown

---

Key Takeaways

• MCP turns tools into a contract usable by AI agents, helping avoid writing custom SDK/primers for each tool.
• An Azure Functions MCP server integration is positioned as production-ready, especially with built-in authentication / managed identity.
• Microsoft Foundry enables building/managing agent models and integrating them into .NET/Azure apps.
• The demo shows how two agents (reasoning + tool) can perform DevOps rollback automation when CI/CD failures occur—and this can be done today.

---

Main Speaker / Source

• Jonah Anderson — Microsoft MVP for Azure; described as a .NET full-stack developer and Azure community/content creator