NetworkX Graph MCP Server

by inbarajaldrin

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, such as add_edge vs. add_node or get_edges vs. get_node_edges, but some overlap exists, like get_graph_stats and get_state_graph_info both providing statistical insights, which could cause mild confusion. The descriptions generally clarify differences, but the overlap in statistical tools is noticeable.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern throughout, such as add_edge, remove_node, and validate_graph, with no deviations in style or convention. This predictability makes it easy for agents to understand and use the tool set without naming confusion.
Tool Count3/5
With 24 tools, the count is borderline high for a graph management server, as it includes many specific operations like set_edge_condition and visualize_graph that might be consolidated. While comprehensive, it feels slightly heavy compared to typical well-scoped sets of 3-15 tools, potentially overwhelming for agents.
Completeness5/5
The tool set provides complete CRUD/lifecycle coverage for graph management, including creation (create_state_graph), reading (get_node, list_nodes), updating (update_node, set_edge_order), deletion (delete_state_graph, remove_node), and additional utilities like import/export, validation, and visualization. No obvious gaps exist for the domain.
Average 2.6/5 across 24 of 24 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits, but it fails to do so. It does not indicate whether this is a read-only operation, if it requires authentication, what errors might occur, or the format of returned details. For a tool with no annotation coverage, this lack of behavioral context is inadequate and leaves critical operational aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, but this brevity results in under-specification rather than efficient communication. While front-loaded, it lacks necessary detail to be helpful. The structure is minimal but fails to convey essential information, making it inefficient in practice despite its short length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by sibling tools and the lack of annotations, output schema, and parameter documentation, the description is incomplete. It does not address what 'node details' include, how results are structured, or any behavioral aspects like error handling. For a tool in a graph management context with no structured support, this description is insufficient to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning beyond the input schema, which has 0% description coverage for its two required parameters ('graph_id' and 'node_id'). It does not explain what these parameters represent, their expected formats, or how they relate to retrieving node details. With low schema coverage and no compensatory details in the description, parameter understanding is severely lacking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get node details' is a tautology that essentially restates the tool name 'get_node' without adding meaningful specificity. While it indicates a retrieval action on a 'node' resource, it lacks details about what 'details' encompass or how this differs from sibling tools like 'list_nodes' or 'get_node_edges'. This minimal phrasing provides only basic intent without distinguishing scope or content from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 does not mention prerequisites, context, or exclusions, such as when to choose 'get_node' over 'list_nodes' for bulk retrieval or 'get_node_edges' for relational data. With multiple sibling tools available (e.g., 'list_nodes', 'get_node_edges'), the absence of any usage instructions leaves the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 but fails completely. It doesn't indicate whether this is a destructive operation, what permissions are required, whether removal is permanent or reversible, what happens to associated edges, or what the response looks like. For a mutation tool with zero annotation coverage, this is critically inadequate.
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 extremely concise at just three words, which could be appropriate if it were informative. However, this brevity results in under-specification rather than efficient communication. The structure is simple but lacks the necessary front-loaded information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations, 0% schema coverage, no output schema, and multiple sibling tools, the description is completely inadequate. It doesn't explain what 'removing a node' entails, what the parameters mean, what happens to graph integrity, or how this differs from related operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning neither parameter (graph_id, node_id) is documented in the schema. The description adds no information about what these parameters represent, their format, or their relationship. For a tool with 2 undocumented parameters, the description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a node' is a tautology that merely restates the tool name without adding meaningful context. While it identifies the verb ('Remove') and resource ('node'), it lacks specificity about what constitutes a 'node' in this graph context or how this differs from sibling tools like 'delete_state_graph' or 'update_node'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 (e.g., whether the node must exist), exclusions (e.g., cannot remove nodes with edges), or relationships to sibling tools like 'remove_edge', 'update_node', or 'delete_state_graph'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'List all nodes' implies a read operation but lacks details on permissions, rate limits, pagination, or output format. It doesn't mention if it returns all nodes globally or within a specific graph (though the schema hints at a 'graph_id' parameter), making behavioral traits unclear.
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 with a single sentence 'List all nodes.' It is front-loaded and wastes no words, making it efficient in terms of brevity, though this conciseness comes at the cost of clarity and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a listing operation with 1 parameter), lack of annotations, 0% schema description coverage, and no output schema, the description is incomplete. It doesn't explain what nodes are, how they relate to the graph, what the output includes, or any constraints, making it inadequate for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter ('graph_id') with 0% description coverage, meaning the schema provides no details. The description 'List all nodes' adds no parameter semantics—it doesn't explain what 'graph_id' is, its format, or how it affects the listing. With low schema coverage, the description fails to compensate, leaving parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all nodes' restates the tool name 'list_nodes' with minimal elaboration, making it tautological. While it indicates a listing action on nodes, it doesn't specify what 'nodes' are in this context or differentiate this tool from sibling tools like 'get_node' or 'get_node_edges', leaving the purpose vague beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With siblings like 'get_node' (for a specific node), 'get_node_edges' (for node relationships), and 'list_state_graphs' (for listing graphs), the description offers no context on selection criteria, prerequisites, or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'Remove an edge' implies a destructive mutation, but it doesn't specify whether this operation is reversible, what permissions are required, how errors are handled (e.g., if the edge doesn't exist), or what the response looks like. For a mutation tool with zero annotation coverage, this is a critical gap.
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 with a single three-word sentence. It's front-loaded and wastes no words, though this brevity comes at the cost of completeness. Every word earns its place, making it structurally efficient despite being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a destructive mutation with three parameters), lack of annotations, 0% schema description coverage, and no output schema, the description is completely inadequate. It doesn't explain what an edge is, how removal affects the graph, what happens on success/failure, or provide any operational context. This leaves the agent with insufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (graph_id, from, to) are documented in the schema. The description adds no information about what these parameters mean, their expected formats, or how they relate to edge removal. For a tool with three required parameters and no schema documentation, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove an edge' is a tautology that restates the tool name without adding meaningful context. While it specifies the verb 'remove' and resource 'edge', it doesn't distinguish this tool from sibling tools like 'remove_node' or explain what constitutes an 'edge' in this graph context. The purpose is minimally stated but lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 (e.g., needing an existing edge), exclusions, or relationships to sibling tools like 'get_edges' (to check edges first) or 'bulk_add_edges' (for batch operations). Without any usage context, the agent has no basis for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 but offers minimal information. It doesn't indicate whether this is a mutation (likely, given 'add'), what permissions are needed, if it's idempotent, what happens on duplicate edges, or what the response looks like. For a tool with 6 parameters and no output schema, this is severely inadequate.
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 with a single sentence: 'Add an edge with order and optional condition.' It's front-loaded and wastes no words, though this brevity contributes to underspecification rather than clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, nested objects, no output schema, and no annotations), the description is highly incomplete. It doesn't explain the tool's role in the graph system, what an 'edge' represents, how parameters interact, or what to expect upon success/failure. This leaves the agent with insufficient context to use the tool effectively.
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 0%, so the description must compensate but only mentions 'order' and 'condition' explicitly. It ignores 'graph_id', 'from', 'to', and 'properties'—which are critical parameters. The mention of 'order' and 'condition' adds some meaning but fails to cover most parameters, leaving significant gaps.
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 'Add an edge with order and optional condition' states the basic action (add edge) and mentions two specific attributes (order, condition), which provides a vague purpose. However, it doesn't specify what type of edge or in what context (e.g., graph, state machine), and doesn't distinguish it from sibling tools like 'bulk_add_edges' or 'set_edge_condition'.
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 choose 'add_edge' over 'bulk_add_edges' for multiple edges, or when to use 'set_edge_condition' versus including condition here. No prerequisites, exclusions, or contextual advice are given.
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 implies a write operation ('Add') but doesn't specify permissions needed, whether it's idempotent, error handling for invalid edges, or what happens on success/failure. The mention of 'order/condition' hints at behavioral traits but lacks detail, resulting in significant gaps for a mutation tool.
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 that front-loads the core action ('Add multiple edges at once') and adds a clarifying parenthetical. There's no wasted verbiage, though it could be more informative without sacrificing brevity.
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 bulk write operation with 2 parameters (including a nested array), 0% schema coverage, no annotations, and no output schema, the description is inadequate. It fails to explain key aspects like input formats, return values, error conditions, or how it differs from similar tools, leaving the agent poorly equipped to use it correctly.
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 0%, so the description must compensate for undocumented parameters. It mentions 'order/condition', which relates to nested properties in the 'edges' array, but doesn't explain the semantics of 'graph_id', 'edges', 'from', 'to', 'properties', or how 'order' and 'condition' function. This adds minimal value beyond the schema's structure.
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 states the tool's purpose as 'Add multiple edges at once (with order/condition)', which clearly indicates it performs a bulk write operation on edges. However, it doesn't explicitly distinguish itself from the sibling 'add_edge' tool beyond the 'multiple at once' aspect, nor does it specify what type of edges or graph system is involved, making it somewhat vague.
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 'add_edge' for single edges or other sibling tools. It mentions 'with order/condition', but this is part of the purpose statement rather than usage advice, leaving the agent without explicit direction on selection criteria.
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 edges with optional filtering, but doesn't describe what 'edges' represent in this context, whether results are paginated, what format they return, or any performance characteristics. For a read operation with zero annotation coverage, this leaves significant behavioral gaps.
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 extremely concise at just 6 words, with no wasted language. It's front-loaded with the core purpose. While arguably too brief for adequate tool documentation, it achieves efficiency in expression 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 tool's moderate complexity (2 parameters, no output schema, no annotations), the description is insufficiently complete. It doesn't explain what constitutes an 'edge' in this graph context, what data the tool returns, or how the optional filtering works. With 15 sibling tools in this domain, more contextual information would be needed for proper tool selection and use.
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?
With 0% schema description coverage for both parameters, the description provides minimal additional semantic information. It mentions optional filtering by 'node' (which likely corresponds to 'node_id'), but doesn't explain what 'graph_id' represents or the relationship between these parameters. The description doesn't compensate for the complete lack of schema documentation.
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 states the tool's purpose as 'Get edges (optionally filter by node)', which provides a basic verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'get_node_edges' or 'list_nodes', leaving ambiguity about its specific scope. The purpose is clear but lacks differentiation from alternatives.
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 mentions optional filtering by node, but doesn't specify scenarios where this is preferable over tools like 'get_node_edges' or 'list_nodes'. There's no mention of prerequisites, exclusions, or comparative use cases with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the action is destructive ('Delete') but doesn't clarify if deletion is permanent, reversible, requires specific permissions, or has side effects on related data. For a destructive operation with zero annotation coverage, this is inadequate.
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 with a single clear sentence. It's front-loaded with the core action and resource, with no wasted words or unnecessary elaboration.
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 destructive tool with no annotations, no output schema, and 0% parameter documentation, the description is insufficient. It doesn't address critical context like deletion consequences, error conditions, or return values, leaving significant gaps for agent understanding.
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?
The schema has 0% description coverage for its single parameter 'graph_id', and the tool description adds no parameter information. It doesn't explain what a graph_id is, how to obtain it, or format requirements. With low schema coverage, the description fails to compensate.
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 ('Delete') and the resource ('a state graph'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'remove_edge' or 'remove_node' that also perform deletion operations on related graph components.
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 (e.g., whether the graph must be empty), relationships to other deletion tools, or what happens to associated nodes/edges when a graph is deleted.
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 'Get graph metadata and stats,' implying a read-only operation, but doesn't specify permissions, rate limits, response format, or error conditions. This is inadequate for a tool with no annotation coverage.
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 graph metadata and stats.' It's front-loaded with the core purpose and has zero wasted words, making it easy to parse quickly.
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 graph operations, lack of annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't clarify what metadata and stats are included, how this differs from similar siblings, or behavioral aspects like error handling, leaving significant gaps for the agent.
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?
The input schema has 1 parameter (graph_id) with 0% description coverage. The tool description adds no meaning beyond the schema—it doesn't explain what 'graph_id' represents, its format, or how it relates to the metadata and stats. This fails to compensate for the low schema coverage.
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 graph metadata and stats' clearly states the action (get) and target (graph metadata and stats), but it's vague about what specific metadata and stats are retrieved. It doesn't distinguish this tool from sibling tools like 'get_graph_stats' or 'list_state_graphs', which likely overlap in functionality.
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. With sibling tools like 'get_graph_stats' and 'list_state_graphs' available, there's no indication of how this tool differs in scope or context, leaving the agent to guess based on tool names 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?
With no annotations provided, the description carries full burden but discloses minimal behavioral traits. 'Set' implies a mutation operation, but it doesn't specify whether this overwrites existing conditions, requires specific permissions, has side effects on graph execution, or what happens if the edge doesn't exist. No rate limits, error conditions, or response format are described.
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 maximally concise with a single sentence that directly states the tool's function. There's zero wasted language or redundancy. However, this conciseness comes at the cost of completeness, as it leaves many important details unspecified.
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 mutation tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is severely incomplete. It doesn't address what the tool returns, error conditions, the nature of 'condition labels' in this graph system, or how this operation fits within the broader graph manipulation context provided by sibling tools.
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?
With 0% schema description coverage for all 4 parameters, the description adds no semantic information beyond what's inferred from parameter names. It doesn't explain what 'graph_id', 'from', 'to', or 'condition' represent, their formats, or constraints. The description mentions 'edge' and 'condition label' but doesn't map these concepts to the specific parameters.
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 'Set condition label for an edge' clearly states the action (set) and target (condition label for an edge), but it's vague about what a 'condition label' represents in this graph context. It distinguishes from siblings like 'add_edge' or 'remove_edge' by focusing on labeling rather than structural changes, but doesn't specify how this differs from 'set_edge_order' or other labeling tools.
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. With siblings like 'add_edge', 'remove_edge', 'set_edge_order', and 'update_node', there's no indication whether this is for workflow conditions, validation rules, or other graph metadata. No prerequisites, exclusions, or complementary tools are mentioned.
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 implies a mutation ('set'), suggesting it modifies data, but doesn't specify if this requires permissions, is reversible, or has side effects. It lacks details on rate limits, error conditions, or what happens if the edge doesn't exist, 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's front-loaded and appropriately sized for the tool's apparent complexity, making it easy to parse quickly without unnecessary elaboration.
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 tool's mutation nature, 4 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain the return value, error handling, or behavioral nuances, leaving the agent with insufficient information to use the tool effectively beyond basic invocation.
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?
The input schema has 4 parameters with 0% description coverage, so the description must compensate. It mentions 'edge' and 'execution order', hinting at 'from', 'to', and 'order', but doesn't explain what 'graph_id', 'from', 'to', or 'order' represent (e.g., IDs, integer meaning). This adds minimal value beyond the schema's structure.
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 'Set execution order for an edge' clearly states the action (set) and target (execution order for an edge), but it's vague about what 'execution order' means in this context and doesn't distinguish it from sibling tools like 'set_edge_condition' or 'get_execution_sequence'. It avoids tautology by not just restating the name, 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 prerequisites (e.g., needing an existing graph or edge), exclusions, or how it relates to siblings like 'set_edge_condition' or 'get_execution_sequence'. Usage is implied only by the action 'set', with no explicit context.
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 action 'Add' but doesn't clarify if this is a mutation (likely yes, given the context), what permissions are required, whether it's idempotent, or how errors are handled. For a tool with 7 parameters and no annotation coverage, this leaves significant behavioral 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 extremely concise—a single sentence that efficiently conveys the core action and node types. It's front-loaded with the essential information and wastes no words, making it easy for an agent to parse quickly.
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 (7 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what a 'node' represents in this graph context, how parameters interact, or what the tool returns. For a mutation tool with rich input schema but zero structured documentation, the description should provide more context to guide effective use.
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 0%, so the description must compensate for undocumented parameters. It only mentions 'node_type' with its enum values, but doesn't explain the purpose of other parameters like 'graph_id', 'node_id', 'label', 'phase', 'tool', or 'properties'. With 7 parameters total and minimal explanation, it fails to add meaningful semantics beyond the bare schema.
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 'Add' and the resource 'node', specifying the types of nodes that can be added (action/decision/verification/loop/success/failure). It distinguishes from siblings like 'update_node' or 'remove_node' by focusing on creation. However, it doesn't explicitly contrast with 'bulk_add_nodes', which handles multiple nodes at once, leaving some sibling differentiation incomplete.
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 (e.g., needing an existing graph from 'create_state_graph'), when to choose 'bulk_add_nodes' for multiple nodes, or how it relates to 'update_node' for modifications. Without such context, the agent must infer usage from the tool name 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 the action (export to file) but lacks behavioral details: it doesn't mention if this is a read-only operation, what permissions are needed, whether it overwrites existing files, or any rate limits. For a file-writing tool with zero annotation coverage, this is a significant gap.
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's front-loaded with the core action and specifies output formats clearly, making it easy to parse quickly.
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 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It covers the basic purpose but lacks details on parameters, behavioral traits (e.g., file handling), and usage context, which are crucial for a tool that writes files.
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 0%, so the description must compensate. It mentions 'YAML or JSON file' which hints at the 'format' parameter, but doesn't explain 'graph_id' (required), 'output_dir', or 'filename'. With 4 parameters and no schema descriptions, the description adds minimal value beyond implying format options.
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 ('Export') and resource ('graph'), specifying the output formats (YAML or JSON file). It distinguishes from siblings like 'import_graph' (import vs export) and 'visualize_graph' (visualization vs file export), though it doesn't explicitly contrast with all siblings.
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 on when to use this tool versus alternatives is provided. While the description implies it's for exporting graphs to files, it doesn't specify scenarios (e.g., backup, sharing) or contrast with siblings like 'get_state_graph_info' (info retrieval vs file export).
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 function but omits critical details: whether this is a read-only operation, if it has performance implications for large graphs, what happens if no path exists, or if there are rate limits. For a computational tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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—a single sentence that directly states the tool's purpose without any fluff. It is front-loaded with the core action ('find shortest path'), making it easy to parse. Every word earns its place, achieving maximum efficiency in communication.
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 pathfinding operation, no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't address what the output looks like (e.g., a path list, distance), error conditions, or dependencies on other tools like 'create_state_graph'. For a tool with three required parameters and computational nature, more context is needed.
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?
The schema has 0% description coverage, meaning all three parameters are undocumented in the schema. The description adds no semantic information about 'graph_id', 'from', or 'to'—it doesn't explain what these represent (e.g., node IDs, names), their formats, or constraints. Since the description fails to compensate for the schema's lack of documentation, the score remains low.
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 ('find shortest path') and the resource ('between two nodes'), making the purpose immediately understandable. It distinguishes itself from siblings like 'get_edges' or 'visualize_graph' by focusing on pathfinding rather than data retrieval or visualization. However, it doesn't specify the type of graph or algorithm used, which prevents 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. It doesn't mention prerequisites like needing an existing graph, nor does it differentiate from potential siblings that might handle similar tasks (e.g., 'get_execution_sequence' could involve paths). Without any context on when or when not to use it, the agent lacks operational clarity.
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 retrieves edges but doesn't mention if it's read-only, requires permissions, handles errors, or returns paginated results. This leaves significant gaps for a tool that likely queries graph data.
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, making it appropriately sized and front-loaded. It conveys the core purpose without unnecessary elaboration.
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 graph operations, lack of annotations, no output schema, and 0% schema coverage, the description is incomplete. It doesn't address return values, error handling, or how edges are structured, leaving the agent with inadequate information for correct invocation.
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 0%, so the schema provides no parameter details. The description adds no meaning beyond the parameter names implied by 'graph_id' and 'node_id', failing to explain what these IDs represent or how to obtain them, which is insufficient given the low coverage.
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 ('Get') and resource ('incoming/outgoing edges for a node'), making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'get_edges' or 'get_node', which might have overlapping functionality, so it lacks sibling differentiation.
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. With siblings like 'get_edges' and 'get_node' that might retrieve similar data, there's no indication of context, prerequisites, or exclusions for usage.
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 provides minimal behavioral insight. It mentions the action ('import') and source formats, but lacks details on permissions, side effects (e.g., overwriting existing graphs), error handling, or output expectations. This is inadequate for a mutation tool with zero annotation coverage.
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 (one sentence) and front-loaded with the core action. Every word earns its place by specifying the resource and source formats without unnecessary elaboration, making it efficient for quick understanding.
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 tool's complexity (mutation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It omits critical details like parameter meanings, behavioral traits (e.g., idempotency, errors), and output expectations, leaving significant gaps for agent decision-making.
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 0%, so the description must compensate but fails to do so. It doesn't explain the two required parameters ('graph_id' and 'path'), such as what 'graph_id' represents (e.g., new or existing graph) or 'path' format (e.g., file path syntax). This leaves parameters undocumented.
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 ('import') and resource ('graph'), specifying the source formats (YAML or JSON file). It distinguishes from siblings like 'export_graph' (opposite direction) and 'create_state_graph' (different creation method). However, it doesn't explicitly contrast with all possible alternatives like bulk 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?
No guidance on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites (e.g., file existence, format specifics), compare to sibling tools like 'create_state_graph' for new graphs, or indicate scenarios where import is preferred over other creation methods.
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. It states this is an update operation, implying mutation, but doesn't disclose behavioral traits like required permissions, whether changes are reversible, error conditions (e.g., invalid node_id), or response format. This is inadequate for a mutation tool with zero annotation coverage.
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's front-loaded with the core action and directly lists the updatable properties, making it easy to parse. 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 tool's complexity (mutation with 6 parameters, nested objects, no annotations, and no output schema), the description is incomplete. It lacks behavioral context, full parameter semantics, and output expectations. For a tool that modifies graph nodes, this leaves significant gaps for an AI agent to understand proper invocation.
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 0%, so the description must compensate. It lists the updatable properties (label, phase, tool, properties), which maps to 4 of the 6 parameters, but doesn't explain the semantics of 'graph_id' and 'node_id' (required identifiers) or provide details on data formats, constraints, or the 'properties' object structure. The description adds some value but doesn't fully address the coverage gap.
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 ('Update') and target resource ('node properties'), and specifies the properties that can be updated (label, phase, tool, properties). It doesn't explicitly differentiate from siblings like 'get_node' or 'remove_node', but the verb 'Update' implies modification rather than retrieval or deletion.
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 (e.g., needing an existing node), exclusions, or sibling tools like 'add_node' for creation or 'remove_node' for deletion. 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. It states the tool creates a new graph but doesn't disclose behavioral traits such as what happens if the graph_id already exists, whether creation is idempotent, permissions required, or what the response includes. This leaves significant gaps for a mutation tool.
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 action and key characteristics (directed, cycles allowed). There's no wasted text, making it easy to parse and understand quickly.
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 no annotations, no output schema, and low schema description coverage, the description is incomplete. It doesn't cover parameter details, behavioral aspects like error handling, or what the tool returns, which is inadequate for a creation tool in a complex graph system with many siblings.
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 1 parameter with 0% description coverage, so the description must compensate. It doesn't explain the 'graph_id' parameter's purpose, format, or constraints (e.g., uniqueness, length). However, with only one parameter, the baseline is higher, but the description adds no value beyond the schema's structure.
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 'create' and the resource 'state/decision graph', specifying it's directed and allows cycles. However, it doesn't distinguish this tool from its sibling 'import_graph' which might also create graphs, leaving some ambiguity about when to use one versus the other.
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 'import_graph' or 'list_state_graphs' for checking existing graphs. It mentions no prerequisites, constraints, or typical scenarios for creating a graph, offering minimal usage context.
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 retrieves statistics, implying a read-only operation, but does not specify whether it requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior beyond the basic purpose.
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—a single sentence that efficiently lists the statistics retrieved. Every word earns its place by specifying the metrics (node counts by type, edges, phases, decision points, loops), with no redundant or vague language. It is front-loaded with the core action ('Get statistics'), making it easy to scan and understand.
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 (a statistical tool with no annotations, no output schema, and 0% schema description coverage), the description is incomplete. It states what statistics are retrieved but does not cover behavioral aspects (e.g., read-only nature, error handling), parameter details, or return format. For a tool in a server with many siblings, more context is needed to ensure proper use without relying on external knowledge.
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 one parameter ('graph_id') with 0% description coverage, and the tool description does not mention parameters at all. Since there is only one parameter, the baseline is 4, but the description fails to add any semantic context (e.g., what 'graph_id' represents or format expectations), reducing the score. It relies entirely on the schema, which lacks descriptions, resulting in minimal but not inadequate coverage.
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 specific verbs ('Get statistics') and enumerates the types of statistics returned (node counts by type, edges, phases, decision points, loops). It distinguishes itself from siblings like 'get_state_graph_info' or 'list_nodes' by focusing on statistical metrics rather than general information or listings. However, it doesn't explicitly contrast with all siblings, keeping it from 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. With siblings like 'get_state_graph_info' (which might overlap in providing graph metadata) and 'list_nodes' (which focuses on node listings), there is no indication of when this statistical tool is preferred or what prerequisites (e.g., graph existence) are needed. Usage is implied only by the tool name and description, lacking explicit context.
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 mentions 'warnings only', implying non-destructive behavior and potential error reporting, but doesn't specify what happens on validation failure, output format, or performance characteristics. For a validation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 with just one phrase, front-loading the core purpose ('validate graph structure') and adding a brief qualifier ('cycles allowed, warnings only'). Every word earns its place with zero waste, making it easy to parse quickly.
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 tool's complexity (validation operation with 1 parameter), no annotations, and no output schema, the description is incomplete. It doesn't explain what validation entails, what 'warnings' might include, how results are returned, or error handling. For a tool that likely returns validation results, this lack of detail makes it inadequate for full understanding.
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 schema description coverage is 0%, so the description must compensate for the undocumented parameter 'graph_id'. However, the description doesn't mention this parameter at all, failing to explain what 'graph_id' represents or how to obtain it. The baseline is 3 since the schema covers the parameter structure, but the description adds no semantic value beyond what's already in the schema.
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 'validate' and resource 'graph structure', making the purpose understandable. It distinguishes from siblings like 'get_graph_stats' or 'export_graph' by focusing on validation rather than retrieval or export. However, it doesn't explicitly contrast with all possible siblings, keeping it at 4 instead of 5.
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 minimal usage context with 'cycles allowed, warnings only', hinting at when validation might be needed (e.g., checking graph integrity). However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_graph_stats' for analysis or 'find_path' for traversal, and doesn't mention prerequisites or exclusions.
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 mentions 'parents before children', which hints at behavioral constraints, but fails to disclose critical traits like whether this is a mutation (likely yes), permissions needed, error handling, or what happens on failure (e.g., partial updates). This leaves significant gaps for a bulk operation tool.
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 with a single sentence that is front-loaded and wastes no words. Every part ('Add multiple nodes at once', 'parents before children') adds value, making it efficient and well-structured.
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 (bulk mutation with 2 parameters, no output schema, and 0% schema coverage), the description is incomplete. It lacks details on behavior, parameters, return values, and error handling, which are crucial for a tool that modifies graph data. The minimal guidance is insufficient for safe and effective use.
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 0%, so the description must compensate. It mentions 'parents before children', which loosely relates to the 'nodes' array parameter but doesn't explain any parameters (graph_id, nodes structure, node_type enum values, etc.). This adds minimal value beyond the schema, failing to address the coverage gap adequately.
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 ('Add multiple nodes at once') and resource ('nodes'), making the purpose understandable. It distinguishes from the sibling 'add_node' by emphasizing bulk operations, though it doesn't explicitly mention all siblings like 'bulk_add_edges' for full differentiation.
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 provides implied usage guidance with 'parents before children', suggesting a specific order for adding nodes in a graph context. However, it lacks explicit when-to-use vs. alternatives (e.g., 'add_node' for single nodes or 'bulk_add_edges' for edges), and no exclusions or prerequisites are mentioned.
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 key behavioral traits: the tool saves files to disk (not base64) and outputs PNG format. However, it doesn't mention permissions needed for file writing, error handling, or whether the operation is idempotent, leaving gaps for a mutation tool.
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 with just one sentence containing no wasted words. It's front-loaded with the core action and efficiently includes critical behavioral details (PNG format, disk storage).
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 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, how errors are handled, or provide sufficient parameter context, leaving too many unknowns for effective use.
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 0%, so the description must compensate. It only implicitly relates to 'output_dir' and 'filename' parameters by mentioning 'saves to disk', but doesn't explain any parameters like 'graph_id', 'layout', or 'dpi'. This insufficiently compensates for the schema gap.
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 ('Render graph to PNG file') and resource ('graph'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'export_graph' which might have overlapping functionality, 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 'export_graph' or other visualization-related siblings. It mentions the output format (PNG) and storage method (saves to disk), but lacks explicit when-to-use or when-not-to-use instructions.
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 of behavioral disclosure. It adds useful context about memory resetting each session and scanning for YAML/JSON files, which clarifies the tool's ephemeral nature and file format focus. However, it lacks details on permissions, error handling, or performance implications, leaving gaps for a mutation-free tool.
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 appropriately concise with two sentences that efficiently convey key information: the action, memory behavior, scanning details, and return value. It's front-loaded with the core purpose, though the parenthetical about memory could be slightly rephrased for clarity. Overall, it avoids unnecessary verbosity.
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 low complexity (1 optional parameter, no output schema, no annotations), the description is moderately complete. It covers the basic operation and return format but lacks details on error cases, directory defaults, or how results are structured. For a simple list tool, this is adequate but not comprehensive.
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 the single optional 'directory' parameter. The description adds marginal value by implying scanning occurs in 'graphs directories' and mentioning YAML/JSON files, but doesn't elaborate on parameter semantics beyond what the schema provides. Baseline 3 is appropriate given high schema coverage.
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: 'List all available state graph files on disk' with the specific action of scanning for YAML/JSON files. It distinguishes itself from siblings like 'list_nodes' or 'get_state_graph_info' by focusing on file discovery rather than graph content. However, it doesn't explicitly contrast with all similar siblings, keeping it from a perfect 5.
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 minimal usage guidance, mentioning that memory resets each session and it scans directories, but it doesn't specify when to use this tool versus alternatives like 'import_graph' or 'get_state_graph_info'. No explicit when-not-to-use or prerequisite information is given, leaving the agent with little contextual direction.
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 key behavioral traits: it follows edges by order attribute, stops at decision nodes by default, and returns a sequence of nodes with details. However, it lacks information on permissions, rate limits, error handling, or what 'details' include (e.g., node properties). This is adequate but has gaps for a tool with no annotations.
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 front-loaded and efficient: two sentences that convey the core functionality and default behavior without waste. Every sentence earns its place by adding value (execution order logic and stopping condition). No redundant or vague phrasing.
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 no annotations, no output schema, and moderate schema coverage (67%), the description is minimally complete. It covers the tool's purpose and basic behavior but lacks details on output format (what 'details' entail), error cases, or integration with sibling tools. For a graph traversal tool with 3 parameters, this is adequate but leaves room for improvement in contextual richness.
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 67% (2 out of 3 parameters have descriptions). The description adds minimal value beyond the schema: it mentions 'from a start node' (covered by schema) and 'Stops at first decision node by default' (hints at 'until_decision' parameter). It doesn't explain 'graph_id' or provide additional context like format or constraints. Baseline 3 is appropriate as the schema does most of the work.
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: 'Get nodes in execution order from a start node, following edges by order attribute.' It specifies the verb ('Get'), resource ('nodes'), and method ('following edges by order attribute'). However, it doesn't explicitly differentiate from siblings like 'find_path' or 'list_nodes', which also retrieve node information but with different logic or scope.
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 by mentioning 'from a start node' and 'Stops at first decision node by default,' which suggests it's for traversing graphs in a specific order. However, it doesn't explicitly state when to use this tool versus alternatives like 'find_path' (which might find paths between nodes) or 'list_nodes' (which lists all nodes without order). No exclusions or prerequisites are provided.
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:

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

Score Badge

Copy to your README.md:

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

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/inbarajaldrin/networkx-graph-mcp-server'

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