What MCP Changed — On Giving an AI "Hands"

From an AI that only reads to one that reaches into your environment—what the MCPs we actually connect changed about how we build

For a while, building with an AI meant copy-pasting source code in and pasting what came back out—by hand. The AI read text and returned text; it couldn't lay a finger on the real environment. So we had to investigate the current state ourselves and feed it in, and the answers always rested on a guess: "this is probably how things look."

What broke through that wall was MCP. MCP (Model Context Protocol) is, in a word, a common "socket" that lets an AI reach out and touch external tools and environments. Connect a compatible tool to that socket and the AI stops merely returning text—it can query a database, drive a browser, go look at the state of a deployment. Here's what changed, traced plainly, naming a few of the ones we actually connect.

Chapter 1 — Checking the present, directly

The first thing it helped with was grasping the current state.

Supabase MCP — querying the database's live state. Until then, the only way to know how a table currently looked was to trace the 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 latest shape—if anything, the more you read, the less clear "so how does it actually look right now?" becomes. Supabase's MCP flips that: instead of assembling the present from history, you query the live definitions and data directly. As guesses get replaced by facts, the rework born of false assumptions drops away.

Context7 MCP — a library's up-to-date docs. An AI's knowledge stops at the moment it was trained, so it can hand you plausible-looking code written in an old, since-changed style. Connect Context7 and it pulls the official docs for the library you're using, current, on the spot. Building on "the correct way today" instead of "the old API the AI remembers" spared us the detour of writing something, then rewriting it once we realized 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's always a gap between "it probably works" and "it works." A few MCPs let us step across it.

Playwright (browser) MCP — operating the real thing. The AI itself spins up a browser and actually walks a login and a full flow. Code that compiles can still fail to transition right after login on a real machine—a runtime mismatch you'll never see by reading the text. You only find it by touching it.

GitHub MCP — operating the repository. PRs, issues, cross-repo code search—the AI handles them 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 — checking the deployment. "We shipped it" is the tricky part: from status and logs you can confirm directly whether the right thing actually reached production and whether it's throwing errors. It turns "it should be live" into "I watched it go live."

Chapter 3 — To be able to touch is to be able to break

So much for the upside. There's something to put down honestly.

Here's one we actually 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 an AI that only reads could never cause. Convenience and danger pour from the same tap. We learned it the hard way.

That's 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: 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.

And before we knew it, we weren't just connecting off-the-shelf MCPs—we'd started building our own, to operate our own product. The further in you go, the more you can do, and by exactly 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 born of guesswork falls away. At the same time, because it can touch things, accidents can happen—so the reins, meaning the line between read and write and the operational procedure, stay in human hands. More can be delegated, but never abandoned. 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.

The micro-SaaS we keep building this way, by feel, is PentaTrail—a CTEM service that uses AI to continuously grasp your externally visible attack surface. If you're curious, take a look at your own company's "externally visible attack surface."

See PentaTrail / CTEM