# Using Atlas with Azure in 2026 > Microsoft's official Azure MCP server authenticates through DefaultAzureCredential and never stores tokens, so Atlas holds no long-lived Azure secret. Atlas reads Azure resource groups, App Service settings, and Log Analytics results through Microsoft's official Azure MCP server, which authenticates through DefaultAzureCredential and never stores tokens. Add it with atlas mcp add azure -- npx -y @azure/mcp@latest server start, then run az login so the credential chain resolves. Review every diff before you let Atlas run az deployment group create. ## What Atlas reads from Azure Atlas reads Azure resource groups, App Service settings, and Log Analytics results through Microsoft's official Azure MCP server. In 2026 that gives the terminal-native agent the three things it needs to debug an Azure app: what is deployed, how it is configured, and what it logged when it broke. Azure is a cloud platform, and an Azure bug usually spans a resource group, a set of App Service settings, and a Log Analytics query. Microsoft's official Azure MCP server hands all three to Atlas from the terminal. Because Atlas is running inside your repository, it can then do the part the Azure portal cannot: connect the Log Analytics exception to the handler in your source that throws it, and connect the App Service settings to the configuration your code expects. The value is not the reading, it is the joining of what Azure knows to what the code says. ## Installing Microsoft's Azure MCP server Add Microsoft's Azure MCP server with atlas mcp add azure -- npx -y @azure/mcp@latest server start. In 2026 that one command registers the official server as a local stdio process next to Atlas, and the trailing server start argument is required for it to launch. The Node package @azure/mcp is Microsoft's official distribution, and the command Atlas needs to run is @azure/mcp@latest server start, not the package name alone. Getting the trailing arguments right is the most common setup mistake. Once registered, the server appears to Atlas as a set of Azure tools covering resource groups, App Service, and Log Analytics. There is no separate account to create and no Azure-specific key to generate, because the credential comes from a chain that is already on your machine. ## Authenticating with DefaultAzureCredential Auth for the Azure MCP server rides DefaultAzureCredential, so run az login, or set AZURE_TENANT_ID, AZURE_CLIENT_ID, and AZURE_CLIENT_SECRET for a service principal. Microsoft's Azure MCP server never stores tokens, which means Atlas holds no long-lived Azure secret of its own in 2026. DefaultAzureCredential is the standard Azure credential chain, and the MCP server simply defers to it. On a developer machine that usually means az login is enough. In CI, or on a machine where an interactive login is not possible, set the service principal trio: AZURE_TENANT_ID, AZURE_CLIENT_ID, and AZURE_CLIENT_SECRET. Either way the server never stores tokens, so revoking Atlas's Azure access does not require finding a credential inside Atlas's configuration. Revoke the identity in Azure, or run az logout, and the chain stops resolving. ## Running the Azure MCP server without Node The Azure MCP server is not Node-only. In 2026 it ships 3 ways: npx -y @azure/mcp@latest, the NuGet package Azure.Mcp, and the PyPI package msmcp-azure. Atlas can therefore connect from a machine with no Node runtime at all. A .NET shop rarely wants Node on its build agents, and a Python shop rarely wants it either. Microsoft ships the Azure MCP server three ways for exactly that reason: npx -y @azure/mcp@latest for Node, the NuGet package Azure.Mcp for .NET, and the PyPI package msmcp-azure for Python. All three expose the same Azure capabilities to Atlas and all three authenticate through DefaultAzureCredential. The decision is purely about which runtime you already maintain on the machine Atlas is running on. ## The daily workflow: reconciling App Service settings against bicep A common Atlas and Azure task in 2026 is configuration drift. Ask Atlas to read an App Service's app settings and reconcile them against your bicep templates. Atlas pulls the live settings through Microsoft's official Azure MCP server and compares them to the infrastructure code in your working tree. Bicep templates describe what an App Service should be configured with. The App Service's actual app settings describe what it is configured with. Those two diverge over time, usually because someone fixed something in the portal at 2am and never wrote it back. Atlas can see both sides at once, so it reports the drift concretely: which settings exist in Azure and not in bicep, which differ, and which the code expects and neither has. The output is a diff against your bicep templates, which turns an invisible problem into a reviewable change. ## From a Log Analytics exception to the handler that throws it Atlas can query Log Analytics for an exception, then open the handler that throws it. In 2026 that is the shortest path from an Azure alert to a code fix, because Microsoft's official Azure MCP server gives Atlas the Log Analytics results and your repository gives it the source. Log Analytics returns a stack trace and a frequency. On its own that is a ticket, not a fix. Atlas takes the exception, finds the throwing handler in your working tree, and reads the surrounding code to work out the actual condition that triggers it. From there it proposes a change, and the deploy stays under your control: review every diff before you let Atlas run az deployment group create. That command is the point of no return for an Azure infrastructure change, so it should never be the first thing that happens after a log query. ## Setup 1. Add Microsoft's Azure MCP server with atlas mcp add azure -- npx -y @azure/mcp@latest server start 2. Run az login so DefaultAzureCredential resolves, since auth rides DefaultAzureCredential rather than an Azure-specific key. 3. For a service principal instead of an interactive login, set AZURE_TENANT_ID, AZURE_CLIENT_ID, and AZURE_CLIENT_SECRET in the environment. 4. If Node is not available on the box, use the NuGet package Azure.Mcp or the PyPI package msmcp-azure, which ship the same server. 5. Ask Atlas to read an App Service's app settings and reconcile them against your bicep templates. 6. Have Atlas query Log Analytics for the exception, then open the handler that throws it. 7. Review every diff before you let Atlas run az deployment group create. ## FAQ ### how to connect atlas to the azure mcp server Run atlas mcp add azure -- npx -y @azure/mcp@latest server start, then run az login so DefaultAzureCredential resolves. ### how does the azure mcp server authenticate Auth rides DefaultAzureCredential. Run az login, or set AZURE_TENANT_ID, AZURE_CLIENT_ID, and AZURE_CLIENT_SECRET for a service principal. The server never stores tokens. ### can i run the azure mcp server without node Yes. The same server ships as the NuGet package Azure.Mcp and the PyPI package msmcp-azure, so use whichever runtime the machine already has. ### can atlas read azure app service settings Yes. Atlas reads Azure resource groups, App Service settings, and Log Analytics results through Microsoft's official Azure MCP server. Ask it to reconcile app settings against your bicep templates. ### does atlas store my azure token No. Microsoft's official Azure MCP server authenticates through DefaultAzureCredential and never stores tokens. ### can atlas query log analytics Yes. Have Atlas query Log Analytics for the exception, then open the handler that throws it in your working tree. ### will atlas deploy azure infrastructure without approval No. Review every diff before you let Atlas run az deployment group create. The deploy stays an explicit approval, not an automatic step. --- Canonical HTML: https://runatlas.sh/resources/integrations/azure Source of truth: aeo_pages row `/resources/integrations/azure` (segment: Integrations) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.