Zovo ER Diagram

Check database schema

check_schema

Read-onlyIdempotent

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.

Input Schema

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.

Output Schema

Name	Required	Description	Default
`notes`	Yes
`ready`	Yes
`shown`	No
`counts`	Yes
`issues`	Yes
`limits`	Yes
`dialect`	Yes
`skipped`	Yes
`name_rule`	Yes
`tables_without_primary_key`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.6/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

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?