Loading ToolBench
An MCP server that parses Mermaid ER diagrams and provides database schema information, SQL generation, and REST/GraphQL CRUD APIs
This MCP server provides 12 tools for parsing Mermaid ER diagrams and managing PostgreSQL schemas. Tool definitions are present with descriptions and input schemas visible in dbTools.ts and diagramTools.ts. However, critical gaps reduce quality: (1) Parameter descriptions are minimal or missing for core inputs, many params lack explanation of their purpose, format, or constraints. (2) Output schemas are NOT documented anywhere in the code, callers cannot know what fields to expect from responses. (3) Error handling is present but inconsistent, some tools return structured error objects, others likely fail with generic errors. (4) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite having tools like drop_schema that are clearly destructive. (5) Parameter naming is sometimes ambiguous, 'diagram' is optional everywhere but fallback behavior is not documented in descriptions. Overall, the server has the foundation of a functional tool suite but lacks the polish needed for reliable LLM-driven usage. Descriptions are adequate in length (average ~100 chars) but often lack actionable detail. Schemas use Zod but outputs are untyped from the LLM's perspective.
Create PostgreSQL tables from the ER diagram. This will execute DDL statements to create tables and foreign key constraints.
Drop all tables defined in the ER diagram. WARNING: This will delete all data!
Generate SQL DDL statements from the ER diagram without executing them. Useful for reviewing the SQL before creating tables.
Get information about the running API server and its endpoints.
Get detailed information about a specific entity including all its attributes, types, and keys (PK, FK, UK).
Get all relationships between entities in the ER diagram with cardinality information.
Output schemas completely undocumented. No tool returns a documented output schema. LLMs cannot know what fields to expect or plan downstream tool calls. For example, parse_er_diagram, list_entities, and get_api_endpoints return complex objects but the response structure is invisible to the LLM.
Missing tool annotations. Tools with destructive side effects (drop_schema, create_schema with dropExisting=true, start_api_server, stop_api_server) lack destructiveHint or readOnlyHint annotations. LLMs cannot distinguish safe reads from dangerous mutations without explicit hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
List all entities (tables) in the ER diagram with their names and aliases.
Parse a Mermaid ER diagram and extract the complete database schema including entities, attributes, and relationships.
Start the REST/GraphQL API server for the entities in the ER diagram.
Stop the running API server.
Test the PostgreSQL database connection. Returns success or error message.
Validate a Mermaid ER diagram for syntax errors and structural issues.
Optional 'diagram' parameter lacks dependency documentation. Every tool that accepts 'diagram' as optional with a fallback to configured source must document: (1) what happens if neither provided, (2) which takes precedence, (3) where the default comes from. Currently descriptions say 'Uses configured source if not provided' but LLMs cannot infer the selection logic.
Parameter descriptions lack actionable constraints. 'diagram' params are documented as 'Mermaid ER diagram text' but don't specify: (1) minimum/maximum length, (2) valid Mermaid syntax requirements, (3) what constitutes a valid entity or relationship. 'entityName' in get_entity_details is not described at all, LLM must infer it from context.
drop_schema confirmation is fragile. The 'confirm' parameter requires true, but there's no guidance in the description on what happens if false, whether the operation is reversible, or what data loss entails. Description does state 'WARNING: This will delete all data!' but doesn't explain recovery options or impact scope.
Error guidance inconsistent. Some tools (test_connection, generate_sql) return structured error objects with 'success' and 'error' fields. Others (validate_diagram, start_api_server) likely throw or return generic failures. LLMs need predictable error classification (retryable, user-fixable, fatal) across all tools.
No pagination support for list_entities or get_relationships. If an ER diagram defines 100+ entities or complex relationship graphs, these tools will return massive unstructured lists. No limit parameter, no cursor/offset, no total count. Large responses blow context windows.
Composition gap: multiple tools operate on 'diagram' but none chainable. If parse_er_diagram extracts entities, the response must include entity names that get_entity_details accepts. Currently unclear if response field names match input parameter expectations.