Connect Microsoft Azure

Microsoft Azure is where a great many of your customers' servers, networks, databases and bills live. Connecting it gives your AI a large set of azure_ MCP tools — MCP (Model Context Protocol) tools are the standardized commands an AI assistant can call through StackJack — covering subscriptions, virtual machines, storage, networking, DNS, app services, Kubernetes, SQL, monitoring, cost, policy, access control and security posture.

Two things make this connector different from every other one in StackJack, and both are worth reading before you connect.

Nothing to enter, unless you bring your own app

Every other connector asks you for a key, a secret or a URL. Azure asks for none of them by default. StackJack has its own Microsoft application, so you connect by signing in with Microsoft and approving the request — that is the entire setup. (Organizations that prefer to consent to an application they own can bring their own app registration instead — the option lives under Advanced — use your own app registration on the connector card, and the Microsoft Graph connector guide describes the whole flow. Each Microsoft connector card stores its own application choice, so set it here and on Microsoft Graph if you use both.)

1. Check who can approve. Many organizations require an administrator to approve a new application once, on behalf of everyone. If you are a Global Administrator you can approve it yourself as you connect. If you are not, either ask an administrator to connect first, or ask them to approve the request when Microsoft prompts for it.
2. Connect with Microsoft. On the Connectors page, open Microsoft Azure and choose Connect with Microsoft. Sign in with the account you use to manage Azure and approve the request.
3. Check what you can reach. Ask your AI to list your Azure subscriptions. If one you expected is missing, that is almost always a role question rather than a connection problem — see below.

Your Azure role decides everything

Azure grants StackJack exactly one thing: permission to act as you. It does not grant "read virtual machines" or "manage storage" separately, because Azure does not work that way. Instead, Azure checks your own role on every single call.

The consequences are worth stating plainly, because they surprise people who have set up other connectors:

• What this connector can do is exactly what you can do in the Azure portal. No more, and no less.
• Two people on the same team will legitimately get different answers. Someone with Reader gets reads and a clean refusal on writes. Someone with Contributor can make changes. That is Azure working correctly.
• A refusal is not a broken connection. When Azure says you are not authorized, it names the action it refused and the scope it refused it at. The fix is an Azure role assignment from an Owner or User Access Administrator — reconnecting will not help, because signing in again grants the same single permission it already had.
• StackJack's plan tiers are a separate, narrower thing. Read tools are available on Free and write tools on Pro, but that only decides which tools your AI is offered. It cannot grant Azure access you do not have.

Managing your customers' Azure

If you manage customers' Azure subscriptions through Microsoft's delegated access, your USER access comes along automatically — there is no separate connection per customer. One thing does need setting up per customer, once: admin consent for the StackJack application in that customer's tenant.

Microsoft asks two separate questions on a customer-directory call: whether YOU may act there (your delegated access), and whether the customer's tenant has admitted the APPLICATION the call comes through. Delegated roles do not answer the second — an administrator in the customer's tenant (Global Administrator, Application Administrator, or Cloud Application Administrator) must approve it once. Generate the link with Authorize a customer tenant on the Azure connector card and send it to them; until they approve, calls into that customer fail with a consent error (AADSTS65001), and reconnecting your own sign-in will not fix it. If the customer runs Conditional Access policies that block external accounts, ask their admin to exclude the specific partner accounts that need access — or the partner-user categorization the policy keys on — from the blocking policy.

Every Azure tool takes an optional customer directory (their Microsoft tenant ID or a verified domain such as contoso.onmicrosoft.com). Leave it out and the tool works on your own Azure. Provide it and the tool works on that customer's, with whatever access you already have there.

In practice you just name the customer when you ask:

• "List the subscriptions in Contoso's directory."
• "Which VMs in Contoso's production resource group are running an unsupported OS?"
• "Compare last month's Azure spend across all our customers."

That last one is worth calling out. StackJack uses Azure's own cross-subscription query service for questions that span many subscriptions, which answers in a single call instead of walking each subscription one at a time. It is both much faster and much less likely to be throttled — so prefer broad questions over asking about each customer in turn.

Every person signs in for themselves

There is no shared Azure identity for a team to fall back on. The stored connection is one person's own Microsoft sign-in, carrying their Azure roles and everything those roles reach across your customers' directories, so StackJack will not run anyone else's calls under it.

• Owners keep the fallback. The organization's owner and co-owners can use the stored connection before they personally sign in.
• Everyone else must connect their own account, including Administrators. Until they do, Azure tools refuse for them with personal_sign_in_required. This is not a preference or an optimization — it is the only way that member gets an Azure identity at all.
• Nothing has to be prepared for them. StackJack's own Microsoft application serves every organization, so a member can connect whether or not an owner ever configured the connector.

Signing in individually is also what keeps the record honest. Azure logs every action against the identity that performed it, so one shared identity would put one person's name against the whole team's work — and each person can only do what their own Azure role allows.

Members connect from the Connectors page, in their personal sign-ins section. The rules in full: Who can use which identity.

What this connector deliberately does not do

Stated up front so it does not read as a gap:

