Debug a Next.js app with Claude, Cursor and MCP

Updated 28 October 2026 · 4 min read

AI coding assistants are good at reading code, but they cannot see what your app actually did at runtime. The qaisdebugs MCP server gives them that: the real requests, logs, errors and a debugger.

Set it up

npm install -g qaisdebugs
claude mcp add qaisdebugs -- qaisdebugs mcp

For Cursor, Windsurf and other MCP clients, add the same command to their MCP settings, for example Cursor's mcp.json:

{
  "mcpServers": {
    "qaisdebugs": { "command": "qaisdebugs", "args": ["mcp"] }
  }
}

Then start your app with qaisdebugs dev as usual.

What to ask

"Clear qaisdebugs and wait while I reproduce the bug on the tasks page, then find out what went wrong."
"Why does /api/orders return 500?"
"Set a breakpoint in app/shop/page.tsx line 18 and tell me what searchParams is when I load /shop?category=shoes."

A real example

A team tasks card showed "No tasks found" for every person. Asked to investigate, the assistant used list_problems and get_trace and saw that the page called /api/tasks?userId=2, but the server then called the tasks API with userId=null, from line 13 of route.ts. Reading the file showed the handler read the query parameter user instead of userId. One look at both halves of the request found a bug that threw no error at all.

The tools it gets

Tools	What they do
`status`, `clear`, `wait_for`	See what is running, start clean, wait while you reproduce the bug
`list_requests`, `get_request`, `get_trace`	Browser and server requests with headers, bodies, timing and the line that made them
`list_logs`, `list_problems`	Server and browser logs; failed requests, errors and warnings
`find_files`, `read_file`	The app's source
`set_breakpoint`, `wait_for_pause`, `evaluate`, `step`	Pause server or client code and read the variables

Privacy

Everything stays on your machine. The MCP server reads from the local inspector, which masks passwords, tokens, API keys and cookies before it stores anything.