MCP server on Azure Functions

HTTP trigger for MCP: basic implementation

Create your Function App in the Azure portal or with the Azure CLI, then add an HTTP trigger for the MCP endpoint. The Node.js v4 programming model (recommended for new projects) uses a simpler function registration API than v3:

// src/functions/mcp.ts — MCP server as an Azure HTTP trigger (Node.js v4 model)
import { app, HttpRequest, HttpResponseInit, InvocationContext } from "@azure/functions";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
import { z } from "zod";

const createMcpServer = (context: InvocationContext) => {
  const server = new McpServer({ name: "azure-mcp", version: "1.0.0" });

  server.tool(
    "list_storage_blobs",
    "List blobs in an Azure Storage container",
    { container: z.string(), prefix: z.string().optional() },
    async ({ container, prefix }) => {
      // Azure SDK — uses Managed Identity or connection string from Key Vault reference
      const { BlobServiceClient } = await import("@azure/storage-blob");
      const client = BlobServiceClient.fromConnectionString(
        process.env.AZURE_STORAGE_CONNECTION_STRING!
      );
      const containerClient = client.getContainerClient(container);
      const blobs: string[] = [];

      for await (const blob of containerClient.listBlobsFlat({ prefix })) {
        blobs.push(blob.name);
        if (blobs.length >= 100) break; // Prevent unbounded listing
      }

      return { content: [{ type: "text", text: JSON.stringify(blobs) }] };
    }
  );

  server.tool(
    "query_cosmos",
    "Query Azure Cosmos DB",
    { container: z.string(), query: z.string() },
    async ({ container, query }) => {
      const { CosmosClient } = await import("@azure/cosmos");
      const client = new CosmosClient({ endpoint: process.env.COSMOS_ENDPOINT!, key: process.env.COSMOS_KEY! });
      const database = client.database(process.env.COSMOS_DATABASE!);
      const { resources } = await database.container(container).items.query(query).fetchAll();
      return { content: [{ type: "text", text: JSON.stringify(resources, null, 2) }] };
    }
  );

  return server;
};

app.http("mcp", {
  methods: ["POST"],
  authLevel: "anonymous",  // Use Azure AD authentication at the API Management layer instead
  route: "mcp",
  handler: async (request: HttpRequest, context: InvocationContext): Promise<HttpResponseInit> => {
    const server = createMcpServer(context);
    const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: () => crypto.randomUUID() });
    await server.connect(transport);

    // Convert Azure HttpRequest to standard Fetch API Request
    const req = new Request(request.url, {
      method: request.method,
      headers: Object.fromEntries(request.headers.entries()),
      body: request.method !== "GET" ? await request.text() : undefined,
    });

    const response = await transport.handleRequest(req);

    return {
      status: response.status,
      headers: Object.fromEntries(response.headers.entries()),
      body: await response.text(),
    };
  },
});

{
  // host.json — Azure Functions host configuration
  "version": "2.0",
  "logging": {
    "applicationInsights": {
      "samplingSettings": { "isEnabled": true, "excludedTypes": "Request" }
    }
  },
  "extensions": {
    "http": {
      "routePrefix": "api",
      "maxConcurrentRequests": 100,
      "maxOutstandingRequests": 200,
      "dynamicThrottlesEnabled": true
    }
  },
  "functionTimeout": "00:05:00"  // 5-minute max per invocation on Consumption Plan
}

Consumption Plan vs Premium Plan for MCP

The hosting plan decision is the most impactful architectural choice for Azure Functions MCP servers:

For MCP servers in enterprise agent pipelines, cold starts are a significant problem. A 3-second cold start on the first tool call of an agent run adds latency that compounds through multi-step agent workflows. The Premium Plan's pre-warmed instance eliminates this at the cost of ~$150/month baseline — often justified for production agent infrastructure.

If you must use Consumption Plan in production, mitigate cold starts with "keep-warm" pings from your monitoring tool. AliveMCP pings every 60 seconds, which is frequent enough to keep a Consumption Plan function warm during active business hours (Lambda/Function instances typically idle after 15–20 minutes of inactivity).

Durable Functions for long-running tool orchestration

Durable Functions extend Azure Functions with stateful orchestration — a checkpoint-based execution model that survives crashes, timeouts, and VM restarts. For MCP servers with tools that orchestrate multi-step operations (data pipelines, document processing, multi-service aggregation), Durable Functions replace the start/poll async dispatch pattern with a more elegant actor model:

// src/functions/report-orchestrator.ts — Durable Function orchestration
import { app, OrchestrationContext, ActivityHandler } from "@azure/functions";
import * as df from "durable-functions";

// Activity functions: individual steps that can be retried independently
const fetchDataActivity: ActivityHandler = async (input: { datasetId: string }) => {
  const res = await fetch(`${process.env.DATA_API}/datasets/${input.datasetId}`);
  return await res.json();
};

const processDataActivity: ActivityHandler = async (input: { raw: unknown }) => {
  // CPU-intensive processing — runs in a separate activity invocation
  return transformData(input.raw);
};

const generatePdfActivity: ActivityHandler = async (input: { data: unknown, reportId: string }) => {
  const pdf = await renderPdf(input.data);
  // Store in Azure Blob Storage
  await uploadToBlob(`reports/${input.reportId}.pdf`, pdf);
  return `reports/${input.reportId}.pdf`;
};

