Loading ToolBench
NetworkX Graph MCP Server - State/decision graph creation and management for AI agents
This STDIO-only server presents 20 tools for state/decision graph management. While tool definitions are visible and schemas are present, there are significant gaps in description quality, parameter documentation, and error handling patterns. Tools like `create_state_graph` and `delete_state_graph` have minimal descriptions (under 20 chars for some parameters). Parameter descriptions are largely absent, most params lack contextual guidance on valid ranges, formats, or dependencies. Output schemas are not documented anywhere, forcing LLMs to infer what these tools return. Error handling is generic ('Internal error') with no recovery guidance. The naming is mostly sound (verb_noun pattern), but the overall implementation reads as a basic scaffolding rather than production-grade tooling. This score reflects a C-grade community server with clear potential but significant polish needed before production use.
Add an edge with order and optional condition.
Add a node (action/decision/verification/loop/success/failure).
Create a new state/decision graph (directed, cycles allowed).
Delete a state graph.
Export a graph to JSON format.
Export a graph to YAML format.
Get edges (optionally filter by node).
Output schemas undocumented. No specification of what tools return, LLMs must infer structure from operation names alone. This violates pattern:tool and forces agents to guess at response fields and types.
Parameter descriptions largely absent or minimal. Most params (graph_id, node_id, from, to, etc.) have no contextual description explaining format, constraints, or valid ranges. Baseline: 100% of A+ tools have parameter descriptions; this server has ~15%.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get node details.
Get graph metadata and stats.
Import a graph from JSON file.
Import a graph from YAML file.
List all nodes.
List all available state graph files on disk (memory resets each session, so this scans for YAML/JSON files in graphs directories). Returns file paths that can be imported.
Remove an edge.
Remove a node.
Set condition label for an edge.
Set execution order for an edge.
Update node properties (label, phase, tool, properties).
Validate graph structure (allows cycles, checks for isolated nodes and multiple entry points).
Render graph to PNG file (supports spring, circular, kamada_kawai layouts).
Generic error handling with no recovery guidance. Error response is always 'Internal error: {str(e)}', no categorization (retryable vs fatal), no invalid value echoed back, no suggestions for next steps. Agents cannot self-correct. Violates pattern:recovery-guide.
Destructive operations (delete_state_graph, remove_node, remove_edge) lack confirmation or dry-run support. No validation that the resource exists before deletion. Agents make mistakes, these tools could silently fail or succeed unexpectedly. Violates pattern:confirmation-request.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) in tool definitions. The server marks tools with 'Risk: READ_ONLY, WRITE, DESTRUCTIVE' in metadata but does not expose these hints in the MCP tool schema. Clients cannot distinguish safe from unsafe operations without reading external documentation.
Missing input validation and range constraints. Parameters like 'phase' (integer), 'dpi' (integer), 'order' (integer) have no min/max bounds declared. An LLM could pass phase=-999 or dpi=1000000, causing undefined behavior or resource exhaustion.
Path traversal risk. Tools like 'export_graph_yaml', 'export_graph_json', 'import_graph_yaml', 'import_graph_json', 'list_state_graphs' accept 'output_path', 'file_path', 'directory' parameters without path sanitization visible in the code snippet. An LLM could be tricked (via prompt injection) into writing files outside intended directories or reading sensitive system files.
No pagination support for list operations. 'list_state_graphs' and 'list_nodes' may return unbounded result sets. If a graph has thousands of nodes, returning all of them wastes tokens, bloats context, and risks hallucinations. Violates pattern:paginated-result.