Zovo ER Diagram

Make ER diagram

make_er_diagram

Read-onlyIdempotent

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.

Input Schema

Name	Required	Description
`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.

Output Schema

Name	Required	Description	Default
`pdf`	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

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.1/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), yet the description adds substantial behavior: accepted DDL constructs, skipped statements reported with line numbers, refusal on unparsable CREATE TABLE naming the line, a 50-table cap, and ~1 hour link expiry for large diagrams. These are operational constraints an agent cannot get from the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the triggering use case and examples before secondary detail, which is the right ordering. It runs long, and the extended enumeration of return values is somewhat redundant because an output schema exists, but most sentences carry real information (limits, failure modes, expiry).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a 4-parameter tool with an output schema and full annotation coverage, the description still supplies the limits, failure semantics and artifact expiry an agent needs. Nothing material for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains ddl, title, dialect and page_size in depth, and the description largely restates that list (auto/postgres/mysql/sqlite, page size, optional title). No additional syntax or format guidance beyond the schema is provided, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and artifact ("drawn from SQL CREATE TABLE statements") plus concrete example phrasings, so an agent can match the request to the tool instantly. It implicitly separates itself from check_schema by declaring it "Does not connect to a database or run SQL" and produces diagram/download artifacts, but it never names the sibling for explicit differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger ("Use this when the user wants an ER diagram...") reinforced by two sample utterances, and an exclusion (no DB connection, no SQL execution). It omits when-not-to-use relative to check_schema, so the agent must infer the alternative on its own.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Zovo ER Diagram tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?