Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@azure-query-mcp Count resources by type in subscription 00000000-0000-4000-8000-000000000000"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A read-only Model Context Protocol server for querying Azure Log Analytics and Azure Resource Graph (ARG). It runs locally over stdio and uses Azure RBAC through DefaultAzureCredential.
This project is currently distributed from source. Each user runs the MCP server locally and authenticates with their own Microsoft Entra identity. Nothing is deployed into an Azure tenant, and the server does not receive shared credentials.
Use it when an MCP client needs both of these Azure data planes:
Log Analytics for logs, events, telemetry, and time-series analysis.
Azure Resource Graph for resource inventory and control-plane configuration.
Related MCP server: Purple AI MCP Server
Need | MCP tool | Data source |
Logs, events, telemetry, metrics, incidents, or time-series analysis |
| Log Analytics workspace |
Azure resource inventory, configuration, tags, policy, health, or cross-subscription discovery |
| Azure Resource Graph |
Find a workspace or inspect its tables and schemas |
| Azure Resource Manager |
ARG describes Azure control-plane resources and can be slightly delayed. It does not contain workspace log records. Log Analytics queries require a workspace customer ID and an ISO 8601 timespan.
All tools are marked read-only, non-destructive, and idempotent.
ARG calls a fixed Microsoft endpoint with API version 2024-04-01; users cannot control the URL.
ARG requires explicit subscription scope and caps each page at 1,000 rows and 5 MiB.
Log Analytics requires bounded KQL and caps output at 1,000 rows and 2,000 characters per cell.
Requests time out, upstream ARG error bodies are not returned, and access tokens are never logged.
Authentication and authorization are delegated to Microsoft Entra ID and Azure RBAC.
See SECURITY.md before production deployment.
Git
Node.js 22 or later
Azure CLI for local interactive authentication
An Azure identity available to DefaultAzureCredential
Azure RBAC on only the subscriptions and workspaces that should be queried
Recommended least-privilege roles:
Capability | Suggested role and scope |
Query ARG and discover workspaces |
|
Read Log Analytics schemas and data |
|
Custom roles can be narrower. The effective permissions must include the relevant Azure Resource Manager read operations and Log Analytics query access.
Clone and build the server.
git clone https://github.com/kapetanios55/azure-query-mcp.git
Set-Location azure-query-mcp
npm ci
npm run checkSign in to the tenant that contains the target subscriptions and workspaces.
az login --tenant <tenant-id>
az account list --output tableAdd the server to the MCP client. For VS Code, add this to .vscode/mcp.json and replace the path with the absolute path to the cloned repository.
{
"inputs": [
{
"id": "azureTenantId",
"type": "promptString",
"description": "Microsoft Entra tenant ID"
}
],
"servers": {
"azure-query": {
"type": "stdio",
"command": "node",
"args": ["C:/path/to/azure-query-mcp/dist/index.js"],
"env": {
"AZURE_TENANT_ID": "${input:azureTenantId}"
}
}
}
}Start azure-query from the MCP server view. Reload the VS Code window if the server does not appear after editing the configuration.
Verify both paths with prompts such as:
List the Log Analytics workspaces in subscription <subscription-id>.
Show the schema of the Heartbeat table in workspace <workspace-resource-id>.
Use Azure Resource Graph to count resources by type in subscription <subscription-id>.For production, use managed identity or workload identity. Avoid client secrets when the hosting platform supports federation.
Never place AZURE_CLIENT_SECRET directly in a committed MCP configuration. Use the host's secret store or managed identity.
query_azure_resourcesRuns read-only ARG KQL against one or more explicitly supplied subscription IDs. The query must begin with a supported ARG table such as Resources.
subscriptionIds: ["00000000-0000-4000-8000-000000000000"]
query: Resources | where type =~ 'microsoft.compute/virtualmachines' | project id, name, resourceGroup, location | order by name asc | limit 50
maxResults: 50Use the returned skipToken with the identical query and subscription scope to request another page.
query_workspaceRuns bounded read-only KQL against one Log Analytics workspace. A result-limiting operator and timespan are mandatory.
workspaceId: 00000000-0000-4000-8000-000000000000
query: Heartbeat | project TimeGenerated, Computer | take 50
timespan: PT1HThe remaining tools discover workspaces and inspect Log Analytics table metadata.
The examples below use query_workspace. Supply the workspace customer ID and an explicit ISO 8601 timespan with every request. Table availability depends on the workspace configuration.
Prompt:
For the last 24 hours, show the 25 computers with the most recent heartbeat.KQL:
Heartbeat
| summarize LastHeartbeat=max(TimeGenerated) by Computer
| top 25 by LastHeartbeat descTimespan: P1D
Prompt:
For the last seven days, show the 20 users with the most failed sign-ins.KQL:
SigninLogs
| where ResultType != 0
| summarize FailedSignIns=count() by UserPrincipalName
| top 20 by FailedSignIns descTimespan: P7D
Prompt:
Show the 20 most recently updated Microsoft Sentinel incidents from the last seven days.KQL:
SecurityIncident
| summarize arg_max(TimeGenerated, *) by IncidentNumber
| project TimeGenerated, IncidentNumber, Title, Severity, Status, Owner
| top 20 by TimeGenerated descTimespan: P7D
Use search_tables when the table name is unknown, then use describe_table to retrieve the canonical column names and types before writing KQL.
The examples below use query_azure_resources and one or more explicit subscription IDs. ARG reports Azure control-plane state and can be slightly delayed.
Resources
| summarize ResourceCount=count() by type
| top 25 by ResourceCount descResources
| where type =~ 'microsoft.compute/virtualmachines'
| project id, name, resourceGroup, subscriptionId, location
| order by name asc
| limit 100Resources
| where isempty(tags.owner)
| project id, name, type, resourceGroup, subscriptionId
| order by type asc, name asc
| limit 100Set targetPort to the port to investigate. This query handles a single destination port, destination port arrays, ranges such as 5000-5100, and the * wildcard. It also handles single and array source prefixes.
Resources
| where type =~ 'microsoft.network/networksecuritygroups'
| mv-expand rule = properties.securityRules
| where tostring(rule.properties.direction) =~ 'Inbound'
and tostring(rule.properties.access) =~ 'Allow'
| extend sourcePrefixes = iif(
array_length(rule.properties.sourceAddressPrefixes) > 0,
rule.properties.sourceAddressPrefixes,
pack_array(rule.properties.sourceAddressPrefix)
), destinationPorts = iif(
array_length(rule.properties.destinationPortRanges) > 0,
rule.properties.destinationPortRanges,
pack_array(rule.properties.destinationPortRange)
)
| mv-expand sourcePrefix = sourcePrefixes
| where tostring(sourcePrefix) in~ ('*', 'Internet', '0.0.0.0/0', '::/0')
| mv-expand destinationPort = destinationPorts
| extend portText=tostring(destinationPort), targetPort=22
| extend rangeStart=toint(split(portText, '-')[0]),
rangeEnd=toint(split(portText, '-')[1])
| where portText == '*'
or targetPort == toint(portText)
or (rangeStart <= targetPort and rangeEnd >= targetPort)
| summarize MatchingRules=count(),
NsgCount=dcount(id),
Nsgs=make_set(name, 100)This query shape was tested against Azure Resource Graph with both positive and zero-result ports.
Important: this identifies candidate exposure in configured custom NSG rules. It does not calculate effective packet reachability, rule priority conflicts, subnet and NIC associations, public IP presence, routes, Azure Firewall behavior, or application listeners. Treat the result as an investigation starting point, not proof that a service is reachable from the internet.
Symptom | Action |
Wrong-token-issuer or tenant error | Run |
| Verify Reader access at the requested subscription or resource scope. |
Workspace metadata works but queries fail | Verify Log Analytics Reader access to the workspace and confirm the workspace customer ID. |
Table not found | Run |
Query rejected as unbounded | Add |
Server is not visible in VS Code | Run |
npm run check
npm audit --omit=devThe implementation follows the Microsoft Learn Azure Resource Graph REST API and Resources API reference.
Get the canonical schema and retention metadata for a Log Analytics table.
| Name | Required | Description | Default |
|---|---|---|---|
| tableName | Yes | Case-sensitive table name. | |
| workspaceResourceId | Yes | Full ARM resource ID of the workspace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds that the tool returns schema and retention metadata, but does not disclose additional behavioral details like pagination or required permissions beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words, effectively conveying the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with two required parameters, good annotations, and no output schema, the description sufficiently explains the return value at a high level. However, it lacks detailed usage context such as when to prefer this over search_tables, so completeness is slightly below perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes both parameters fully (100% coverage) with clear descriptions, including case-sensitivity for tableName. The description adds no additional parameter-specific meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' and specifies the exact resource: canonical schema and retention metadata for a Log Analytics table. This clearly distinguishes it from sibling tools like search_tables or query_workspace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as search_tables or list_workspaces. The description only states what it does, without any exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Azure Log Analytics workspaces accessible in a subscription.
| Name | Required | Description | Default |
|---|---|---|---|
| subscriptionId | Yes | Azure subscription ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the constraint that only workspaces 'accessible' to the user are returned, which is useful context, but it does not describe pagination or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear, front-loaded sentence with no wasted words. It states the action, resource, and scope efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one parameter and strong annotations, the description is mostly adequate. It lacks explicit details about return values or pagination, but the tool's simplicity and the openWorldHint annotation partially compensate. Slightly more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter subscriptionId, describing it as 'Azure subscription ID'. The description adds no further parameter detail, but the schema already handles it, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'Azure Log Analytics workspaces' and scope 'in a subscription'. It clearly distinguishes from sibling tools like search_tables and query_workspace, which are for different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: to enumerate accessible Log Analytics workspaces for a given subscription. It does not explicitly state alternatives or exclusions, but the context is clear and distinct from the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for Azure resource inventory, configuration, tags, policy, health, and cross-subscription discovery through Azure Resource Graph. Do not use for telemetry, logs, events, or time-series analysis; use query_workspace for those.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Read-only Azure Resource Graph KQL beginning with an ARG table such as Resources. | |
| skipToken | No | Opaque continuation token returned by the preceding identical query. | |
| maxResults | No | Maximum rows returned in this page. | |
| subscriptionIds | Yes | One or more Azure subscription IDs that bound the query scope. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds contextual scope beyond the annotations by specifying the data domains (inventory, config, tags, policy, health) and the underlying mechanism (Azure Resource Graph). It does not add details like rate limits or pagination behavior, but the schema covers pagination via skipToken and maxResults, so the bar is appropriately lowered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences: the first front-loads the primary use cases and scope, and the second delivers a crisp exclusion with a sibling alternative. No filler or redundant content, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations, fully self-describing schema, and a description that clearly delineates scope and alternatives, the tool is fully contextualized. The tool is a read-only query tool, and the description covers what it queries and what it avoids. The lack of an output schema is acceptable per rules, as the return value is not a required explanatory element.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes comprehensive descriptions for all four parameters, achieving 100% coverage. The description does not add additional parameter-specific meaning beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Use for Azure resource inventory, configuration, tags, policy, health, and cross-subscription discovery through Azure Resource Graph.' It distinguishes from the sibling query_workspace by explicitly naming what it does NOT do and directing to the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use and when-not-to-use guidance is provided: 'Do not use for telemetry, logs, events, or time-series analysis; use query_workspace for those.' This directly references the sibling tool as an alternative, making the usage boundaries unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for telemetry, logs, events, metrics, and time-series data stored in a Log Analytics workspace. Run bounded, read-only KQL against one workspace. Do not use for Azure resource inventory or configuration; use query_azure_resources for those.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Read-only KQL with a result-limiting operator. | |
| timespan | Yes | ISO 8601 duration, such as PT1H. | |
| workspaceId | Yes | Log Analytics workspace customer ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful context: 'bounded' (requiring a result-limiting operator), 'against one workspace' (scope constraint), and the data types covered. This goes beyond what annotations provide, though it doesn't discuss return format or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary use case and followed by an exclusion with an alternative. Every word earns its place, no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With rich annotations (readOnly, idempotent, non-destructive) and a clear description covering purpose, scope, and exclusions, the tool is well-specified for an agent. No output schema exists, but for a query tool the description sufficiently sets expectations without needing to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear description. The tool description reinforces the query parameter as 'bounded, read-only KQL' and the workspaceId as 'one workspace', but does not add substantially new meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs bounded, read-only KQL queries against a single Log Analytics workspace, specifically for telemetry, logs, events, metrics, and time-series data. This specific verb+resource+scope distinguishes it from sibling tools like query_azure_resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (telemetry, logs, etc.) and when not to use (Azure resource inventory/config), with a direct pointer to the alternative tool query_azure_resources. This provides clear decision-making guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or search tables in a Log Analytics workspace using ARM metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Optional name or description substring. | |
| workspaceResourceId | Yes | Full ARM resource ID of the workspace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds that it uses ARM metadata, clarifying it operates on metadata rather than querying data. However, it does not disclose additional behaviors such as pagination, return format, or search semantics beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that immediately conveys the tool's purpose. No redundant or filler content exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list/search tool with strong annotations and full schema coverage, the description is nearly complete. It lacks explicit details about the return value, but with no output schema and a straightforward use case, the provided information is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both workspaceResourceId and search having descriptive text. The description itself does not add parameter-level detail, but that is acceptable given the complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists or searches tables in a Log Analytics workspace, specifying the resource type (tables) and context (Log Analytics workspace). This distinguishes it from siblings like query_workspace (querying data) and describe_table (specific table details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: if you need to list or search tables, use this tool. However, there is no explicit guidance on when to use this versus alternatives like describe_table for table details or list_workspaces for workspace discovery. No exclusions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: workspace discovery, table exploration, schema inspection, Log Analytics queries, and Resource Graph queries. The two query tools explicitly cross-reference each other to prevent confusion.
All tool names follow a consistent verb_noun pattern (list_workspaces, search_tables, describe_table, query_workspace, query_azure_resources), making the API predictable and easy to navigate.
Five tools is well-scoped for an Azure query-oriented MCP server. Each tool addresses a necessary step in the workflow without bloat or redundancy.
The server covers the full lifecycle of querying Azure: discovering workspaces, exploring tables, understanding schemas, and running both telemetry and resource queries. No obvious gaps exist for its intended use case.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only MCP access to sessions, funnels, campaigns, errors, live visitors, and anomalies.
Read-only MCP access to a documented IT fleet: state, changes, posture. 15 tools.
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kapetanios55/azure-query-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
