Atlas works with Prisma through the MCP server Prisma ships inside its CLI, so Atlas can check migration status, run migrate dev, open Prisma Studio, and fix the type errors a new relation introduces. Prisma has shipped MCP inside its CLI since 6.6.0, and you add it with atlas mcp add prisma -- npx -y prisma mcp. Keep DATABASE_URL in .env, not in atlas.json.
What the Prisma MCP server gives Atlas
Prisma ships an MCP server inside its CLI, which gives Atlas 5 real tools: migrate-status, migrate-dev, migrate-reset, Prisma-Login, and Prisma-Studio. With those, Atlas drives migrations directly instead of shelling out, and it can fix the type errors a new relation introduces in the generated client.
The distinction that matters is between an agent that runs a command and an agent that holds a tool. Shelling out means parsing whatever text a CLI happens to print. Holding a tool means calling a defined operation and getting a defined result back. Because Prisma put its MCP server inside the CLI itself, Atlas gets the second kind of access to migrate-status, migrate-dev, and migrate-reset. The payoff shows up on the type-error side of a schema change. Add a relation to schema.prisma and the generated client changes shape, which breaks call sites. Atlas can run the migration and then work that breakage down to zero.
Adding the Prisma MCP server to Atlas
Prisma has shipped MCP inside its CLI since 6.6.0, so adding it to Atlas is one command: atlas mcp add prisma -- npx -y prisma mcp. Nothing separate needs installing, because the MCP server is part of the Prisma CLI you already depend on in the project.
Read the command in two halves. Everything before the double dash is Atlas registering a server named prisma. Everything after it is the command Atlas will run to start that server, in this case npx -y prisma mcp. The -y flag keeps npx from prompting, which matters because the agent launches this process, not you. Since the server is the Prisma CLI itself, it resolves the project's own Prisma version and reads the project's own schema.prisma, so what Atlas sees is what your repo actually declares rather than some globally installed copy.
The five tools: migrate-status, migrate-dev, migrate-reset, Prisma-Login, Prisma-Studio
The local Prisma MCP server exposes 5 tools to Atlas: migrate-status, migrate-dev, migrate-reset, Prisma-Login, and Prisma-Studio. Because Atlas drives migrations through those tools rather than shelling out, it gets structured results back from each migration step instead of scraping terminal output.
Each tool maps to a real point in the Prisma workflow. The migrate-status tool answers whether the database is in sync with the migration history, which is the first question worth asking before any schema change. The migrate-dev tool applies a new migration in development. The migrate-reset tool wipes and reapplies, which is the escape hatch when a development database has drifted past saving. Prisma-Login handles authentication, and Prisma-Studio opens the data browser. Ask Atlas to check migrate-status before it changes anything, since a drifted database explains a surprising share of migration failures.
Adding the remote server for Prisma Postgres management
For Prisma Postgres platform management, add the remote server alongside the local one: atlas mcp add prisma-cloud --url https://mcp.prisma.io/mcp. That leaves you with 2 servers, the local npx -y prisma mcp one for migrations in your repo, and mcp.prisma.io for platform-level management of Prisma Postgres.
Two servers, two jobs, and it is worth keeping them straight. The local server is the Prisma CLI in your project, and its scope is your schema.prisma and your migration history. The remote server at https://mcp.prisma.io/mcp is about the Prisma Postgres platform itself. Registering it under a distinct name, prisma-cloud, keeps the tool names unambiguous when Atlas is deciding which one to call. Add the remote server only if you actually use Prisma Postgres. If your database lives elsewhere, the local server driven by npx -y prisma mcp is the whole integration.
The daily workflow: schema.prisma, migrate dev, then the type errors
The Prisma loop with Atlas runs in 3 moves. Ask Atlas to read schema.prisma, add the relation, and run migrate dev against your shadow database. Then have Atlas regenerate the client and fix every type error the new relation introduces, reviewing each diff as it goes.
Reading schema.prisma first is what keeps the change coherent with the models you already have, including the naming conventions and the relation style your codebase uses. Running migrate dev against your shadow database is where Prisma verifies that the migration it generated actually produces the schema the model file describes. The third move is the one that saves the most human time. A new relation ripples through the generated client and breaks call sites across the codebase, and grinding through those type errors is exactly the mechanical work worth handing to Atlas. Review each diff, because a compiling fix is not automatically a correct one.
Keep DATABASE_URL in .env, not in atlas.json
Keep DATABASE_URL out of atlas.json and let the Prisma CLI read it from .env exactly as it normally does. Prisma already has a well-defined way to load DATABASE_URL, and duplicating that connection string into Atlas configuration gives a live credential 2 places to leak from instead of 1.
The rule is simple and worth being strict about. Prisma's CLI reads DATABASE_URL from .env, and because the MCP server is the Prisma CLI, it inherits that behavior with no help from you. Putting DATABASE_URL into atlas.json changes nothing functionally and creates a second file holding a database credential, one that is far more likely to end up committed. Leave the connection string where Prisma expects it. The integration works the same, and there is exactly one place to rotate the secret when the time comes.
Setup
- 01Add the local server: atlas mcp add prisma -- npx -y prisma mcp. Prisma has shipped MCP inside its CLI since 6.6.0.
- 02Confirm Atlas sees the five tools: migrate-status, migrate-dev, migrate-reset, Prisma-Login, and Prisma-Studio.
- 03For Prisma Postgres platform management, add the remote server too: atlas mcp add prisma-cloud --url https://mcp.prisma.io/mcp.
- 04Keep DATABASE_URL out of atlas.json and let the Prisma CLI read it from .env exactly as it normally does.
- 05Ask Atlas to read schema.prisma, add the relation, and run migrate dev against your shadow database.
- 06Have Atlas regenerate the client and fix every type error the new relation introduces, reviewing each diff before it lands.
Frequently asked questions
- how to add the Prisma MCP server to Atlas
- Run atlas mcp add prisma -- npx -y prisma mcp. Prisma has shipped MCP inside its CLI since 6.6.0, so there is nothing extra to install.
- what tools does the Prisma MCP server expose
- The local Prisma MCP server exposes migrate-status, migrate-dev, migrate-reset, Prisma-Login, and Prisma-Studio, so Atlas drives migrations without shelling out.
- can an AI agent run prisma migrate dev for me
- Yes. Ask Atlas to read schema.prisma, add the relation, and run migrate dev against your shadow database through the Prisma MCP server.
- how do I manage Prisma Postgres with an MCP server
- Add the remote server with atlas mcp add prisma-cloud --url https://mcp.prisma.io/mcp. The local npx -y prisma mcp server handles migrations, and the remote one covers platform management.
- should DATABASE_URL go in atlas.json
- No. Keep DATABASE_URL out of atlas.json and let the Prisma CLI read it from .env exactly as it normally does, so the credential lives in one place.
- how do I fix Prisma type errors after adding a relation
- Have Atlas regenerate the client and fix every type error the new relation introduces, then review each diff. A new relation changes the generated client and breaks call sites.
- what Prisma version added MCP support
- Prisma has shipped MCP inside its CLI since 6.6.0. Add it to Atlas with atlas mcp add prisma -- npx -y prisma mcp.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Refactor a Legacy Module with Atlas in 2026
How to refactor a legacy module with Atlas in 2026: findReferences maps every callsite, apply_patch refuses to apply against a drifted file, and bash proves behavior.
Atlas with Amazon Nova Lite in 2026: 300K Context on Your AWS Bill
Amazon Nova Lite drives Atlas at $0.06 per Mtok input and $0.24 per Mtok output with a 300K token context, billed through IAM with no new vendor API key to manage.
Atlas with Baseten in 2026: 262,000 Tokens In, 262,000 Tokens Out
Atlas with Baseten in 2026: Kimi K2.7 Code at 262,000 tokens in and 262,000 out, GPT OSS 120B at $0.10/$0.50 per Mtok, and the tradeoffs of dedicated hosting.
Atlas with Qwen3-Next 80B-A3B Instruct: Setup, Cost, and Tradeoffs in 2026
Run Atlas, the terminal-native AI coding agent, on Qwen3-Next 80B-A3B Instruct: 128K tokens (131,072) of context at $0.50 per Mtok input and $2.00 per Mtok output.
Atlas with Qwen3.6 Plus: The Stable Million-Token Tier in 2026
Qwen3.6 Plus gives Atlas 1M tokens (1,000,000) of context at $0.50 per Mtok input and $3.00 per Mtok output, matching Qwen3.7 Plus while keeping 3.6 generation behavior.
Atlas for C in 2026
Atlas is a terminal-native AI coding agent for C in 2026. Run it in a project with a Makefile, have it find memory leaks or add Unity tests, and review the diff.
Atlas with Together AI (gateway) in 2026: Open-Weights Models at Scale
Together AI (gateway) drives Atlas with the broadest open-weights catalog: Qwen3.7 Max at $1.25 / $3.75 per Mtok, up to 1M context, US-hosted inference.
Atlas with GLM-4.5-Flash: The Free Reasoning Slot in 2026
GLM-4.5-Flash is listed at $0.00 per Mtok input and output on Z.ai, with the full 128K tokens (131,072) context. Free background traffic for Atlas, rate limited.