Vibe coding is fast. You describe what you want, the agent writes it, and the app appears. The trouble starts after the first demo: the agent guesses at an API, the tests were never run, the database schema drifts, and nobody can start the project on a second machine.
Model Context Protocol (MCP) servers give an agent tools for those jobs. Instead of guessing, it can read current documentation, check the running app, and query the real database. Here are ten worth connecting, roughly in order of how often they save a project.
1. Context7: current library documentation
Agents often write code against library versions they half remember. Context7 supplies the current documentation for the library in question, so the agent can check a method signature before using it. It is the cheapest way to cut down on invented APIs.
2. GitHub: issues, pull requests, and CI
The GitHub MCP lets the agent read issues, open pull requests, and check CI status. It closes the loop between "I changed the code" and "the change passed the pipeline", which is where many vibe-coded projects quietly break.
3. Playwright: browser testing
Playwright lets the agent open the running app, click through a flow, and check the result. A generated page that compiles is not the same as a page that works, and a browser test is the closest thing to what a user sees.
4. TDK CLI: the local stack
Most vibe-coded apps are more than one process: a frontend, an API, a database, a worker. TDK CLI ships an MCP server, started with tdk mcp, that lets an agent run that whole local stack through tools. It exposes six of them: doctor, up, down, status, logs, and resource_list. Each one runs the matching command in JSON mode, so the agent gets structured results it can check.
Two behaviours matter in practice. up returns as soon as it has started the stack, because a build can take longer than a single tool call. The agent should then poll status until readiness.ready is true, which gives it a clear finish line instead of a guess. And doctor reports whether the host can run the stack at all, so the agent can stop and explain instead of retrying.
To connect it in Codex, add a project-scoped entry to .codex/config.toml with command = "tdk", args = ["mcp"], and cwd set to the folder that contains .tdk/project.json. The working directory matters, because the server looks for the project there.
TDK CLI is a local development tool. It does not deploy anything, and deployment stays with your existing tooling.
5. Supabase: database and auth
If the app uses Supabase, its MCP lets the agent inspect tables, check policies, and run queries against the project. Schema changes are the most common source of silent breakage in vibe-coded apps, so an agent that can read the schema is far less likely to invent a column.
6. Figma: design to code
When a design exists, the Figma MCP lets the agent read the frame, its layout, and its tokens. The interface then follows the design instead of the agent's memory of a similar screen.
7. Sentry: errors in production
Once the app is live, the Sentry MCP lets the agent read recent errors and their stack traces. Fixing a bug is much easier with the actual trace in front of it than with a vague report.
8. Filesystem: scoped file access
A filesystem MCP grants the agent read and write access to chosen folders. The useful part is the scope: point it at the project and nothing else. Most agents already have file access, but an explicit, scoped server makes the boundary visible.
9. Chrome DevTools: performance and console
The Chrome DevTools MCP exposes the page's console, network requests, and performance traces. It catches the problems that a passing test misses: a failed request, a slow layout, or a warning that appears only in the browser.
10. Notion or Linear: the plan
Vibe-coded projects drift without a written plan. A tracker MCP lets the agent read the task it is working on, update its status, and leave a note. The plan then lives outside the chat, where it survives a new session.
How to choose
Start with the three that catch the most common failures: documentation (Context7), testing (Playwright), and the local stack (TDK CLI). Add the rest as the project needs them. Scope each server to what the project actually uses, and review what the agent writes before it reaches production.
No MCP server makes a bad design good. What they do is replace guesses with checks, and that is what keeps a fast prototype from becoming a fragile product.
Top comments (10)
The TDK CLI "poll status until readiness.ready is true" pattern is the right one — I've seen too many MCP servers just return "started" and let the agent fly blind.
One thing I'd push back on: #8 (filesystem MCP) sounds safer than it actually is. "Scoped to the project" usually means the agent has read+write access to everything in that folder — including
.env,.git/config, and any build scripts. A read-only filesystem MCP for the "inspect" use case + explicit write for specific files is much safer.Curious about #1 (Context7) — does it cache docs locally or hit the source on every query? Asking because a slow doc fetch mid-generation can burn tokens fast while the agent waits.
just try it
Context7 at number one tracks hard for me. The invented API method is the most common failure I hit when an agent writes code against a library it half remembers. Curious about the Playwright one though: does the browser loop slow the agent down enough that you'd only run it before committing, or do you leave it in the whole session?
Thanks, Ivan. Context7 is the one I’d reach for first too, for the same reason: a checked signature beats a remembered one.
On Playwright: I haven’t measured how much the browser loop slows a session, so I don’t have a number. My suggestion is to scope it rather than leave it running.
Start the browser for a specific flow, run the check, and stop it. Run it before a commit, or when the agent says a UI change is done, not on every edit.
Two behaviours matter in practice. up returns as soon as it has started the stack, because a build can take longer than a single tool call. The agent should then poll status until readiness.ready is true, which gives it a clear finish line instead of a guess. And doctor reports whether the host can run the stack at all, so the agent can stop and explain instead of retrying.
To connect it in Codex, add a project-scoped entry to .codex/config.toml with command = "tdk", args = ["mcp"], and cwd set to the folder that contains .tdk/project.json. The working directory matters, because the server looks for the project there.
TDK CLI is a local development tool. It does not deploy anything, and deployment stays with your existing tooling.
On #6, from building an MCP-based Figma-to-code pipeline: reading the frame is only half of it. With layout and tokens alone, the agent faithfully rebuilds the design out of fresh divs, so it matches the screen and still duplicates your component library. What made it work for us was mapping Figma components to real code components, so the agent resolved to the existing before it wrote anything. Design fidelity and codebase fidelity are two separate problems.
On #5: I’m building becauseiliked.com on Supabase (Postgres + pgvector, RLS on every table), and the schema is exactly where an agent can do the most quiet damage. A missing RLS policy or an RPC like match_items() with a changed signature won’t fail loudly; the app just returns wrong or empty results. So point the Supabase MCP at a dev branch or a read-only role. An agent that can read the schema is great; one that can “fix” it live in production is a different risk.
Thanks, Pushpendra. The Figma point is one I hadn’t put clearly enough: design fidelity and codebase fidelity are separate problems, and the agent can match the first while ignoring the second. Asking it to map frames to existing components before it writes new markup seems like the fix.
On Supabase, I agree with the dev-branch or read-only-role advice. An agent that can write to the schema can also make a query return empty results without any error, so a read-only role for checks is the safer default.
Two behaviours matter in practice. up returns as soon as it has started the stack, because a build can take longer than a single tool call. The agent should then poll status until readiness.ready is true, which gives it a clear finish line instead of a guess. And doctor reports whether the host can run the stack at all, so the agent can stop and explain instead of retrying.
To connect it in Codex, add a project-scoped entry to .codex/config.toml with command = "tdk", args = ["mcp"], and cwd set to the folder that contains .tdk/project.json. The working directory matters, because the server looks for the project there.
TDK CLI is a local development tool. It does not deploy anything, and deployment stays with your existing tooling.
Solid list. One thing I'd add to the MCP discussion: an agent is much more reliable when it can check the running app, not just the code it wrote.
If your stack is a few services plus a database, TDK CLI runs it locally and ships an MCP server (tdk mcp). It exposes doctor, up, down, status, logs, and resource_list, so the agent can start the stack and read its readiness instead of guessing. The agent tooling guide has the setup for Codex and Claude Code.
Two details that helped me: up returns before the stack is ready, so poll status until readiness is true. And doctor --json tells the agent whether the host can run the stack at all, so it stops and explains instead of retrying.
For context on generated files and drift checks, see what TDK writes. Example projects you can clone: ERP, e-commerce, and auth, queue and email.
cool!