BetterAzureMCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BETTERAZUREMCP_LOG_LEVEL | No | error, warn, info or debug. Logs go to stderr. | info |
| BETTERAZUREMCP_TENANT_ID | No | Tenant to sign in to. Default: tenant of your login. | |
| BETTERAZUREMCP_CREDENTIAL | No | auto tries environment variables, Azure CLI, Azure Developer CLI and Azure PowerShell, in that order. Or pin one: azurecli, azd, azurepowershell, environment, managedidentity. | auto |
| BETTERAZUREMCP_SHOW_SECRETS | No | Set to true to stop masking secret values. Not recommended. | false |
| BETTERAZUREMCP_MAX_RESPONSE_KB | No | Size limit for a single tool result (2–256). | 12 |
| BETTERAZUREMCP_TIMEOUT_SECONDS | No | Deadline for a single tool call (5–600). | 60 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| azure_contextA | Shows who you are signed in to Azure as, which tenant is used, and the subscriptions you can read. Call this first when you need a subscription ID, or when another tool reports an authentication or permission problem. |
| azure_find_resourcesA | Finds Azure resources by name, type, resource group, location or tag, across all your subscriptions at once. Returns resource IDs you can pass to other tools, plus type, location, SKU and provisioning state. Example: {"name": "orders-api", "type": "Microsoft.Web/sites"}. Common types: Microsoft.Web/sites (App Service and Functions), Microsoft.App/containerApps, Microsoft.ContainerService/managedClusters (AKS), Microsoft.Insights/components (Application Insights), Microsoft.OperationalInsights/workspaces (Log Analytics). |
| azure_resource_graph_queryA | Runs a KQL query against Azure Resource Graph: a fast, read-only index of every resource across your subscriptions. Useful tables: resources, resourcecontainers (subscriptions and resource groups), resourcechanges (recent property changes), healthresources (availability), advisorresources, policyresources. Examples: "resources | where type =~ 'microsoft.web/sites' | summarize count() by location"; "resourcechanges | where properties.changeAttributes.timestamp > ago(1d) | project properties.targetResourceId, properties.changeType, properties.changes | take 20". Use azure_find_resources for simple lookups. |
| azure_get_resourceA | Returns the full Azure Resource Manager definition of one resource: configuration, SKU, identity, networking and state. Works for any resource type, including child resources such as deployment slots. Secret values are masked. Get the resource ID from azure_find_resources. |
| azure_resource_healthA | Shows whether Azure itself reports a resource as healthy: its current availability, recent availability changes with Azure's stated reason, and active Azure service issues affecting the subscription. Use it early when an app is down, to tell a platform problem apart from an application problem. |
| azure_recent_changesA | Lists configuration changes to a resource, or to every resource in a resource group or subscription, over the last hours (up to 14 days): what changed, the before and after values, who changed it and through which client. Use it to answer "what changed before this broke?". |
| azure_activity_logA | Lists control-plane operations from the Azure activity log: deployments, restarts, scaling, configuration updates, role assignments, and their failures, with the caller and error message. Scope it to a resource, a resource group or a whole subscription. Set onlyFailures to see only failed operations. |
| azure_telemetry_locationsA | Finds where a resource's logs and telemetry are stored: diagnostic settings (Log Analytics workspaces, storage accounts, Event Hubs, with the enabled log categories), linked Application Insights, Container Apps environment logging, and AKS Container Insights. Returns the resource IDs to use with azure_logs_query and azure_appinsights_failures, and which tables to query. Call this before querying logs for a resource you have not looked at yet. |
| azure_metricsA | Reads platform metrics for any resource: CPU, memory, requests, HTTP 5xx, response time, restarts, queue length, DTU and so on. Call without metrics to list the metrics a resource offers. With metrics, returns min/avg/max/latest per series and a downsampled time series. Example: {"resourceId": "...sites/orders-api", "metrics": ["Http5xx", "HttpResponseTime"], "hours": 6}. Split by a dimension with filter, e.g. "Instance eq '*'". |
| azure_logs_queryA | Runs a KQL query against Azure Monitor Logs. scope can be a Log Analytics workspace (queries the whole workspace), an Application Insights resource, or any other resource (only that resource's logs, from every workspace it sends to). Application Insights tables: AppRequests, AppDependencies, AppExceptions, AppTraces. App Service: AppServiceHTTPLogs, AppServiceConsoleLogs. AKS: ContainerLogV2, KubePodInventory, KubeEvents. Example: {"scope": "", "query": "AppRequests | where Success == false | summarize count() by ResultCode, Name | top 10 by count_"}. Use azure_telemetry_locations to find the right scope. |
| azure_appinsights_failuresA | One-call triage of an application from Application Insights: request volume and failure rate, the most frequent failed operations, top exceptions, failing dependencies (databases, HTTP calls, queues) and the slowest operations. Each entry carries a sample operation ID to pass to azure_appinsights_trace for the full end-to-end transaction. |
| azure_appinsights_traceA | Shows everything recorded for one operation ID in Application Insights, in time order: the incoming request, outgoing dependency calls, exceptions with stack details, and log traces, across all services. Get operation IDs from azure_appinsights_failures (sampleOperationId) or from a log query. |
| azure_appservice_overviewA | Summarizes an App Service or Function app (or a deployment slot) for debugging: state, runtime stack, plan and scale, key configuration (Always On, health check, TLS, workers), logging settings, slots, recent deployments and, for Function apps, the functions. App setting and connection string values are never read. |
| azure_appservice_logsA | Reads the most recent log lines of an App Service or Function app from its log files (Kudu). Linux: source "app" is the container stdout/stderr (your application output), "platform" is container start, stop and crash events. Windows: "app" is application logging (must be enabled), "platform" is the Windows event log (IIS and runtime errors). For logs older than the files on disk, use azure_logs_query. |
| azure_diagnosticsA | Runs Azure's built-in "Diagnose and solve problems" detectors for App Service, Function apps and Container Apps. These analyze platform data you cannot query yourself: crashes, restarts, HTTP 5xx breakdowns, CPU and memory pressure, SNAT port exhaustion, deployment and container start failures. Call without detector to list the available detectors, then call again with a detector id. |
| azure_containerapp_overviewA | Summarizes a Container App for debugging: provisioning and running state, ingress, containers (image, CPU, memory, probes), scale rules, revisions with health and traffic, and the replicas of active revisions with container restart counts and states. Use azure_containerapp_logs for console and system logs. |
| azure_containerapp_logsA | Reads recent Container App logs from the environment's Log Analytics workspace. source "console" is your containers' stdout/stderr; "system" is platform events: revision provisioning, image pulls, probe failures, crashes and scaling. Filter by revision or by text. Results are oldest first. |
| azure_aks_overviewA | Summarizes an AKS cluster from Azure Resource Manager: power and provisioning state, Kubernetes version and available upgrades, node pools (size, count, autoscaling, state), networking, identity and access mode, and enabled add-ons such as Container Insights. Also tells whether azure_aks_workloads and azure_aks_pod_logs can reach this cluster. |
| azure_aks_workloadsA | Reads live workload state from an AKS cluster's Kubernetes API with your Entra ID account (read-only). view "problems" (default) returns only what needs attention: failing or restarting pods, recent Warning events, deployments that are not fully available, and nodes that are not ready. Other views list everything: "pods", "events", "deployments", "nodes". Optionally limit to one namespace. |
| azure_aks_pod_logsA | Reads the last log lines of a pod container in an AKS cluster through the Kubernetes API (read-only). Set previous to true to read the logs of the previous, crashed instance of a container in CrashLoopBackOff. Find pod names with azure_aks_workloads. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 20 tools
Most tools are clearly distinct by resource type (App Service vs AKS vs Container Apps) and by action (overview vs logs vs metrics vs query). However, azure_logs_query and azure_appinsights_failures both query application telemetry and could be confused, though one is a raw query and the other is a pre-built triage. Also, azure_appservice_logs and azure_containerapp_logs are similar but differ by platform.
The naming pattern is mostly consistent with a resource prefix (azure_<resourcetype>_<action>), e.g., azure_appservice_logs, azure_containerapp_overview, azure_aks_workloads. However, there are several tools that break this pattern: azure_context, azure_find_resources, azure_resource_graph_query, and azure_logs_query lack a clear resource type in the name, making them less predictable. But the overall style is still uniform (snake_case, resource-first).
With 20 tools, this is at the upper edge of a well-scoped set. Each tool covers a specific debugging need, and there is no redundancy or bloat. It feels slightly heavy because azure_get_resource could be redundant with azure_find_resources plus the ARM API, but it's still reasonable given the breadth of Azure services covered.
The tool surface is remarkably complete for the domain of Azure debugging. It covers resource discovery (find_resources, resource_graph_query), state (get_resource, resource_health), metrics (azure_metrics), logs (appservice_logs, containerapp_logs, aks_pod_logs, logs_query), diagnostics (azure_diagnostics, appinsights_failures), telemetry locations (azure_telemetry_locations), and change tracking (azure_recent_changes, activity_log). It provides a full lifecycle for investigating any Azure resource, and the ability to drill down from broad to specific.