How I Move Faster With Claude Code and a Custom MCP

Earlier this year I started WorkHoodie, building apps for myself and helping clients ship theirs. Claude Code became my default development partner for both.

I thought I was pair programming with it. I was actually just doing its QA.

Every time it made a change, it would tell me it was done. And it wasn’t. Not maliciously. It just had no way to check its own work. It couldn’t see the app or read the browser console or look at the server logs. So it would confidently declare victory, and I’d go verify, find the issue, describe what I was seeing, paste in the error, and send it back. Then it would fix that and we’d do the whole thing again.

That’s not pair programming. That’s me sitting next to a fast developer who can’t test their own code. The iteration loop was slower and less accurate because everything had to pass through me first, and I’m a lossy middleman between an app and a terminal.

Where I Was Losing Time

The app I was building had three places things could break: the server logs, the browser console, and the visual state of the UI. None of them live in the terminal where Claude Code does.

The pattern was always the same. Claude Code would make a change, tell me it was done, and I’d go check. Half the time it wasn’t done. I’d find the issue, describe what I was seeing, paste in the error. It would fix that, tell me it was done again. I’d go check again. Every round trip added time and lost fidelity. My description of a bug was never as good as the actual stack trace. My “the layout looks off” was never as useful as a screenshot.

The obvious response is “just write tests.” Claude Code can run tests. But tests verify known expectations. They tell you the function returns the right value or the API responds with a 200. They don’t tell you the hero image is overlapping the nav on mobile, or that a console error is firing on every page load, or that the layout just feels off in a way you’d catch in two seconds of actually looking at it. Tests cover what you already know to check for. The gap is everything else.

The Fix: A Custom MCP Server

MCP lets you give Claude Code custom tools it can call on its own. So I built a small MCP server that gives it eyes and ears into my local dev environment. Enough for it to check its own work before coming to me. Five TypeScript files, nothing fancy:

tools/dev-server-mcp/
├── index.ts            # MCP server + tool definitions
├── server-manager.ts   # start, stop, logs
├── screenshot.ts       # screenshots + visual diff
├── perf.ts             # Core Web Vitals
└── types.ts            # shared types

Claude Code discovers it from a .mcp.json file in the project root:

{
  "mcpServers": {
    "engage-dev-server": {
      "type": "stdio",
      "command": "npx",
      "args": ["tsx", "tools/dev-server-mcp/index.ts"]
    }
  }
}

If Claude Code can see the app, read the logs, and take screenshots, it can do its own QA. The whole iteration loop gets faster and more accurate because the machine is reading its own stack traces instead of my descriptions of them.

It can start and stop the dev server, read server logs, take screenshots across device viewports, capture browser console output, run visual diffs against a baseline, and measure Core Web Vitals. Everything I’d normally check by hand.

What Actually Changed

The first time Claude Code started the server, took a screenshot, noticed a layout issue, fixed it, took another screenshot, and confirmed the fix without me touching anything, I just sat there. The whole loop ran without me.

Before, I was the bottleneck in that iteration loop. Checking the browser, reading logs, describing errors. That work matters, but I was adding latency and losing fidelity every time I relayed what I was seeing. The MCP gives Claude Code direct access to the signal, so the loop runs faster and catches more.

And because the loop is tighter, I have time I didn’t before. The questions I’m asking changed. Whether the thing we’re building actually solves the problem we scoped. Whether I should redirect before Claude goes three rounds deep on the wrong approach. I wasn’t getting to that stuff when I was busy relaying screenshots.

Build Your Own

Start with whatever feedback loop costs you the most time. Mine was “make change, check browser, describe result.” Yours might be checking test output or verifying API responses or looking at database state.

Paste this prompt into Claude Code from your project root and it will inspect your setup and build a custom MCP server tailored to your stack.