# AI Help With Your Database Design, Without a Vendor Cloud in the Middle

> You want AI help with schema design, but NDA and IT policy forbid pasting schemas into yet another cloud tool. Schemity is a local MCP server: the agent you already use reads the diagram and stages edits you review, with no database credentials and no diagram vendor in between.

Source: https://schemity.com/blog/ai-database-design-without-the-cloud/

You can get AI help with database design without adding a vendor to the loop: Schemity is database design software that runs an MCP server on your own machine, so the AI agent you already use - Claude Code, Claude Desktop, Cursor, or any other MCP host - reads the diagram through it and stages edits you review before anything is saved. The schema goes only where your agent already sends your code. No diagram vendor's cloud sits in between, the agent never holds database credentials, and a migration only runs from your own click.

AI is genuinely good at schema design. Describe a booking system in two sentences and a model will sketch the entities, the foreign keys, the junction tables - a solid first draft in seconds. Every engineer who has tried it knows the pull.

And every engineer doing client work knows the catch. Your schema is the most honest document your business owns. Table names alone reveal the product roadmap: `subscriptions`, `usage_credits`, `partner_payouts`. Pasting your `CREATE TABLE` statements into a new AI website means handing that document to one more third party - and if the project is [under NDA](https://schemity.com/blog/your-clients-schema-doesnt-belong-in-your-cloud-account/), or your IT department reviews every tool that touches project data, that is not a gray area. It is a no.

## Why is a schema worth protecting from AI tools?

We underrate how much a schema leaks. It is not just structure - it is strategy. The presence of a `trial_extensions` table says something about your conversion funnel. A `soft_deleted_reasons` column says something about churn. Consultants see this clearly because their contracts spell it out: the client's data model is confidential material, full stop.

That is why "just use the AI feature in your diagram tool" fails as advice. The problem was never whether AI could help with database design. It was the route the schema had to travel to get that help - and how many companies stood along it.

## What does an MCP server change?

Most database design software with AI builds the model into the product: the vendor picks the provider, runs the calls through its own stack, and meters the result. That adds a company to your data processing agreement for every tool that does it.

Schemity does the opposite. It runs no model and no AI server of its own. Instead it is an [MCP server](https://schemity.com/doc/ai-assisted-design/) - the Model Context Protocol that agent hosts use to talk to tools - listening only on `127.0.0.1` and requiring a token. Your agent connects to it the way it connects to any other tool, and your diagrams stay [local JSON files](https://schemity.com/blog/erd-lives-in-your-git-repo/) with no account and no sync.

So let's be precise about where the schema goes: to the model your agent host uses, under the agreement you already have for it. If your company has approved Claude Code or Cursor for the codebase, the schema that codebase migrates is not a new disclosure. There is no second AI vendor to review, no diagram company logging prompts, and no new name on the list. And if even that one relationship is off the table - a blanket AI ban, an air-gapped network - an agent host running a [local model](https://schemity.com/blog/ai-schema-help-that-never-leaves-your-machine/) connects to the same server with nothing leaving the machine.

> An MCP server is not an AI feature. It is a statement about who is in the loop: you, and the agent you already chose. Nobody else.

## What can an AI agent actually do with the diagram?

Paste-in, paste-out AI is exhausting: copy schema to browser, get SQL back, re-import, fix the layout, repeat. Over MCP the agent skips the round trip because it works on the diagram you have open. It can read the schema, the [context views](https://schemity.com/doc/context-views/) and the dependencies between them, the schema lint findings, and the documented data dictionary. It can stage changes: describe "an inventory system with lots, batches, and expiry tracking" and the entities and relationships land on the canvas; ask it to "split the address fields out of customers into their own table" and it modifies the diagram in place. It can [group entities into legends](https://schemity.com/blog/reverse-engineer-legacy-database-group-by-domain/) and route relation lines so they cross less.

On a diagram connected to a live database it can also answer the question that matters before a change ships: what would this migration cost? Schemity's impact analysis reports data loss, statements that can fail on existing rows, table rewrites, and dependent views and functions - and the agent reads that report rather than guessing. It can also draw a migration file it wrote as a read-only proposal, which is how [an agent's migration gets reviewed as a schema change rather than as SQL](https://schemity.com/blog/should-ai-agents-write-database-migrations/).

The canvas stays the single source of truth. The agent is a hand on the same whiteboard, not an oracle you transcribe.

## How do you stay in control of an AI agent's changes?

An agent that edits your diagram raises a fair worry: what if it is wrong? Often it will be - first drafts are drafts. That is why nothing it does is final. Staged edits land in the open diagram as unsaved changes. **History** (F6) lists every undo step and names the agent that made it, so an over-eager suggestion is one undo from gone. Nothing writes the diagram file until you save, and nothing an agent does writes to a database: the agent never holds credentials, and a migration only runs when you click Migrate.

That division of labor is the point. Let the agent handle the boilerplate guesswork - the obvious foreign keys, the timestamps, the junction table for the N:N you described - and spend your attention on the decisions that actually need a human: boundaries, constraints, and the business rules hiding between the tables. And the division runs the other way too: once the design is yours, [the ERD can become the spec an AI codes from](https://schemity.com/blog/design-first-ship-by-context/), one bounded context at a time.

AI help for your database design does not have to cost you your schema's privacy, or another vendor review. With database design software on your desktop, it costs one line of agent configuration.