An ERD MCP Server: AI Agents That Follow Your Naming Standard

AI agents already write database schemas. Ask Claude or Cursor for a feature and the migration file comes back with tables, columns, and foreign keys — named however the model’s training data leans that day. user_id here, userId there, usr_no when it read one too many legacy dumps. The agent isn’t wrong; it just has no idea your team writes cust_no, because your naming convention lives in a wiki the model has never seen.

That’s the actual problem an ERD MCP server solves. Not “AI can draw diagrams now” — but that schema work done by agents can follow the same standard as schema work done by people. This post explains what sqemo-mcp does, how the naming part works, and — in the same honest-comparison spirit as our dbdiagram comparison — what it doesn’t do yet.

What an MCP server is, in one paragraph

MCP (Model Context Protocol) is the open standard for giving AI agents tools. A server exposes typed operations — “list entities,” “add an attribute,” “export SQL” — and any MCP-capable client (Claude Code, Claude Desktop, Cursor, Codex, and a growing list) can call them. Instead of the agent hallucinating your schema from half-remembered context, it reads the real one and edits it through operations that enforce your rules.

What an agent can do with your ERD

sqemo-mcp exposes 36 tools over your ERD files. Grouped by what they’re for:

Why the naming tools are the interesting part

Most schema tools treat names as free text, so an agent’s naming is only as good as its prompt. Sqemo treats the physical name as computed: you register a glossary (customer → cust, number → no) and naming rules once, and the physical column name is generated from the logical one — same input, same output, for humans and agents alike.

That changes what the agent is asked to do. It doesn’t guess that your team abbreviates “customer” as cust — it says “Customer Number” and generate_physical_name returns cust_no, per your rules, deterministically. And because the correct name is computable, drift is detectable: check_naming and lint_erd flag any column that deviates from what the glossary would generate. The agent’s output is held to the same standard as a human’s — mechanically, not by code-review vigilance. If you want the fuller argument for glossary-based naming, that’s its own post.

Setup

Node.js 22+, no install — it runs via npx. For Claude Code, add to .mcp.json at your project root:

{
  "mcpServers": {
    "sqemo": { "command": "npx", "args": ["-y", "sqemo-mcp"] }
  }
}

Claude Desktop and most other clients take the same mcpServers JSON; the docs page has per-client paths. Local .erd.json files work fully offline with no account. To let an agent touch ERDs saved on the Sqemo server, sign in once with npx sqemo-mcp login — credentials are stored locally, and your password itself never is.

The same enforcement, without an agent

The package doubles as a plain CLI, which is how the standard reaches CI:

npx sqemo-mcp lint schema.erd.json   # exit code 1 on naming violations

Put that in a GitHub Action and a pull request that drifts from the glossary fails the build — the same check the agent runs interactively, enforced mechanically on every merge. There’s also export for generating SQL or DBML in a pipeline. If you’re deciding what artifact should be the source of truth in the first place, we wrote about DBML vs SQL DDL — the .erd.json model sits a layer above both, and the CLI derives either from it.

What it doesn’t do (yet)

Honest limits, so you can decide with eyes open:

Where this fits

If your schema work is entirely human and entirely solo, an MCP server is a nice-to-have. The moment either stops being true — an agent writes your migrations, or more than one person names columns — the question becomes how the standard gets enforced. Our answer: make the correct name computable, then let humans, CI, and agents all be checked against the same computation. Try it in the app (no signup), or point your agent at npx sqemo-mcp and ask it to import your schema.