graph-atlas-mcp

Server Quality Checklist

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

Latest release: v0.1.5
Disambiguation5/5
Each tool has a clearly distinct purpose: history vs detail vs summary vs permission context vs search vs filter vs report vs visualize vs expand vs object search vs timeline. The overlapping history tools are explicitly differentiated, with get_object_history providing full change history and get_node_timeline being a compact visualizer companion.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (get_*, search_*, visualize_*, expand_*), which is good. The exception is 'schema_change_report', a noun phrase that breaks the pattern slightly, but it's still readable and doesn't cause confusion.
Tool Count5/5
11 tools is within the ideal 3-15 range and each tool covers a distinct aspect of the Graph schema, change history, permissions, and visualization domain. No redundancy or excessive fragmentation.
Completeness4/5
The set covers search, change history, permission context, schema reporting, and interactive visualization comprehensively. A minor gap is the lack of a direct tool to fetch a single entity's full property definition, but this is accessible via expand_schema_node or the visualizer, so it's workable.
Average 4.1/5 across 11 of 11 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 57 commits in the last 12 weeks
- Last stable release on August 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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 the full burden of behavioral disclosure. It indicates a read-only query via the word 'query' but omits important behavior such as default date range, pagination, output format, or side effects. The description does not add meaningful context beyond the basic query nature.
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, front-loaded sentence that efficiently summarizes the tool's purpose and main features. There is no wasted wording, and it is easy to scan.
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 7 optional parameters, no output schema, and no annotations, the description is too sparse. It lacks critical context such as what 'recent' means (time range), default behavior, how results are returned, or how this differs from sibling tools like search_changes. The tool is not adequately specified for an agent to select and invoke it confidently.
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 coverage is only 43%, so the description partially compensates by listing filter dimensions (date, endpoint, object type/name, change kind, source) that map to the parameters. However, it does not explain parameter meanings or formats beyond what's already in the schema, leaving some parameters like 'source' and 'endpoint' without additional semantics.
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 identifies the tool as a structured, filterable query over change history and lists the key filter dimensions (date, endpoint, object type/name, change kind, source). This is a specific verb+resource pairing, though it doesn't explicitly differentiate from the sibling search_changes, which may also query change history.
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 get_object_history or search_changes. It only implies usage through 'filterable query' but gives no context about which scenarios call for this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the timeline is newest-first and compact, which is useful. But it does not describe what a 'change timeline' contains, how the limit parameter behaves, or whether it is read-only (though this is implied). More detail could be added without much cost.
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?
Two sentences, front-loaded with the core purpose, and no redundant phrasing. Every word earns its place.
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?
The description is adequate for a simple read tool but lacks details on return format or content. With no output schema, the agent must infer what a 'timeline' consists of. The reference to get_object_history helps, but more explicit information about the response shape would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description adds no information about parameters. It does not explain the meaning of 'limit' or 'endpoint', and 'since' is only briefly described in the schema. The description should compensate for half the parameters being undocumented, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a compact newest-first change timeline for a single schema object, and the phrase 'App-facing companion to get_object_history' distinguishes it from the sibling get_object_history tool. This is a specific verb+resource with clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it is the app-facing companion to get_object_history and is sized for the visualizer detail panel, which gives clear context for when to use it. However, it does not explicitly state when not to use it or mention alternatives like get_recent_changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose significant behavior: 'full history' and 'oldest to newest' (ordering). However, it omits any mention of read-only semantics, pagination, rate limits, or return format, which are common behavioral disclosures for history tools. The provided ordering is useful, but the lack of other context keeps it at a mid-range score.
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, front-loaded sentence that succinctly communicates the tool's core functionality and ordering. There is no wasteful text, and the structure is clear and readable.
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 lack of output schema and annotations, the description is somewhat thin. It conveys purpose and ordering but does not describe the response shape, any limitations, or prerequisites. For a 3-parameter tool, this is acceptable but leaves gaps that could confuse an agent expecting more operational detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, and the description does not compensate for the undocumented 'endpoint' parameter. The phrase 'specific Graph object type' loosely references object_name, but adds no real meaning beyond the schema's examples. The 'since' parameter is not mentioned, so the description adds little value to parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'full change history for a specific Graph object type, oldest to newest', which is a specific verb+resource. It also includes a user-oriented question ('what has happened to X over time?') and distinguishes from siblings like get_recent_changes by emphasizing 'full' and chronological order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when you need a complete historical timeline of a Graph object. It implies a contrast with recent-changes tools, but does not explicitly name alternatives or provide when-not-to-use guidance, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It states that the tool returns metadata counts and size, implying a read-only operation, but it does not explicitly confirm safety, explain response structure, or mention side effects. Adequate but not rich.
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 extremely concise—two clauses and a use-case question—with no filler. Every sentence adds context, and the structure is easily scannable.
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?
The tool is simple, with no required parameters and no output schema. The description covers the core return values (counts, size, change count) and mentions trend analysis, but lacks details on how to perform trend analysis (e.g., multiple dates) and the default behavior of 'date' is only in the schema. It is minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: the 'date' parameter is described in the schema, but 'endpoint' is not. The tool description adds no parameter information and does not clarify the meaning of 'endpoint' (e.g., which Graph API version). The enum provides allowed values, but semantics are incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: providing snapshot metadata with entity/property/enum counts, CSDL size, and change count. It also includes a concrete use case ('How big is Graph API now?'), which distinguishes it from siblings focused on history, changes, or schema graphs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for understanding overall snapshot size and trends. It gives context ('trend analysis') but does not explicitly exclude alternatives or mention when to choose this over related tools like get_recent_changes or schema_change_report. Still, the context is clear enough for a basic decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool returns structured JSON (no UI), describes the three view modes, and notes that the endpoint parameter only applies to view=entity. However, it does not explicitly state whether this is a read-only operation or what side effects (if any) might occur, leaving some ambiguity.
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 information-dense but each sentence adds value: it starts with a clear summary, then details each view and the relationship to visualize_schema_graph. It could be slightly better formatted but remains within a reasonable length.
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?
The description gives a high-level view of the output (nodes+edges+change counts) and explains the main parameters. However, without an output schema, it doesn't fully specify the return structure, and details like limit semantics and change-activity count definitions are absent. Still, the 'same data as visualize_schema_graph' reference provides useful context.
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 description enriches parameter meaning beyond the schema by explaining how view and object_name interact: view=entity focuses on an entity, view=permission on permission scopes, and view=role for comparing roles. It also clarifies that omitting focus_object yields an overview and that endpoint only applies to entity view, which the schema doesn't convey. The limit and since parameters remain largely described by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool outputs a structured JSON graph with change-activity counts and explicitly differentiates from visualize_schema_graph by noting it provides the same data without rendering. It also defines three views and focus_object semantics, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance for each view: use role view to compare role capabilities, and suggests omitting focus_object for an overview. It also notes the difference from visualize_schema_graph, implying when to choose this tool over the visualization sibling, though it doesn't mention other change-related alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It reveals the hybrid algorithm (BM25 + semantic, Reciprocal Rank Fusion) and the fallback behavior when OPENAI_API_KEY is missing. It also identifies the data sources searched. This goes beyond a generic 'search' claim, though it doesn't detail return structure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that gets straight to the point. It covers purpose, scope, search mechanism, and a conditional dependency without wasted words. Every clause contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides sufficient context for a search tool: it names the sources, explains the hybrid mode, and notes the fallback. With no output schema, it doesn't describe result format, but that is not critical for a search invocation. It lacks explicit guidance on when to use alternative search tools, but overall it is complete for most use cases.
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 baseline is 3. The description itself does not add parameter-level detail beyond the schema; it mentions natural-language/keyword queries and mode degradation, which are already present in the schema descriptions for 'query' and 'mode'. No additional meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search'), the resource ('Microsoft Graph API change history'), and the scope ('across all sources (seed-entra-ms, backfill-graph-changelog, self)'). This distinguishes it from sibling tools like search_schema_objects and get_recent_changes, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('Search Microsoft Graph API change history') but does not explicitly state when to prefer this tool over alternatives or provide exclusions. For example, it doesn't mention that search_schema_objects is for schema objects or get_change_detail for specific change details. However, the context is clear enough for an agent to infer common use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses key behavior: it returns related changes and permission context, and warns that the permission context is heuristic, pointing to another tool for the caveat. This adds valuable context beyond a simple 'get' operation.
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 sentence that is front-loaded with the core purpose and then efficiently packs related details and a pointer to another tool. It is concise without being overly terse, though splitting into two sentences could improve readability slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description adequately covers what is returned (full detail, related changes, permission context) and drawbacks (heuristic caveat). It is sufficiently complete for an AI agent to decide whether to use it.
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 coverage is 100% and the single parameter is described adequately as 'Change record ID'. The description does not add further parameter-level detail, so the schema does the heavy lifting, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Full detail for a single change record' with a specific verb and resource, distinguishing it from sibling tools like get_recent_changes and search_changes. It further differentiates by mentioning related changes and permission context, explicitly pointing to get_permission_context for the heuristic caveat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when full detail on a single change record is needed) and references get_permission_context for a specific caveat, giving an alternative. It does not explicitly state when not to use it, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses ranking behavior ('prefix matches rank first'), return structure ('ranked candidates {id, kind, label, sub}'), and fuzzy matching. This is meaningful behavioral context. However, it does not mention edge cases like no results or query length constraints, so it is not exhaustive.
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?
Two sentences, front-loaded with purpose, then return behavior. Every phrase adds value (scope, downstream usage, output shape, ranking). No filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 4 params and no output schema, the description explains the purpose, the kinds searched, the return format, ranking order, and downstream consumers. It is missing explicit guidance on limit and endpoint semantics, but those are partially covered by schema. Overall it provides enough context for an agent to invoke the tool correctly.
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 50% (kinds and endpoint have descriptions; query and limit do not). The description adds meaning for query ('fuzzy names') and kinds ('Graph entity types, permission scopes, and Entra roles'), but it does not clarify limit or endpoint beyond schema defaults. It partially compensates for the gap but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is very specific: 'Name search across Graph entity types, permission scopes, and Entra roles' names the verb, resources, and scope. It also states the outcome ('resolves fuzzy names to canonical node ids') and explicitly references sibling tools visualize_schema_graph / expand_schema_node, which clearly differentiates it from other search tools like search_changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the downstream use case ('for visualize_schema_graph / expand_schema_node'), telling the agent when to invoke this tool. It implies an alternative (for changing data, use search_changes or get_recent_changes), but it does not explicitly list when not to use it or name alternative tools. Clear context but not a full exclusionary set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description discloses the output shape, the variant-specific behaviors, and the fact that the role mapping is a 'heuristic role map.' It also makes clear result is a delta to merge into the canvas. A minor gap is that it doesn't explicitly state read-only/side-effect semantics, but the wording strongly implies a graph-query operation.
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 front-loaded with the main purpose and is information-dense without wasted words. It is a single long sentence, but the enumerations are clear and every clause adds behavioral value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/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 unusually complete: it explains the return structure and all kind/view combinations. The only notable gap is that the effects of optional params like since and endpoint are not fully integrated into the behavior description.
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?
Schema coverage is already high (80%), and the description adds further meaning beyond the schema by explaining exactly what each kind and view combination yields. The description particularly clarifies the ambiguous view parameter for EntityType and the difference between entity/permission/role expansion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Expand one node of the schema graph' and clearly defines the return as a {nodes, edges, message} delta. It distinguishes itself from the sibling visualize_schema_graph by calling itself 'the interactive companion,' and it enumerates what each kind returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use it for expanding a single node with different views rather than the whole schema graph. It also explains which behavior to expect for EntityType vs Permission vs Role, although it does not explicitly name sibling tools as alternatives to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds valuable context about release behavior: the database is re-released daily as calendar-tagged GitHub releases, while server code uses semver on npm. This goes beyond a simple label and helps set expectations, though it doesn't explicitly state the tool is read-only.
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 appropriately sized: it starts with a clear heading phrase, lists content areas, explains release mechanics with examples, and ends with concrete use cases. Every sentence adds value, and the structure is logical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is complete. It covers what information is available, how releases are versioned, and when to call it. No critical gaps are apparent.
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 zero parameters, and schema coverage is trivially 100%. The description does not need to explain parameters, so the baseline of 4 applies. It correctly focuses on the informational content returned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as providing server information: running version, changelog entry, data freshness, and release mechanics. It distinguishes from sibling tools by focusing on server-level info rather than schema objects or changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to call the tool: 'what version is this?', 'what's new in the latest Graph Atlas release?', or to check data currency. While it doesn't explicitly name alternative tools or exclusions, the usage triggers are clear and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It explicitly states that it does NOT rank or compute least privilege automatically, explains why resource count and ownership scoping are different axes, and warns that role-permission cross-referencing is heuristic and not ground truth. This gives the agent a realistic model of the tool's capabilities and limitations.
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 information-dense but efficiently structured, opening with 'Two modes' and then detailing each mode and relevant caveats. Every sentence contributes value, including the anti-goal clarification about least privilege and the heuristic caveat. It is long but not wasteful, and front-loaded with the most important usage differentiator.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description is remarkably complete. It describes what each mode returns, the fields used for reasoning, the notion of ownership scoping, and important failure modes (heuristic correlation). It even clarifies that the tool does not decide for the user, which sets expectations for downstream reasoning. The only minor gap is not detailing the behavior of 'recent changes', but this is not critical to selecting/invoking the tool.
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 description adds meaningful context beyond the schema by explaining how object_name and permission_name mode switch, and what is_ownership_scoped means in the output. It does not elaborate on limit or endpoint, but limit has a schema description and endpoint is an enum. The addition clarifies the relationship between parameters and the output semantics, so it goes beyond the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with specific verbs: it lists permissions touching a Graph object, what each unlocks, who can grant them, and recent changes. It also details the second mode for comparing a permission's detail with overlapping alternatives. This is distinct from sibling tools focused on history, schema, or change snapshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use each mode, including a concrete example comparing a less-privileged alternative. It implies when to use the tool (for permission analysis) and hints at limitations (does not rank or claim to compute least privilege). However, it does not explicitly name alternatives or exclusions relative to sibling tools, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It thoroughly discloses the tool's interactive UI behavior, the semantics of nodes and edges (e.g., 'nodes = entity types, colored by distance from the focus, with recent-change activity badges'), and the fact that the user can continue exploring in the UI. It also clarifies the alternative schema_change_report does the same data without rendering, adding behavioral context.
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 appropriately sized for its complexity. It starts with the main purpose, then systematically explains each view, and ends with alternatives—every sentence contributes necessary information without redundancy or fluff. The structure is logical and easy to follow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking annotations and an output schema, the description is remarkably complete. It covers the tool's purpose, all configurable aspects (view, focus_object), interaction model, and relationships to sibling tools. It even explains the visual details (color-by-distance, badges) and the non-rendered alternative, giving the agent enough context to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema includes descriptions for since, endpoint, and focus_object, the 'view' parameter has no schema description, and the description fills this gap with detailed semantic guidance. It maps each view to specific focus_object types, provides real-world examples, and explains the default when focus_object is omitted. This significantly exceeds what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens the Graph Atlas visualizer, a force-directed schema graph, and distinguishes it from schema_change_report ('use schema_change_report for the same data without rendering'). It uses specific verbs ('Open', 'visualizer') and specifies the resource, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance for each view ('entity', 'permission', 'role') with concrete examples of focus_object values (e.g., 'group', 'User.Invite.All'). It also instructs when to omit focus_object ('Omit focus_object for an overview') and names alternatives (expand_schema_node, schema_change_report), giving clear context for choosing this tool versus siblings.
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:

[![graph-atlas-mcp MCP server](https://glama.ai/mcp/servers/darrenjrobinson/graph-atlas-mcp/badges/card.svg)](https://glama.ai/mcp/servers/darrenjrobinson/graph-atlas-mcp)

Score Badge

Copy to your README.md:

[![graph-atlas-mcp MCP server](https://glama.ai/mcp/servers/darrenjrobinson/graph-atlas-mcp/badges/score.svg)](https://glama.ai/mcp/servers/darrenjrobinson/graph-atlas-mcp)

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/darrenjrobinson/graph-atlas-mcp'

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