Azure Topology Graph MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose: export_topology for full graph export, find_path for pathfinding between resources, get_neighbors for adjacency queries, get_resource for detailed resource info, refresh_topology for cache updates, and search_resources for filtering. No ambiguity exists as they target different operations on Azure topology data.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with clear, descriptive names (e.g., export_topology, find_path, get_neighbors). The naming is uniform across all six tools, using lowercase with underscores, making them predictable and easy to understand.
Tool Count5/5
With 6 tools, the server is well-scoped for managing Azure topology graphs. Each tool serves a specific, non-redundant function, covering key operations like querying, searching, pathfinding, and cache management without being overly sparse or bloated.
Completeness4/5
The toolset provides strong coverage for querying and analyzing Azure topology, including CRUD-like operations (get, search, refresh) and graph-specific functions (export, find_path, get_neighbors). A minor gap might be the lack of tools for modifying or annotating the topology, but core workflows are well-supported.
Average 2.9/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Export' implies a read operation that generates output, but it doesn't specify whether this is a heavy operation, whether it requires specific permissions, what the output format entails beyond the parameter options, or if there are rate limits. The description adds minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource. However, it could be slightly more informative without sacrificing conciseness, such as hinting at the output's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the exported topology graph contains, how it's structured, or what 'complete' means. Given the complexity implied by 'topology graph' and lack of structured data, more context is needed for the agent to use this effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'format' clearly documented with enum values and default. The description doesn't add any parameter semantics beyond what the schema provides, such as explaining what 'json' versus 'summary' formats entail. 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Export the complete topology graph' clearly states the action (export) and resource (topology graph), but it's somewhat vague about what 'complete' means in this context. It distinguishes from siblings like 'find_path' or 'get_neighbors' by focusing on export rather than querying, but doesn't explicitly differentiate from 'refresh_topology' which might also involve topology operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'refresh_topology' or 'search_resources'. There's no mention of prerequisites, use cases, or exclusions. The agent must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get resources connected' but doesn't disclose behavioral traits like whether this is a read-only operation, what types of connections are considered, if there are rate limits, or how results are returned (e.g., list format). The description is minimal and leaves key behaviors unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Get resources connected to a specific resource'. It's front-loaded with the core action and target, with zero wasted words. Every part earns its place by conveying the essential purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tool that retrieves connected resources, with no annotations, no output schema, and minimal description, this is incomplete. The description lacks details on what 'connected' means, the return format, or any behavioral context, making it inadequate for an agent to use effectively without guesswork.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'resourceId' documented as 'Full Azure resource ID'. The description adds no meaning beyond this, as it doesn't explain what a 'resource' entails or how connections are defined. With high schema coverage, the baseline is 3, but the description doesn't compensate with additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get resources connected to a specific resource' clearly states the action (get) and target (connected resources), but it's vague about what 'connected' means and doesn't distinguish from siblings like 'find_path' (which might find connection paths) or 'search_resources' (which might search broadly). It avoids tautology but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'find_path' for pathfinding or 'get_resource' for single-resource details, nor does it specify prerequisites or exclusions. Usage is implied by the action but not explicitly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states the tool finds a 'connection path,' but doesn't explain what constitutes a connection (e.g., network links, dependencies), whether it returns multiple paths or just one, performance characteristics, or error conditions. For a path-finding tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Find connection path between two Azure resources.' It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a tool with two straightforward parameters. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of path-finding in Azure resources, no annotations, and no output schema, the description is incomplete. It doesn't explain what a 'connection path' entails, the return format, or behavioral aspects like whether it's a read-only operation. For a tool that likely involves graph traversal or dependency analysis, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('sourceId' and 'targetId') clearly documented in the schema as 'Source resource ID' and 'Target resource ID.' The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find connection path between two Azure resources.' It specifies the verb ('Find'), resource type ('Azure resources'), and scope ('connection path between two'). However, it doesn't explicitly differentiate from sibling tools like 'get_neighbors' or 'export_topology' which might also involve resource relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for when path-finding is needed, or comparisons to siblings like 'get_neighbors' (which might show direct connections) or 'search_resources' (which might help identify resources). Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 searching by properties but doesn't describe key behaviors like pagination, rate limits, authentication needs, error handling, or what the output looks like (e.g., list of resources with fields). For a search tool with no annotation coverage, this leaves significant gaps in understanding how it operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with every part contributing to understanding the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a search operation, no annotations, and no output schema, the description is incomplete. It doesn't explain return values, result format, limitations (e.g., search scope), or behavioral aspects like performance or constraints. For a tool with 2 parameters and no structured support, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('query' and 'resourceType') with clear descriptions. The description adds minimal value by implying search across multiple properties, but doesn't provide additional syntax, format details, or examples beyond what the schema specifies. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search' and the resource 'Azure resources', specifying searchable properties (name, type, or other properties). It distinguishes from siblings like 'get_resource' by indicating a broader search capability rather than retrieving a specific resource. However, it doesn't explicitly differentiate from all siblings (e.g., 'find_path' might also involve searching).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer 'search_resources' over 'get_resource' for specific resource retrieval, or how it differs from 'find_path' or other siblings. There are no explicit usage contexts, exclusions, or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves 'detailed information,' implying a read-only operation, but doesn't specify authentication needs, rate limits, error conditions, or what 'detailed' entails (e.g., metadata, configuration, status). This leaves significant gaps for a tool interacting with Azure resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose ('Get detailed information about a specific Azure resource'), making it easy to parse quickly. Every word earns its place, achieving optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (interacting with Azure resources), lack of annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, usage context, and output format. This leaves the agent with gaps, especially for error handling or result interpretation, making it just viable but not fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'resourceId' documented as 'Full Azure resource ID.' The description adds minimal value beyond this, only implying the parameter identifies a 'specific Azure resource.' Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't provide additional syntax or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 a specific verb ('Get') and resource ('Azure resource'), and specifies it retrieves 'detailed information' rather than just basic data. However, it doesn't differentiate from sibling tools like 'search_resources' or 'get_neighbors' that might also retrieve Azure resource information, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'search_resources' (which might list multiple resources) or 'get_neighbors' (which might retrieve related resources). It mentions 'specific Azure resource' but doesn't clarify prerequisites, such as needing a full resource ID versus a name, or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose if this is a read/write operation, its impact (e.g., performance, data freshness), rate limits, or permissions required, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—it directly states the purpose without redundancy. It's appropriately sized for a no-parameter tool and front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 0 parameters and no output schema, the description is minimally adequate but lacks completeness. It doesn't explain what 'topology cache' entails, the outcome of refreshing, or error handling, leaving the agent with insufficient context for optimal use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema coverage, so no parameter documentation is needed. The description adds value by explaining the action involves 're-querying Azure', which provides context beyond the empty schema, justifying a baseline above 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('refresh') and the resource ('topology cache'), specifying it's done by 're-querying Azure'. This distinguishes it from siblings like 'export_topology' or 'search_resources', though it doesn't explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_resource' or 'search_resources'. It implies usage when the cache needs updating but offers no explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![azure_mcp_graph MCP server](https://glama.ai/mcp/servers/dhippley/azure_mcp_graph/badges/card.svg)](https://glama.ai/mcp/servers/dhippley/azure_mcp_graph)

Score Badge

Copy to your README.md:

[![azure_mcp_graph MCP server](https://glama.ai/mcp/servers/dhippley/azure_mcp_graph/badges/score.svg)](https://glama.ai/mcp/servers/dhippley/azure_mcp_graph)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dhippley/azure_mcp_graph'

If you have feedback or need assistance with the MCP directory API, please join our Discord server