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 (3)
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.