You have built an AI agent. It can reason about user input, call tools, and produce structured output. Now you need it to list the blobs in a storage account, query Application Insights for error spikes, or restart an App Service slot. The options are not inspiring: shell out to the Azure CLI, wrap the management SDK in custom tool definitions, or bolt together a chain of REST calls with hand-rolled authentication. None of these approaches scale well when the agent needs to interact with dozens of Azure services, and none of them give you a consistent security boundary.

Azure MCP Server 2.0, which reached general availability on 10 April 2026, is Microsoft's answer to this problem. It implements the Model Context Protocol (MCP) specification and exposes 276 tools across 57 Azure services as structured, discoverable operations that any MCP-compatible client can invoke. The headline feature in 2.0 is self-hosted remote deployment — the server can now run as a centralised service behind your network boundary, with proper authentication and governance, rather than being limited to a local stdio process on each developer's machine.

What MCP actually gives you

The Model Context Protocol is an open standard that defines how language models interact with external tools. An MCP server advertises a catalogue of tools — each with a name, description, input schema, and metadata annotations — and an MCP client (your agent, IDE, or orchestration framework) discovers and invokes them. The protocol handles serialisation, transport, and capability negotiation so that neither side needs to know implementation details about the other.

Azure MCP Server is a concrete implementation of this protocol for Azure. Instead of writing bespoke tool definitions for every Azure operation your agent might need, you point your client at the MCP server and it exposes everything from blob storage management to Cosmos DB queries to Key Vault secret retrieval as ready-to-use tools.

The practical benefit is that a single natural-language prompt like "show me all resource groups in subscription X" resolves to the correct tool invocation, parameters, and authentication flow without you writing a line of glue code.

What changed in 2.0

The 1.x releases ran exclusively as a local process using stdio transport. That worked for individual developer workflows — connect your IDE, ask questions about your Azure resources — but it fell apart in shared environments. Every developer needed the server running locally, every machine needed Azure credentials, and there was no way to enforce consistent configuration or audit tool usage.

Version 2.0 introduces HTTP-based transport with proper authentication support. The server can run as a remote service that multiple clients connect to over the network. This opens up several deployment patterns:

Authentication

Remote deployments support multiple authentication methods:

The server inherits Azure Role-Based Access Control (RBAC), so the tools a given user can actually invoke depend on their Azure permissions. An agent running under a service principal with Reader access cannot delete resources, regardless of what the MCP tool catalogue advertises.

The tool catalogue

The 276 tools span categories that cover the services .NET developers interact with most frequently:

Compute and hosting: App Service management (deployments, diagnostics, settings, database connections), Azure Functions listing, AKS cluster management, Service Fabric operations, and VM details.

Databases: Cosmos DB accounts, databases, containers, and document queries. Azure SQL servers, databases, firewall rules, and elastic pools. PostgreSQL and MySQL server management. Redis cache provisioning.

Storage: Blob containers and objects, file shares with snapshot support, Azure Managed Lustre file systems, and File Sync configuration.

Messaging and events: Service Bus queues and topics (including message peeking), Event Hubs namespaces, and Event Grid topics with subscriptions.

Monitoring and diagnostics: Azure Monitor log and metric queries, Application Insights resource listing, App Lens diagnostic analysis, and Azure Workbooks for data visualisation.

Security: Key Vault keys, secrets, and certificates. RBAC role assignment management. Azure Policy assignments and definitions.

AI and search: Microsoft Foundry models and deployments, Azure AI Search index management and queries, and Speech service operations.

DevOps and governance: Bicep schema retrieval for infrastructure-as-code templates, Azure Advisor recommendations, pricing queries, resource health checks, and Well-Architected Framework guidance.

Each tool carries metadata annotations that tell the client whether it is read-only, destructive, idempotent, or potentially returns sensitive data. These annotations are not just documentation — well-behaved MCP clients use them to gate confirmations. A read-only list operation executes silently; a destructive delete prompts the user first.

Setting it up

As a .NET global tool

The most straightforward way to run the server locally is as a .NET global tool:

terminal 
dotnet tool install -g Azure.Mcp

Then start the server:

terminal 
azmcp server start

By default, this launches in stdio mode, which is what IDE extensions expect. The server authenticates using your Azure CLI session or any credential in the DefaultAzureCredential chain.

IDE configuration

For VS Code, Cursor, or similar editors, add an entry to your .vscode/mcp.json:

.vscode/mcp.json 
{
  "mcpServers": {
    "Azure MCP Server": {
      "command": "azmcp",
      "args": ["server", "start"],
      "type": "stdio"
    }
  }
}

Visual Studio 2026 has the Azure MCP Server built in — enable it through the Azure and AI development workload during installation. No separate configuration is needed.

Docker for remote hosting

For team or CI/CD deployments, Docker is the cleaner option:

mcp-config.json 
{
  "mcpServers": {
    "Azure MCP Server": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "--env-file", "/path/to/.env",
        "mcr.microsoft.com/azure-sdk/azure-mcp:latest"
      ]
    }
  }
}

