ERD Online uses MCP to let AI agents propose schema changes that humans review

Agents hit a schema blind spot

Modern coding agents can read code, run tests and deploy applications, but database schemas have largely stayed out of their reach. A post on dev.to by the team behind ERD Online argues that the tooling is part of the problem: for roughly two decades the field has been split between heavyweight desktop applications such as Navicat and PDManer, and polished but closed web tools like dbdiagram. According to the author, none of these offer versioning, real-time collaboration or any hook for an AI agent.

ERD Online, the open-source tool the author built in response, combines Git-style versioning with Figma-style multiplayer editing — and, the part that matters here, exposes its data through the Model Context Protocol (MCP).

A small, deliberate set of MCP tools

The post explains MCP as a standard way for AI applications to discover and call external tools, comparing it to a universal connector. The protocol defines three primitives: tools the agent can invoke, resources it can read, and prompts that package recurring tasks.

On top of that, ERD Online exposes a deliberately small surface:

• list_projects returns the user's ERD projects
• get_project fetches a project's projectJSON
• create_version submits a proposed schema change as a new version

The key boundary, according to the post, is that agents read and write the same projectJSON a human designer edits. An agent never generates a diagram free-form from a sentence; it reads what exists and proposes changes that land in the version history.

The workflow: read, propose, review

Setup is a two-step affair. First, mint a personal access token in ERD Online under Account Settings, then Personal Access Tokens — the post says a read-only token is enough to start. Second, register the MCP server in Cursor's ~/.cursor/mcp. configuration file, after which the agent can call the tools directly. The same pattern applies to other MCP-capable clients such as Claude and Cline.

The author contrasts two approaches. The wrong one: ask a model to generate an ER diagram for an e-commerce app, which produces a plausible drawing with no connection to your project, no history and no approval step. The right one: have the agent read the existing schema, suggest changes and submit them as a version that a human reviews and approves.

Guardrails come from versions, not restrictions

What makes this safe, in the author's telling, is not limiting what the agent can see but routing every write through create_version. Each proposal becomes a reviewable version with a diff, so an agent cannot silently alter a schema. That also addresses the classic schema questions the post lists — who changed what, when, why, and how to roll back — because multiple people and agents now write to the same shared history, and changes merge and get reviewed like code.

There is an openness angle as well. projectJSON is an open format, ERD Online can be self-hosted, and the source code is published on GitHub, which the author frames as protection against vendor lock-in.

Why it matters

Schema changes are among the riskiest edits in any system, and until now agents have either ignored them or fumbled through ad-hoc SQL. ERD Online's integration illustrates a broader pattern for making agents useful without making them dangerous: grant structured read access, expose a single constrained write verb, and let the existing human process — diff, review, rollback — absorb the risk. It is the same shape as letting an agent open a pull request instead of pushing straight to the main branch. Whatever traction this particular tool finds, the design is a reusable template for anyone exposing infrastructure to agents: version everything, show the diff, and keep a human at the merge gate.