Critical gaps across all three tools. Tool definitions are inferred from SQL migration files rather than explicit MCP server code, making actual implementation unverifiable. Descriptions exist but are generic (architect_draft_workflow: 127 chars, architect_publish_workflow: 138 chars, architect_get_workflow: 68 chars). Input schemas visible but lack proper type definitions and parameter descriptions. No output schemas documented. No error handling guidance. No tool annotations. The source provided contains only package.json files and a SQL migration reference, no actual MCP server implementation code is visible.

• Provide actual MCP server implementation code (e.g., src/index.ts or server.ts) showing explicit tool registration with full JSON Schema definitions, not inferred definitions from SQL migrations.
• Add parameter descriptions to all inputs: explain 'prompt' format (natural language constraints), 'current_graph' structure (JSON schema reference), 'graph' validation rules, 'overwrite' behavior, and 'graph_id' format (alphanumeric, length limits).
• Document output schemas for each tool: architect_draft_workflow should specify Graph JSON structure (nodes, edges, metadata); architect_publish_workflow should return {success: bool, graph_id: string, version: string}; architect_get_workflow should return full Graph object with timestamps.
• Expand architect_get_workflow description to 100+ chars: 'Retrieve a published workflow graph definition by ID. Returns the complete graph structure including nodes, edges, and metadata. Use this to inspect or modify existing workflows before publishing updates.'
• Add error handling guidance: 'If graph_id not found, returns 404 with available graph IDs. If graph JSON is malformed, returns 400 with validation errors. If overwrite=false and graph exists, returns 409 Conflict.'