Laravel Nightwatch's MCP Server Now Diagnoses Performance Issues Too

Laravel Nightwatch, the framework's first-party application monitoring product at nightwatch.laravel.com, shipped an MCP (Model Context Protocol) server back in February 2026 that let AI coding assistants connect directly to a Nightwatch account — listing applications, browsing and triaging issues, viewing full stack traces, updating issue statuses, and adding comments, all without leaving an editor or terminal.

As of a May 26, 2026 update, that MCP server does a lot more than hand off stack traces. It now supports performance issues too. When an AI assistant retrieves a performance issue through the MCP server, it gets back precise timing data — route duration, database query times, and job execution metrics — instead of just a description of what's slow.

Why This Matters

Exception tracking via MCP was already useful: point Claude Code or Cursor at a Nightwatch issue and it has the stack trace in front of it instead of you pasting it in manually. But performance problems have always been a different kind of investigation. "This endpoint is slow" isn't a stack trace — it's a shape made up of query counts, query durations, middleware overhead, and job execution time, and until now an AI assistant had no structured way to see that shape. It could read your code, but it couldn't see what your code was actually doing in production.

With this update, the assistant pulls the real numbers: how long the route took end to end, how much of that was spent in the database, how many queries ran, and how long any related job execution took. That's the same data a developer would otherwise dig for by hand across an APM dashboard, cross-referencing route timings against a slow query log. Handing it to the assistant directly means it can point at the actual bottleneck — say, an N+1 query pattern adding 400ms to a route, or a job step that dominates execution time — rather than guessing from source code alone and proposing a plausible-looking but unverified fix.

What This Looks Like in Practice

The workflow this enables is straightforward: tell your AI assistant to fix the slowest endpoint in production this week, and let it do the legwork.

You: Using the Nightwatch MCP server, find the slowest performance
issue from the last 7 days on the phparchitect-api application and
fix it.

Assistant: [lists applications via MCP, finds phparchitect-api]
[browses performance issues, sorts by duration]
[retrieves the top issue: GET /api/articles/{id}/related]
[reads timing data: route took 890ms, 340ms of which was 42
individual queries against the `comments` table]

That's an N+1 — the related-articles query is loading each
article's comments individually. Adding ->with('comments') to the
base query in RelatedArticlesController should collapse that to a
single query.

Rather than a developer opening the Nightwatch dashboard, finding the issue, reading the timing breakdown, and translating that into a diagnosis, the assistant does the whole loop — retrieve, interpret, fix — because the timing data is now available through the same MCP connection it already uses for exceptions.

Also Worth Knowing

Alongside the original February 2026 MCP server launch, Nightwatch also added custom webhooks and a Linear integration — the ability to create and link Linear issues directly from Nightwatch, with Nightwatch applications mapped to specific Linear teams. Those are separate from the MCP server itself, but they round out the same theme: less time spent manually shuttling information between a monitoring dashboard and wherever the actual work happens, whether that's an editor, an AI assistant, or a project tracker.

The headline here, though, is the performance-issue support in the MCP server. Exception tracking got AI assistants looking at your errors. Real timing data gets them looking at your bottlenecks — with numbers to back up the fix instead of a best guess.