The fast, Pythonic way to build MCP servers with workflow graph management, node-based execution, and agentic control.
This is a STDIO-only framework server for building MCP servers, not a production-grade MCP server itself. The 11 tools have inconsistent quality: test tools (greet, add, error_tool) are minimal stubs with good schemas but generic descriptions. Graph manipulation tools (create_graph, add_node, add_connection, etc.) lack proper descriptions and have parameter schemas with missing required field declarations. The framework does generate proper MCP tool definitions (to_mcp_tool() method), but the sample server definitions in the codebase are underdeveloped. No output schemas documented. Error handling is minimal, error_tool exists but does not guide recovery. Parameter descriptions are sparse or missing on graph tools.
Add two numbers together.
Connect two nodes in a graph.
Add a node to a graph.
Create a new workflow graph.
Delete a graph by ID.
This tool always raises an error.
Get the structure/specification of a graph.
Get properties of a node in a graph.
Graph tool descriptions are extremely brief and lack context. 'Create a new workflow graph' does not explain when to call it, what a workflow graph is, what it initializes with, or what return value to expect. LLMs cannot reliably select this tool without more detail.
No output schema documented for any tool. Callers do not know what fields to expect in responses, making downstream tool chaining difficult and forcing LLMs to guess field names. This violates the documented output schema requirement.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 14 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | 1.6.0+ | v1 |
Resource endpoint for getting a specific user by ID.
Resource endpoint for getting all users.
Greet someone by name.
List all available graph IDs.
Save a graph to disk.
Resource endpoint for wave emoji.
Welcome prompt template.
Parameter 'workflow_id' in create_graph is optional but lacks description. Unclear what happens if it is omitted, what format it expects, or what 'initialize' means. Parameter descriptions are required for all inputs.
add_node has a 'properties' parameter (object type) with minimal description ('Node properties dictionary'). Does not specify expected keys, value types, constraints, or examples. This is too vague for LLM usage.
Error handling is not documented. error_tool raises an error but does not guide recovery. No tool descriptions explain what errors are possible, when they occur, or how to recover. LLMs get no guidance on failure handling.
Parameter naming is inconsistent. Some tools use 'graph_id' (add_node, get_node_properties, add_connection) while others may use alternative naming schemes. Consistency is required to enable smooth tool chaining.
Tool descriptions do not clarify state-modifying operations. delete_graph and save_graph have WRITE/DESTRUCTIVE risk but descriptions lack language stating 'This permanently deletes...' or 'This saves to disk...'. LLMs cannot infer reversibility from current descriptions.