// Register activity functions
app.activity("fetchData", { handler: fetchDataActivity });
app.activity("processData", { handler: processDataActivity });
app.activity("generatePdf", { handler: generatePdfActivity });

// Orchestrator function: coordinates the workflow
df.app.orchestration("reportOrchestrator", function*(context: OrchestrationContext) {
  const { datasetId, reportId } = context.df.getInput<{ datasetId: string; reportId: string }>();

  const raw = yield context.df.callActivity("fetchData", { datasetId });
  const processed = yield context.df.callActivity("processData", { raw });
  const pdfPath = yield context.df.callActivity("generatePdf", { data: processed, reportId });

  return { status: "complete", pdfPath };
});

// MCP tool that starts the orchestration and returns an instance ID for polling
// (in your main mcp.ts HTTP trigger)
server.tool(
  "start_report",
  "Start a long-running report generation",
  { datasetId: z.string() },
  async ({ datasetId }) => {
    const client = df.getClient(context);  // context from Azure Function invocation
    const reportId = crypto.randomUUID();
    const instanceId = await client.startNew("reportOrchestrator", { input: { datasetId, reportId } });
    return { content: [{ type: "text", text: `Report started. Instance: ${instanceId}. Call check_report to poll status.` }] };
  }
);

server.tool(
  "check_report",
  "Check the status of a running report",
  { instanceId: z.string() },
  async ({ instanceId }) => {
    const client = df.getClient(context);
    const status = await client.getStatus(instanceId);
    return {
      content: [{
        type: "text",
        text: JSON.stringify({ runtimeStatus: status.runtimeStatus, output: status.output }),
      }]
    };
  }
);

The key advantage of Durable Functions over a simple async dispatch: if the Azure Function host crashes mid-orchestration (VM restart, deployment), the orchestration resumes from the last checkpoint when the host comes back up. Your MCP client can poll check_report and eventually get a result even if the underlying compute restarted mid-processing.

Azure Key Vault for MCP server secrets

Azure Key Vault references in Function App settings let you store secrets in Key Vault while accessing them as standard environment variables in your function — no Key Vault SDK calls in your tool code:

# Azure CLI: configure Key Vault reference in Function App settings
# 1. Create a Key Vault secret
az keyvault secret set \
  --vault-name my-keyvault \
  --name "database-connection-string" \
  --value "postgresql://user:password@host:5432/dbname"

# 2. Enable System Assigned Managed Identity on the Function App
az functionapp identity assign \
  --name my-mcp-function-app \
  --resource-group my-rg

# 3. Grant the Function App read access to Key Vault
az keyvault set-policy \
  --name my-keyvault \
  --object-id $(az functionapp identity show --name my-mcp-function-app --resource-group my-rg --query principalId -o tsv) \
  --secret-permissions get

# 4. Set the app setting to a Key Vault reference
az functionapp config appsettings set \
  --name my-mcp-function-app \
  --resource-group my-rg \
  --settings "DATABASE_URL=@Microsoft.KeyVault(VaultName=my-keyvault;SecretName=database-connection-string)"

// In your tool handler — just use process.env, Key Vault reference is transparent
server.tool("query_db", "Query the database", { sql: z.string() }, async ({ sql }) => {
  // process.env.DATABASE_URL is automatically resolved from Key Vault at startup
  const pool = new Pool({ connectionString: process.env.DATABASE_URL });
  const result = await pool.query(sql);
  await pool.end();
  return { content: [{ type: "text", text: JSON.stringify(result.rows) }] };
});

Key Vault references are resolved at Function App startup, not per-invocation. If the Key Vault reference is invalid or the Managed Identity doesn't have access, the Function App fails to start and all tool calls fail with a 500 error. AliveMCP's external probe catches this immediately — a failed initialize response after a deployment that changed Key Vault access is a fast signal that permissions need review.

Application Insights and AliveMCP: complementary monitoring

Application Insights (Azure Monitor) provides deep internal telemetry — function execution duration, dependency calls, exception traces, and custom metrics. AliveMCP provides external protocol-level monitoring — what a real agent client experiences when calling your MCP endpoint. The two are complementary:

// Add custom Application Insights telemetry from tool handlers
import { defaultClient as appInsightsClient } from "applicationinsights";

server.tool("search_index", "Search the Azure Cognitive Search index", { query: z.string() }, async ({ query }) => {
  const start = Date.now();
  const results = await searchIndex(query, process.env.SEARCH_KEY!);
  const duration = Date.now() - start;

  // Track custom metric — visible in Application Insights Metrics
  appInsightsClient.trackMetric({ name: "mcp_tool_search_duration_ms", value: duration });
  appInsightsClient.trackEvent({ name: "mcp_tool_call", properties: { tool: "search_index", query } });

  return { content: [{ type: "text", text: JSON.stringify(results) }] };
});

Further reading

• MCP server on Netlify Functions — serverless constraints and timeout patterns
• MCP server on Cloudflare Workers — edge deployment and V8 isolates
• MCP server with AWS Bedrock — tool integration and Lambda patterns
• MCP server secrets management — Key Vault, environment variables, and rotation
• MCP server SAML SSO — Azure AD enterprise authentication
• MCP server SLA — uptime commitments and Azure hosting plan selection
• AliveMCP — continuous protocol monitoring for MCP servers