From azure-mcp
Use this skill when connecting the azure-mcp vendor through the WYRE MCP Gateway — registering an Azure service principal, supplying tenantId/clientId/clientSecret, and granting least-privilege Reader-tier RBAC. Covers the read-only deployment model and why broader write roles must not be granted.
How this skill is triggered — by the user, by Claude, or both
Slash command
/azure-mcp:connectionWhen to use
When setting up or troubleshooting the azure-mcp connector — creating an Azure service principal, choosing RBAC roles, or explaining the read-only constraint to an MSP onboarding a tenant. Use when: connect azure mcp, azure mcp setup, azure service principal, azure mcp credentials, azure rbac for mcp, azure connector, azure mcp permissions, register azure app, or least privilege azure.
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
The `azure-mcp` vendor runs Microsoft's official Azure MCP Server (`mcr.microsoft.com/azure-sdk/azure-mcp`) as a WYRE-built sidecar inside the MCP gateway. Each connecting MSP supplies its own Azure **service principal**; the gateway isolates credentials per tenant and scopes every request to the principal you registered.
The azure-mcp vendor runs Microsoft's official Azure MCP Server (mcr.microsoft.com/azure-sdk/azure-mcp) as a WYRE-built sidecar inside the MCP gateway. Each connecting MSP supplies its own Azure service principal; the gateway isolates credentials per tenant and scopes every request to the principal you registered.
The gateway runs the Azure MCP Server with the --read-only flag and a deliberately constrained namespace allowlist. Day-one the connector exposes exactly eight read-leaning namespaces:
monitor pricing quota advisor resourcehealth applens subscription group
Write- and delete-capable namespaces (storage, keyvault, compute, role, aks, and others) are not enabled. This is intentional defense-in-depth: even if a service principal were over-privileged, the gateway cannot route a mutating call. As shipped, azure-mcp is an Azure observability, cost, and resource-health tool — nothing it does changes infrastructure.
Because the deployment is read-only, the service principal you connect should also be read-only. Grant Reader-tier roles and nothing more.
In the Azure tenant you want to manage, create an Azure AD app registration with a client secret. Either the portal (Microsoft Entra ID → App registrations → New registration) or the CLI works:
az ad sp create-for-rbac \
--name "wyre-azure-mcp" \
--role "Reader" \
--scopes "/subscriptions/<subscription-id>"
This emits three values you will need for the gateway:
tenant → Tenant IDappId → Service Principal Client IDpassword → Service Principal Client Secret (shown once — capture it now)If you reuse an existing app registration, generate a fresh client secret under Certificates & secrets and note its expiry — the connector stops working when the secret lapses.
Assign Reader-tier roles only, at subscription scope (or management-group scope to cover several subscriptions). These two built-in roles cover all eight enabled namespaces:
| Role | Why it is needed | Covers |
|---|---|---|
Reader | Read-only visibility into resources, metrics, health, and inventory | monitor, resourcehealth, applens, advisor, subscription, group |
Cost Management Reader | Read access to cost, pricing, and usage data | pricing, quota, cost-focused advisor recommendations |
az role assignment create \
--assignee "<service-principal-client-id>" \
--role "Reader" \
--scope "/subscriptions/<subscription-id>"
az role assignment create \
--assignee "<service-principal-client-id>" \
--role "Cost Management Reader" \
--scope "/subscriptions/<subscription-id>"
For Log Analytics KQL queries via the monitor namespace, Reader on the subscription is sufficient because it inherits to the workspace. If a workspace lives outside the granted scope, add Log Analytics Reader on that specific workspace — still a Reader-tier role.
Contributor, Owner, User Access Administrator, Key Vault Secrets User, and similar write/secret roles are unnecessary and must not be granted. The connector cannot use them — the gateway runs --read-only and the write namespaces are not in the allowlist. Granting them only widens the blast radius of a leaked secret with zero functional benefit. Least privilege here is both a security control and a no-cost decision.
In the gateway connection UI, choose the azure-mcp vendor and supply:
appIdThe gateway authenticates the Azure MCP sidecar with these credentials and routes the eight enabled namespaces' tools into your session. No Azure credentials are stored client-side.
After connecting, confirm the connector is live with a harmless read:
subscription namespace) — confirms the service principal authenticated and has at least Reader visibility.group namespace) for one subscription — confirms scope is correct.AuthorizationFailed / empty subscription list — no Reader assignment at the subscription/management-group scope, or the assignment hasn't propagated yet (allow a few minutes).Cost Management Reader is missing.azure-mcp is a read-only deployment and the relevant namespace is not enabled; do not attempt a workaround.npx claudepluginhub wyre-technology/msp-claude-plugins --plugin azure-mcpGuides Azure MCP setup by fixing authentication ('az login'), missing Azure CLI, RBAC permissions, and Node.js 20+ installation errors.
Use this skill when connecting the Microsoft Graph MCP Server for Enterprise to the Wyre MCP Gateway — registering the BYOC multi-tenant Entra app, supplying tenantId/clientId/clientSecret, and (the part everyone misses) granting per-tenant admin consent for the MCP.* delegated permissions out of band. Also covers the preview status and the 100 calls/min/user rate limit.
Provides expert guidance for Azure RBAC development: troubleshooting, best practices, custom role JSON, PIM assignments, deny policies, and ARM/Bicep access templates.