Turns SQL CREATE TABLE statements into an entity relationship diagram you can print.
Score is being calculated.
Use this when the user wants SQL CREATE TABLE statements checked without a drawing, for example "check my schema for broken foreign keys" or "which tables have no primary key". Takes the same DDL text and dialect as make_er_diagram. Returns foreign keys that point to a missing table or column, foreign keys whose referenced columns are not a primary key or UNIQUE, type differences between a foreign key column and the column it references, tables without a primary key, duplicate table and column names (with the name rule used), and the statements it skipped with line numbers. Draws nothing and makes no files. Does not connect to a database or check data.
| Name | Required | Description | Default |
|---|---|---|---|
| ddl | Yes | The SQL DDL text: CREATE TABLE statements with columns, types, NOT NULL, PRIMARY KEY, UNIQUE and REFERENCES / FOREIGN KEY, up to 200,000 characters, e.g. "CREATE TABLE users (id int PRIMARY KEY, email text NOT NULL UNIQUE); CREATE TABLE orders (id int PRIMARY KEY, user_id int NOT NULL REFERENCES users(id));". Other statements are listed as skipped. | |
| dialect | No | Which SQL quoting and type names to read: auto (default; accepts "x", `x` and [x]), postgres, mysql or sqlite. It also sets how names are matched: postgres folds unquoted names to lower case and keeps quoted names exact; the others ignore case. Example: postgres. |
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| ready | Yes | |
| shown | No | |
| counts | Yes | |
| issues | Yes | |
| limits | Yes | |
| dialect | Yes | |
| skipped | Yes | |
| name_rule | Yes | |
| tables_without_primary_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, idempotent, closed-world), yet the description still adds substantive behavior: it enumerates exactly which checks are performed, notes that skipped statements are reported with line numbers, and explicitly rules out side effects ("Draws nothing and makes no files. Does not connect to a database or check data"). That is well beyond what the annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The trigger and examples are front-loaded and the negative scope statements are clustered at the end, which reads well. The long enumeration of return findings is somewhat list-heavy for a tool that already has an output schema, but each item is concrete rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only analysis tool with full schema coverage, annotations, and an output schema, the description covers the trigger, the inputs, the exact checks, the reporting of skipped statements, and the absence of side effects. Nothing an agent needs to select or call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in detail, including dialect folding behavior. The description adds only a cross-reference that the DDL text and dialect are the same as make_er_diagram, which is mild value over the schema baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ("SQL CREATE TABLE statements checked") and immediately scopes it against the sibling by stating "Draws nothing and makes no files", which distinguishes it from make_er_diagram. Two concrete example utterances make the intended job unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the trigger condition ("when the user wants ... checked without a drawing") and gives two realistic user phrasings. It also implicitly routes drawing requests to the sibling via "Draws nothing and makes no files", and "Takes the same DDL text and dialect as make_er_diagram" tells the agent the two tools share inputs but produce different outputs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants an ER diagram, entity relationship diagram or database schema diagram drawn from SQL CREATE TABLE statements, for example "draw an ER diagram of this schema" or "make a PDF of my database tables". Takes the DDL text, a dialect (auto, postgres, mysql, sqlite), a page size and an optional title. Reads CREATE TABLE with columns, types, NOT NULL, PRIMARY KEY, UNIQUE and REFERENCES / FOREIGN KEY, including composite keys; lists every other statement as skipped with its line number. Returns counts, relationships with crow's foot cardinality taken from the DDL, schema problems, a geometry check (overlapping tables, lines crossing a table), the PDF page count and smallest text size, an interactive diagram, and PDF, SVG, CSV and JSON downloads. Refuses a CREATE TABLE that does not parse, naming the line. Up to 50 tables. Does not connect to a database or run SQL. Download links of large diagrams expire after about 1 hour.
| Name | Required | Description | Default |
|---|---|---|---|
| ddl | Yes | The SQL DDL text: CREATE TABLE statements with columns, types, NOT NULL, PRIMARY KEY, UNIQUE and REFERENCES / FOREIGN KEY, up to 200,000 characters, e.g. "CREATE TABLE users (id int PRIMARY KEY, email text NOT NULL UNIQUE); CREATE TABLE orders (id int PRIMARY KEY, user_id int NOT NULL REFERENCES users(id));". Other statements are listed as skipped. | |
| title | No | Title printed on the diagram and used in file names, up to 80 characters, e.g. "Shop database". | |
| dialect | No | Which SQL quoting and type names to read: auto (default; accepts "x", `x` and [x]), postgres, mysql or sqlite. It also sets how names are matched: postgres folds unquoted names to lower case and keeps quoted names exact; the others ignore case. Example: postgres. | |
| page_size | No | PDF page: letter (default), a4 or tabloid (11 x 17 in). Landscape unless portrait needs fewer pages. |
| Name | Required | Description |
|---|---|---|
| Yes | ||
| shown | No | |
| title | Yes | |
| counts | Yes | |
| issues | Yes | |
| tables | Yes | |
| dialect | Yes | |
| skipped | Yes | |
| warnings | Yes | |
| downloads | Yes | |
| name_rule | Yes | |
| layout_check | Yes | |
| relationships | Yes | |
| cardinality_rules | Yes |
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_schemamake_er_diagramTurns a short text description of classes into a UML class diagram you can print.
Turns a few lines of text into a UML sequence diagram you can print.
ER diagrams from SQL, Prisma or ORM models. One tool, no account, nothing stored.
Turns a problem and its list of causes into a fishbone diagram you can print.
Add one secure layer between your agents and this server.