Symfony Profiler Mcp Laravel Package

Getting Started

Read the audience-mismatch first. Despite the general-purpose Laravel-flavored assessments floating around this package, productowner-ro/symfony-profiler-mcp is a Symfony bundle. It reads Symfony's Profiler data and exposes it over the Model Context Protocol. Laravel has no Profiler — its analogue is Laravel Telescope (plus barryvdh/laravel-debugbar for the toolbar). Consequences:

• On a pure Laravel codebase this package is not installable/useful — there is no Profiler store for it to read.
• On Symfony projects (including a Symfony service inside a PHP monorepo) it drops in with normal Symfony Flex conventions.
• For a Laravel developer the practical value today is the pattern, not the runtime: it's a working reference for exposing debug data to AI IDEs via MCP — which you can replicate over Telescope with laravel/mcp or a hand-rolled MCP server.

Minimal steps (Symfony context):

1. composer require productowner-ro/symfony-profiler-mcp inside a Symfony app.
2. Confirm the bundle is registered in config/bundles.php (Flex usually handles this).
3. Ensure symfony/profiler-pack is enabled in dev — there must be profiled requests for the bundle to serve.
4. Find the MCP entry point: run bin/console list | grep -i mcp. The README doesn't pin the command name at v0.1.0, so discover it from console rather than trusting docs.
5. Point your MCP client at that console command, scoped to the project directory. Claude Desktop (claude_desktop_config.json), Cursor (.cursor/mcp.json), and Windsurf all support this pattern.
6. Ask the assistant to "list the last five profiled requests, then dump the Doctrine queries for the slowest one."

Where to look first. Two files matter more than the README: the MCP tool definitions registered by the bundle (typically under Resources/config/ or an attribute-discovered tool class), and symfony/mcp-bundle's docs for the client handshake. The v0.1.0 changelog is empty — treat source as the spec.

First use case. Reproduce a slow Symfony endpoint, then have your AI IDE inspect the most recent profiled request and identify duplicated Doctrine queries. That single loop — repro → ask AI → read profiler via MCP — is the entire value proposition.

Implementation Patterns

The AI-debugging loop. The canonical workflow: (a) hit an endpoint to trigger a profiler entry, (b) in your AI IDE ask the MCP client to fetch profiled requests, (c) drill into performance timeline / Doctrine queries / logs / exceptions for the specific request, (d) iterate on code, (e) re-run. This removes the manual back-and-forth of keeping a browser tab on /_profiler open. It's most valuable for exceptions and N+1 query hunts, where the assistant can pattern-match across many queries quickly.

Anchor on request identifiers. The most reliable prompt pattern is "the request to /api/orders at 14:32" rather than "the last request." Profiler entries are ordered and often there are concurrent requests (assets, sub-requests, AJAX). Pin to route + time window, or copy the profiler token from /_profiler and hand it in.

Filter, then drill. Treat the MCP tools as two layers: (1) list/filter requests by URL/status/date, (2) fetch detailed data for one token. If you ask one question that tries to do both, you'll exhaust the model's context with unrelated requests. Split it.

Cross-reference with code, not just data. After the assistant surfaces a slow query, follow with "open the repository method that builds this query." The MCP server only sees profiler data — it won't link back to your source. Keep both tools in play.

Wrap behind an adapter if you adopt. If you're integrating this into a team-wide workflow (CI scripts, internal tooling), wrap calls behind a small interface so the bundle's tool name/schema changes at a 0.x bump are isolated to one place. The bundle is at v0.1.0 with no changelog; API churn is guaranteed, not exceptional.

Laravel-translated pattern. If your goal is Laravel AI-assisted debugging, mirror this architecture: MCP server → Telescope entry store → tool calls like telescope.requests.list, telescope.queries.for_request, telescope.logs.for_request. Telescope's data model maps almost 1:1 to the Symfony Profiler's panes, so the design transfers cleanly. Budget a day or two of work — that's your realistic alternative if you can't wait for a stable Laravel-native equivalent.

Pair with fixtures/tests. During development, have the AI assistant compare two profiled runs (before/after a change) instead of one. That's where the memory/timing deltas actually show regressions.

Gotchas and Tips

• It will not install usefully in Laravel. If you tried composer require on a Laravel app, the service provider would register but every tool would return empty data — there is no Profiler. Don't mistake the empty-changelog, generic-PHP-assessment noise for "Laravel-compatible."
• Dev-only by design. The Symfony Profiler doesn't collect in prod. Anything you test here must be exercised against a dev (or profiler-enabled) environment. Don't expect staging-prod parity.
• Profiler data expires. Symfony prunes profiler entries on a configurable schedule (and can be wiped by cache:clear). If you ask the assistant about "yesterday's request," the data is likely gone unless you raised framework.profiler.collect retention or exported entries first.
• Token budget blows up fast. Large requests — dozens of Doctrine queries with bound parameters, big log payloads — can saturate an MCP client's context window. Configure the client to allow chunked follow-ups, or ask for summaries first ("count the queries, list the five slowest") rather than full dumps.
• Sensitive data in profiler logs is now in your AI client. Exception stack traces, log lines, and query parameters flow to whichever MCP client you connect. Treat the MCP client as a third-party recipient of your dev environment data; don't wire it up against environments with real customer data, and audit what your log handlers write.
• No stable API. v0.1.0, 4 stars, empty release notes, no documented support policy. Pin to productowner-ro/symfony-profiler-mcp:0.1.0 exactly — ^0.1 permits 0.2.0, which under semver-for-0.x is allowed to break. Record the resolved versions in your lockfile.
• MCP client path pitfalls. Most MCP clients launch the server as a subprocess with a working directory you must set explicitly. If the console command is bin/console mcp:serve (verify locally), the client config needs the absolute path to that file and a cwd pointing at the Symfony root — otherwise kernel boot fails and the tool silently returns nothing.
• symfony/mcp-bundle is the real dependency. Most extension points, tool registration, and transport behavior are defined there, not in this package. When debugging MCP-level issues (handshake failures, tool schema errors), read symfony/mcp-bundle source first.
• Extension point for custom panes. If your Symfony app has a custom Profiler collector, the natural addition is a matching MCP tool exposed from this bundle's namespace. That's the intended way to extend it day-to-day — but it's also the surface most likely to shift in 0.x.
• Debugging the server itself. When the assistant reports "no data," check in this order: (1) profiler data exists in /_profiler for the requested token, (2) the MCP subprocess can boot the kernel (test manually), (3) your client's tool list includes the profiler tools, (4) the request is in dev. Skipping step 1 wastes the most time — assistants tend to hallucinate "no requests found" when the tool call actually errored.