• It does not read the contents of your data. Blob contents, queue messages, database rows and Key Vault secret values are all outside this connector. It manages Azure resources — it does not open what is inside them. For Key Vault this is deliberate and worth being explicit about: StackJack can list vaults, see their access policies, and see secret names and expiry dates, but it cannot read a secret's value.
• It does not cover Azure Government or Azure China. Those are separate clouds that need their own setup.
• It has no purpose-built tools for application platform services such as Cosmos DB, Service Bus, Data Factory or Synapse. Those are your customers' application data tiers rather than the infrastructure an MSP manages. They are still reachable through the raw request tools below, with the same Azure role you already hold — there is simply no tool written for them.
• Classic (pre-Resource-Manager) resources have no tools either. They have been retired by Microsoft.
• It does not give automations access by default. An automation has no signed-in person of its own, so it cannot borrow your connection. An administrator can enrol a dedicated Microsoft sign-in for a specific automation, and it then acts with exactly that account's Azure role — enrol a purpose-made account rather than a person's, so an unattended process reaches only what it needs and the Azure activity log names the automation rather than a technician who was not at their desk.

Things that catch people out

A tool says the subscription does not exist. A subscription ID only means something inside its own directory. If it is a customer's subscription, name their directory in the request — without it, the tool looked in your own.

Large lists come back partial. StackJack caps a single call at 1,000 items across 10 pages, and tells your AI where the list left off so it can continue. This is a StackJack safety limit rather than an Azure one, and it exists to stop one question consuming an enormous response.

A long-running change returns immediately, and the answer can look empty. Deleting a resource group, resizing a cluster or restoring a database can take many minutes in Azure. The tool does not wait: Azure answers accepted, the tool hands that answer straight back, and the work continues afterwards. Read the three outcomes differently:

• Accepted — Azure took the request and is still working. The reply is often empty, because Azure returns no body with an acceptance. An empty reply here is not a failure and is not a completion.
• Completed — the reply carries the changed resource.
• Failed — the reply carries Azure's error.

Because an acceptance can come back empty, do not treat "it returned" as "it finished". Confirm the outcome with a read that suits the resource: check whether a resource group still exists, read the resource back, or read the activity log or the operation record for that resource. Ask your AI to confirm the result rather than assuming it.

Azure starts throttling. Azure limits how fast requests can arrive, and StackJack waits as long as Azure asks before retrying, within a bounded retry budget. Pacing reduces throttling; it does not remove it, and a long enough wait can end as a timeout instead. If it keeps happening, ask one broad cross-subscription question rather than many narrow ones, and check whether a write landed before you repeat it — see Retrying a failed or timed-out write.

Destructive actions

Some Azure tools remove data, interrupt running workloads, run code on a machine, or change who has access. StackJack marks those as destructive and they are all Pro-tier. Whether your AI application asks you to confirm before running one depends on that application's own settings — see Destructive tools and confirmation. Review those settings, and restrict the tools you grant, before you allow destructive Azure actions.

The sharpest ones are worth knowing by name:

• Deleting a resource group deletes everything inside it — virtual machines, disks, databases, storage accounts and their contents — with no confirmation from Azure and no undo. Ask your AI to list the group's contents first.
• Storage account keys grant full access to everything in that account, and regenerating one breaks every existing application using it.
• Cluster credentials and registry credentials hand back working administrative access.
• Running a command on a virtual machine executes whatever you send, as an administrator on that machine.
• Role assignments change who can reach what, for everyone.

Marking these clearly is what lets the rest of the connector be used freely.

Advanced: raw API requests

Reach for a purpose-built tool first. They pin the Azure API version for you, escape the names you pass, cap the page size, and their descriptions say what the answer means. Use the raw tools only where no purpose-built tool exists.

Two tools send a request you compose straight to Azure Resource Manager:

• azure_raw_get sends one GET. It is Free-tier and read-only.
• azure_raw_request sends one POST, PUT, PATCH or DELETE. It is Pro-tier and marked destructive. It refuses GET, so a read cannot be run through the write tool.

What they change, and what they do not:

• They widen coverage, not permission. Your connector subscription, your endpoint's tool selection, your plan and your monthly allowance all still apply, and Azure still checks your own role on every call. A raw request returns exactly what your Azure role could reach anyway.
• They reach resource types no tool was written for — Cosmos DB, Service Bus, Data Factory, Synapse and anything else Azure Resource Manager publishes. That is the point of them.
• You supply the API version, and Azure is unforgiving about it. Every Azure resource provider versions independently, and a wrong version comes back as an unhelpful 400. Ask for the provider's supported versions first.
• Paging is yours to drive. A continuation link comes back in the body; pass its path back to get the next page. Nothing pages for you.
• A replacing write drops what you leave out. PUT on Azure Resource Manager replaces the whole resource, so a body assembled from a few fields silently clears every property you did not send. Read the resource first and send it back complete.
• Long-running writes are not followed for you. Azure answers accepted with a tracking address in its response headers, and StackJack returns the body rather than the headers — so the reply can be empty and nothing polls on your behalf. Confirm the outcome with a read, as described above.
• The path is fenced. It has to be rooted at a subscription, a provider or a tenant, with no scheme and no directory traversal. Anything else is refused before the request is sent.

Microsoft adding or promoting an API does not, on its own, produce a purpose-built StackJack tool for it, and it does not change what your organization has consented to. Both remain separate decisions.

See the generated Microsoft Azure tool reference for the current inventory, plan assignment, input schemas, and destructive-action labels.

Microsoft Azure tools

azure_ · 545 tools · Free 304 · Pro 241

Subscriptions

Resource Graph

Resource Groups

Resources & Tags

Virtual Machines

Storage

Networking

Cost Management

Monitor

Log Analytics

App Service

SQL

AKS

RBAC

Policy

Resource Health

Defender for Cloud

Deployments

Management Groups

Disks & Snapshots

Virtual Machine Scale Sets

Containers

DNS

Key Vault

Backup

Automation

Managed Identities

Advisor

Container Apps

Raw Requests