Symfony Profiler Mcp Laravel Package

Product Decisions This Supports

First, a scoping correction that is itself a product decision: this is a Symfony bundle, not a Laravel package. It depends on symfony/mcp-bundle and reads the Symfony Web Profiler. If our stack is Laravel, we cannot adopt it directly — Laravel has no Symfony profiler, it has Telescope/Debugbar. So the decisions this actually informs are:

• Developer-experience (DX) investment — the primary one. The package collapses a routine but high-friction loop: reproduce → open web profiler → click through panels → copy queries/exceptions/logs → paste into an AI assistant. It exposes profiled requests, timelines, memory, Doctrine queries, logs, and exceptions directly to an MCP client. The decision it supports is whether our diagnosis/onboarding loop is expensive enough to justify tooling spend, and it gives us a concrete benchmark to price that spend against.
• Build vs. buy vs. clone for a Laravel equivalent. For a Laravel shop, this is a reference implementation, not a dependency. It is a small, MIT-licensed, working example of "profiler data → MCP server," built on the same protocol our AI IDEs already speak. The realistic decision: do we build a thin Telescope-backed MCP bridge in-house (likely a few hundred lines against symfony/mcp-bundle's pattern) rather than adopt a fourth-party Symfony artifact into a Laravel repo?
• AI-assisted engineering standards. Which MCP servers are sanctioned for the team? This is an early data point in a governance decision — local-only developer tooling versus a curated MCP registry owned by platform engineering.
• Roadmap: internal tooling versus customer-facing features. This belongs in the DX/platform bucket, adjacent to, not inside, the product differentiator. It should never appear on a customer-facing roadmap.
• Use cases worth a spike: onboarding an engineer into an unfamiliar Symfony service; performance triage (N+1 queries, memory, timing outliers) on staging; post-incident forensics from captured requests; support triage against a staging repro.
• Explicitly not supported: anything needing a vendor SLA, a support contract, or a compatibility guarantee. At 4 stars, a single recent release, and empty release notes, this is evaluation-grade only.

When to Consider This Package

Consider it when:

• The stack is Symfony 6/7 on PHP 8.x — this is not usable in a Laravel application without a rewrite of the profiler-facing half.
• The team already has an MCP-capable client (AI IDE or assistant) as part of its normal workflow; without one, the bundle has no consumer.
• You are already on or willing to add symfony/mcp-bundle — this package is a thin layer on top, not a standalone platform.
• The use is confined to local development and staging. Profiler payloads contain SQL, request parameters, environment values, and log lines; an MCP server fronting them must not be reachable off-host or from production.
• You want a precedent to copy rather than a component to depend on — MIT license means forking or reimplementing the pattern is legally clean.
• You can accept churn: pre-1.0, no changelog, no migration guidance, no published compatibility statement.

Look elsewhere when:

• You are a Laravel shop. Use Telescope/Debugbar today and, if the workflow proves out, build the MCP adapter yourself. Adopting this would introduce Symfony framework packages into a Laravel codebase for a developer-only convenience — a bad trade on dependency surface alone.
• You need a support commitment, security-response process, or version policy. None is evidenced. Escalation is a public issue tracker with four stars of attention behind it.
• Exposing profiler data is a compliance problem. Query text, request bodies, and logs routinely carry PII and secrets. In a regulated context this is a gating question, not a footnote.
• The capability is core to how your team differentiates. Own it in-house behind an internal adapter.
• You cannot pin an exact version and review each bump. ^0.x is not a safety net; 0.x minors are permitted to break.

How to Pitch It (Stakeholders)

For executives: This is a developer-productivity tool, not a product dependency. It lets an AI coding assistant read Symfony's profiler directly — query timings, memory, logs, exceptions — instead of an engineer manually copying that data out of a browser panel. The strategic value is not the package; it is that it is a working, MIT-licensed template for a capability our own stack would need to build. My recommendation: no adoption decision and no budget request. Fund a short, timeboxed spike — one engineer, a few days — that either (a) validates the workflow on a Symfony service if we have one, or (b) uses it as a spec to estimate building the Laravel equivalent. The deliverable is a cost estimate and a go/no-go, not a deployment. Two caveats to record: the project is very early (single release, tiny community, no release notes), and profiler data is sensitive, so this stays local-only and out of production. Note also that as published it targets Symfony, not Laravel — so for a Laravel codebase, the honest framing is "buy the idea, build the adapter."

For engineering: Treat this as a reference architecture with a runnable prototype attached, not a dependency to add to a product repo. Three asks before any time is spent:

1. Confirm the stack fit. Read composer.json — Symfony and PHP constraints, the symfony/mcp-bundle requirement, transitive weight. If we are Laravel, stop here and read the source as a design document instead; the useful artifact is the shape of the MCP tool surface (list requests → inspect timeline → fetch queries/logs/exceptions), not the code.
2. Answer the security question first. What exactly does it expose, over what transport, bound to which interface? Profiler data includes SQL, request payloads, and environment values. If it listens beyond localhost or can be enabled in production, that is a blocker, not a config tweak.
3. Measure, don't assert. Pick one concrete diagnostic task — "find why this endpoint is slow" — and time it with and without the tool. A DX tool that cannot show a before/after delta on one task does not earn a slot in the stack.

If it passes: pin the exact version, keep it in require-dev, wrap every call behind a thin internal adapter so a breaking change is a one-file edit, and set a review at the next framework major. If the answer to "what does it cost to rip out?" is more than a sprint, we do not adopt — we build our own against the pattern.