这是一个模型上下文协议 (MCP) 服务器，提供对 Azure Resource Graph 查询的访问权限。它允许您使用 Resource Graph 查询检索跨订阅的 Azure 资源信息。
使用 Resource Graph 查询来查询 Azure 资源
默认查询返回资源 ID、名称、类型和位置
支持自定义资源图查询
使用 Azure DefaultAzureCredential 进行身份验证
Related MCP server: Azure DevOps MCP Server
Node.js 已安装
Azure 订阅
已安装并登录 Azure CLI，或已配置其他 Azure 凭据
您可以使用 Cursor IDE 或 Visual Studio Code 运行 MCP 服务器。
要将 MCP 服务器与 Cursor IDE 集成：
将此存储库克隆到您的本地计算机（例如， C:\YOUR_WORKSPACE\azure-resource-graph-mcp-server ）
构建项目：
npm install
npm run build打开游标设置（JSON）并添加以下配置：
{
"mcpServers": {
"azure-resource-graph-mcp-server": {
"command": "node",
"args": [
"C:\\YOUR_WORKSPACE\\azure-resource-graph-mcp-server\\build\\index.js"
],
"env": {
"SUBSCRIPTION_ID": "xxxxxx-xx-xx-xx-xxxxxx"
},
}
}
}注意：确保更新路径以匹配您的本地存储库位置。
重新启动 Cursor IDE 以应用更改
要将 MCP 服务器与 Visual Studio Code 集成：
将此存储库克隆到本地计算机
构建项目：
npm install
npm run build按Ctrl+Shift+P打开 VS Code 设置（JSON），输入“设置（JSON）”，然后选择“首选项：打开用户设置（JSON）”
添加以下配置：
{
"mcp": {
"servers": {
"azure-resource-graph": {
"type": "stdio",
"command": "node",
"args": [
"C:\\YOUR_WORKSPACE\\azure-resource-graph-mcp-server\\build\\index.js"
],
"env": {
"SUBSCRIPTION_ID": "xxxxxx-xx-xx-xx-xxxxxx"
},
}
}
}
}注意：确保更新路径以匹配您的本地存储库位置。
保存settings.json文件
重新启动 VS Code 以应用更改
现在可以在 VS Code 中使用带有光标集成的 MCP 服务器。
服务器提供以下工具：
从 Azure Resource Graph 中检索资源及其详细信息。
参数：
subscriptionId （可选）：Azure 订阅 ID（默认为配置的 ID）
query （可选）：自定义资源图查询（默认为“资源|项目 ID、名称、类型、位置”）
首先，通过运行以下命令确保您已登录到 Azure CLI：
az login此步骤对于本地开发至关重要，因为 DefaultAzureCredential 将自动使用您的 Azure CLI 凭据。
设置环境变量：
将.env.example复制到.env
使用您的实际订阅 ID 更新.env中的AZURE_SUBSCRIPTION_ID
使用 Azure CLI 身份验证时，其他变量（ AZURE_TENANT_ID 、 AZURE_CLIENT_ID 、 AZURE_CLIENT_SECRET ）是可选的
确保已配置正确的 Azure 凭据。服务器使用 DefaultAzureCredential，它支持：
Azure CLI
托管标识
Visual Studio Code 凭据
环境变量
如果使用环境变量，请设置：
AZURE_SUBSCRIPTION_ID
AZURE_TENANT_ID
AZURE_CLIENT_ID
AZURE_CLIENT_SECRET
该服务器包括强大的错误处理功能：
Azure 客户端初始化失败
查询执行错误
无效的查询或参数
从事此项目：
在src目录中进行更改
使用npm run build进行构建
通过运行服务器来测试您的更改
本项目遵循 MIT 许可证。详情请参阅LICENSE文件。
Retrieves resources and their details from Azure Resource Graph. Use this tool to search, filter, and analyze Azure resources across subscriptions. It supports Kusto Query Language (KQL) for complex queries to find resources by type, location, tags, or properties. Useful for infrastructure auditing, resource inventory, compliance checking, and understanding your Azure environment's current state.
| Name | Required | Description | Default |
|---|---|---|---|
| subscriptionId | No | Azure subscription ID | |
| query | No | Resource Graph query, defaults to listing all resources |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool retrieves details and supports KQL for queries, but it does not disclose critical behavioral traits such as whether it's read-only or destructive, authentication requirements, rate limits, or pagination behavior. This leaves significant gaps for an agent to understand how to invoke it safely and effectively.
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 appropriately sized and front-loaded, starting with the core purpose and usage. Each sentence adds value, such as explaining KQL support and use cases, with no redundant information. However, it could be slightly more concise by integrating the use cases more tightly with the main description.
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 complexity of querying Azure resources with KQL and no annotations or output schema, the description is moderately complete. It covers the purpose, usage context, and parameter hints, but it lacks details on behavioral aspects like safety, response format, and error handling, which are important for an agent to use the tool effectively in this context.
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 description coverage is 100%, so the schema already documents both parameters (subscriptionId and query) adequately. The description adds some context by mentioning KQL for complex queries and default behavior, but it does not provide additional semantic details beyond what the schema offers, such as query format examples or subscription ID usage nuances.
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's purpose with specific verbs ('retrieves', 'search, filter, and analyze') and resources ('Azure resources'), and it distinguishes its scope by mentioning Azure Resource Graph and KQL. It provides concrete use cases like infrastructure auditing and compliance checking, making the purpose highly specific and actionable.
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 usage through phrases like 'Use this tool to search, filter, and analyze' and lists scenarios such as auditing and inventory, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. With no sibling tools, the lack of comparative guidance is less critical, but it still lacks explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
query-resourcesScored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap in purpose. The tool 'query-resources' has a clearly defined and singular function, making it impossible for an agent to confuse it with another tool.
Since there is only one tool, naming consistency is inherently perfect. The tool name 'query-resources' follows a clear verb_noun pattern, and there are no other tools to create inconsistency.
A single tool for an Azure Resource Graph server feels thin and under-scoped. While the tool is powerful, typical MCP servers for cloud resource management offer multiple operations (e.g., list, get, filter, aggregate), making one tool insufficient for comprehensive coverage and likely to limit agent workflows.
The tool surface is severely incomplete for the domain of Azure resource management. It only provides a generic query function, missing essential operations like listing resource types, getting specific resources by ID, aggregating metrics, or managing tags, which are common in such systems and necessary for full agent functionality.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Official Microsoft MCP Server to query Microsoft Entra data using natural language
