JIMDRURY.
Jim Drury
Flat blue editorial illustration: a crossed-out pile of pasted stack traces labelled human clipboard (retired), beside a next dev localhost:3000 terminal answering /_next/mcp queries (routes, last error slot @modal, next 16.2.0) from an agent calling get_routes, get_errors and get_page.
agents

Stop pasting stack traces. Let the agent see the running app.

4 MIN READ

There's a special kind of despair reserved for copying a red Next.js overlay into chat, watching the agent invent a fix for Next 14, then realising you're on 16.2 and the docs in its head are fan fiction.

I dont want to be a human clipboard anymore. (Alright, I dont want that. The agent can keep dreaming.)

Next.js DevTools MCP (and the /_next/mcp endpoint in 16+) finally lets the agent ground itself in the running app instead of my paste buffer.

What changes when the app can talk back

With next-devtools-mcp wired into your agent config, the coding agent can ask the live dev server questions humans normally answer by squinting:

  • What routes exist right now?

  • What was the last compile error?

  • What is on the current page?

  • Which version of Next is actually installed?

That last one alone is worth the setup. Training data is sticky. Runtime truth isnt.

.mcp.json (shape, not gospel)
{
  "mcpServers": {
    "next-devtools": {
      "command": "npx",
      "args": ["-y", "next-devtools-mcp"]
    }
  }
}

Boot next dev. Let the MCP server discover the instance. Suddenly the agent is debugging this app, not a composite memory of every app it's ever seen on the internet.

Paste culture vs grounded culture

Old loop: break the app → copy the overlay → soften the language so the model doesnt panic → receive a patch for the wrong major version → argue with screenshots.

New loop: break the app → ask the agent to inspect live errors / routes / logs via DevTools MCP → patch against what the server reported → verify on the same running instance.

You still need elegance, or at least patterns that fit the use case. You still need tests. But you stop being the lossy transport layer between localhost:3000 and the model. My wrists thank me.

Pair it with the browser, not instead of it

DevTools MCP tells the agent what Next thinks is wrong. A browser tool tells it what a human would see.

I use both. DevTools for compile errors, route maps, framework diagnostics, version-accurate docs under node_modules/next/dist/docs/. Browser for click paths, layout bugs, and "the API route returned 200 but the UI is empty".

Framework truth plus rendered truth. That's the grounding stack, and yes I know that sounds like a slide title. Still true.

A concrete afternoon

I had an App Router page that rendered fine in isolation and exploded only when a parallel route mismatched a slot name. The overlay was noisy. My paste was incomplete. The agent kept "fixing" the wrong file.

Once it could query the running routes and the actual error channel from the dev server, it stopped theorising about useEffect and fixed the slot. Five minutes. No heroic prompting.

That isnt magic. That's sensors.

Caveats

This is a development affordance. Dont expose /_next/mcp to the public internet and call it innovation. Keep it on local/dev instances. Treat it like React DevTools: powerful, local, not a product surface.

Also: grounded agents can still make bad product decisions. Seeing the error doesnt grant elegance (or good patterns). It just stops them lying about which error they saw.

Thoughts

The best debugging prompt of 2026 isnt a better paragraph. It's an agent that can look at the running app without you playing middleman.

Similar Articles