The .env file carries your service principal credentials:

.env 
AZURE_TENANT_ID=your-tenant-id
AZURE_CLIENT_ID=your-client-id
AZURE_CLIENT_SECRET=your-client-secret

// WARNING

Never commit the .env file to source control. For production remote deployments, prefer managed identity over client secrets.

Controlling tool exposure

You do not have to expose all 276 tools. The server supports namespace filtering to limit which service categories are available:

terminal 
azmcp server start --namespace storage,cosmos,monitor

This starts the server with only the Storage, Cosmos DB, and Monitor tools — useful for scoping an agent's capabilities to what it actually needs.

For even finer control, the --tool flag exposes individual tools by name:

terminal 
azmcp server start --tool azmcp_storage_account_get --tool azmcp_monitor_query

The --read-only flag disables all write operations, which is a sensible default for monitoring and diagnostic agents that should never modify infrastructure:

terminal 
azmcp server start --read-only

Integrating with Semantic Kernel

If you are building agents in .NET with Semantic Kernel, the MCP client integration lets you import Azure MCP tools as kernel functions:

Program.cs 
using Microsoft.SemanticKernel;
using Microsoft.Extensions.AI;

var builder = Kernel.CreateBuilder();

builder.AddAzureOpenAIChatCompletion(
    deploymentName: "gpt-4o",
    endpoint: "https://your-instance.openai.azure.com/",
    apiKey: configuration["AzureOpenAI:ApiKey"]!);

var kernel = builder.Build();

// Connect to the MCP server and import tools as plugins
var mcpClient = await McpClient.ConnectAsync(
    new StdioTransport("azmcp", ["server", "start"]));

var tools = await mcpClient.ListToolsAsync();

foreach (var tool in tools)
{
    kernel.ImportPluginFromFunctions(
        tool.Name,
        [tool.AsKernelFunction()]);
}

Once imported, the tools are available to the kernel's automatic function calling. When the model decides it needs to list storage accounts or query logs, it invokes the corresponding MCP tool through the established connection, and RBAC ensures it can only access what the underlying credentials permit.

// TIP

For production deployments, connect to a remote MCP server instance rather than spawning a local stdio process. This centralises credential management and lets you apply consistent tool restrictions across all agents.

The security model

Azure MCP Server's security design has three layers that work together:

Authentication and RBAC: the server uses Azure Identity credentials, so every tool invocation runs under the caller's permissions. If the service principal lacks Microsoft.Storage/storageAccounts/read, the blob listing tool returns an authorisation error. There is no ambient access.

Tool annotations: each tool carries structured metadata — readOnly, destructive, idempotent, secret — that MCP clients use to make policy decisions. A well-built agent can automatically skip confirmation for read-only operations whilst requiring explicit approval for destructive ones.

Elicitation: tools that might return sensitive data (Key Vault secrets, connection strings, certificate private keys) trigger a user confirmation prompt through the MCP elicitation mechanism. The client must ask the user before the server executes the operation. This can be disabled with --disable-user-confirmation for automated pipelines, but the flag name makes the trade-off explicit.

terminal 
# Bad — disables security prompts in an interactive context
azmcp server start --disable-user-confirmation

# Good — read-only mode for automated monitoring agents
azmcp server start --read-only

// IMPORTANT

The --disable-user-confirmation flag removes the safety net for secret retrieval. Only use it in trusted, automated environments where user interaction is not possible. Never in production environments handling untrusted input.

Sovereign cloud support

For organisations operating in regulated environments, Azure MCP Server supports sovereign cloud endpoints including Azure US Government and Azure China. Configure the target cloud through environment variables or startup parameters — the tool definitions and authentication flows adapt automatically to the correct endpoints.

Common pitfalls

Exposing all tools to a general-purpose agent. An agent with access to 276 tools and no constraints will eventually invoke something you did not intend. Use namespace filtering or the --tool flag to limit the surface area to what the agent genuinely needs. Pair this with --read-only for agents that should only observe.

Running local stdio in shared environments. The 1.x deployment model of one local server per developer works for experimentation. For anything resembling a team workflow or automated pipeline, deploy the server remotely with proper authentication. Distributing Azure credentials to every developer machine and build agent creates a sprawling attack surface.

Ignoring tool annotations. The destructive, secret, and readOnly annotations exist for a reason. If you are building a custom MCP client, honour these annotations in your tool execution policy. Ignoring them turns your agent into an unsupervised script with Azure admin credentials.

Assuming the tool catalogue is static. Azure MCP Server's tool list is tied to the server version. When you upgrade, new tools may appear and existing tools may change their schemas. Pin your server version in CI/CD and test agent behaviour after upgrades, just as you would with any other dependency.

Forgetting RBAC scoping. The server can only do what the underlying identity is authorised to do, but many teams grant overly broad permissions to service principals out of convenience. Follow least-privilege principles — if an agent only needs to read storage and query logs, its identity should have Reader on the storage account and Log Analytics Reader on the workspace. Nothing more.

Summary