What MCP Changed: Giving an AI Hands

For a long time, building with an AI meant manual work: copy the source code in, paste back whatever it returned.

The AI read text and returned text; it couldn't touch the real environment. So we had to look up the current state ourselves and feed it in, and the answers it gave always rested on a guess: "this is probably how things look."

What broke that wall down was MCP. MCP (Model Context Protocol) is, in a word, a shared interface that lets an AI operate external tools and environments. Connect a compatible tool to it and the AI can do more than return text. It can query a database, drive a browser, go look at the state of a deployment. Here is what changed, with a few of the ones we actually connect.

Chapter 1: Checking the present, directly

The first thing that helped was grasping the current state.

Supabase MCP lets you query the database's definitions and data directly. Until then, the only way to know how a table looked was to trace its change history, the pile of accumulated diffs, from the top. But a diff records what was done in the past, not how things are now. Those diffs now run past a thousand; read them in order and you still can't reconstruct the current shape. If anything, the more you read, the less clear "so how does it actually look right now?" becomes. Supabase's MCP flips that around: instead of assembling the present from history, you check the current state directly. As guesses get replaced by facts, the rework that comes from false assumptions drops off.

Context7 MCP lets you pull the official docs for a library you're using, current, on the spot. An AI's knowledge stops at the moment it was trained, so it can hand you plausible-looking code written in an old style that has since changed. With Context7 you can build on the correct way to write it today, which cut out the detour of writing something and then rewriting it once we noticed the approach was already deprecated.

Chapter 2: Running it on a real machine

The next thing to change was how we verify.

Reading the code alone won't tell you whether a screen actually works, or whether the right thing shipped to production. There is always a gap between "it probably works" and "it works." A few MCPs let us cross it.

Playwright (browser) MCP has the AI spin up a browser itself and walk a real login and the flow that follows. Code that compiles can still fail to transition right after login on a real machine. You never see that kind of runtime mismatch by reading the text; you only find it by touching it.

GitHub MCP lets the AI handle PRs, issues, and cross-repo code search itself, so making a change, reviewing it, and tracing it become one continuous motion. We also run two-track review, pitting a separate AI lineage against the work, on top of this foundation (a long story of its own, for a later post).

Vercel MCP lets you confirm, from status and logs, whether the right thing actually reached production and whether it's throwing errors. "We shipped it" is the tricky part, and this turns "it should be live" into "I watched it go live."

Chapter 3: To touch is to be able to break

That's the upside. It wasn't all upside.

Here is one we got wrong. Meaning only to rebuild a preview environment, we handed the redeploy to the AI, and it swallowed production's canonical publish target along with it. Production went sideways for a while, and on top of that the development environment started reading production's settings and broke too. A double accident that an AI which only reads could never cause. Convenience and danger come out of the same tap. We learned that the hard way.

That is exactly why the line between what can be read and what can be written becomes the lifeline. Guards that forbid writes don't come attached automatically, so you bind them with procedure. For example, we decide that queries against the production database are read-only and enforce it in practice. Secrets, tokens and keys, aren't handed to the AI; they stay outside the environment.

Before we knew it, we weren't just connecting off-the-shelf MCPs. We had started building our own, to operate our own product. The further in you go, the more you can do, and by the same measure, the more there is to be careful about.

Give it hands, but keep the reins

What MCP brought was the AI's shift from something that reads and answers to something that reaches into the environment. It checks the present directly, watches behavior on a real machine, and the rework that came from guesswork falls away. At the same time, because it can touch things, accidents can happen. So the reins, the line between read and write and the operational procedure, stay in human hands. More can be delegated, but never handed off completely. That, roughly, is where the line we learned this year came to rest.

How we rebuilt this whole stack over a year is in How a Micro-SaaS Tech Stack Changed in a Single Year. Other posts on how we build are gathered in the dev category.

This is what we keep building, feeling our way as we go: PentaTrail, a CTEM service that uses AI to continuously keep track of your company's externally visible attack surface.

See PentaTrail / CTEM