Mcp Profiler Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, and the framing needs correcting first. This is a Symfony bundle, not a Laravel package. The repository name says it: mcp-profiler-bundle. It registers into Symfony's DI compilation pipeline, listens on kernel events, and reads from the profiler service backed by FileProfilerStorage. Laravel has no equivalent hook point — it has its own container, its own lifecycle, and its own observability surface (Telescope, Pulse, Debugbar, Clockwork). There is no ServiceProvider, no publishable config, no facade. A Laravel team cannot composer require this and get anything.

What is actually reusable is the idea, not the artifact. The valuable part is the MCP tool schema design: how request/query/timing data is shaped into JSON-RPC tool responses an agent can consume without blowing its context window. That design is framework-agnostic and can be reimplemented over Telescope's entries table in a few days. The Symfony-specific adapter layer is the part that does not port.

Deprecation is no longer a risk — it is a settled fact. Release 0.2.1 is explicitly titled "Final release: this bundle is deprecated." There is no ambiguity left to investigate: no further updates are planned, the README points at Symfony AI Mate, and the remaining changes are a PHP 8.4 nullable-type fix (#13) and CI housekeeping (#14). The prior open question — "is the September release a deprecation marker or real maintenance?" — is answered: deprecation marker. The maintenance window is closed at 0.2.1. That converts this from "adopt with caution" to "do not adopt; migrate off if already present."

The successor is now concrete, which materially improves the decision. Before, Symfony AI Mate was a name to investigate; the release notes give an actual migration: symfony/ai-mate plus symfony/ai-symfony-mate-extension and symfony/ai-monolog-mate-extension, initialised with vendor/bin/mate init and populated via vendor/bin/mate discover. That is an extension-based architecture — Mate is the host, extensions contribute capabilities, and discover wires them in. The prior "one-day spike to see if Mate's MCP layer points at a custom data source" question is now answerable from documentation rather than guesswork. It also means the pattern this bundle pioneered (agent-facing profiler tooling) has been legitimised upstream. The right move for anyone on Symfony is to follow the documented removal steps: composer remove killerwolf/mcp-profiler-bundle, delete the line from config/bundles.php, delete the mcp:server:run entry from the MCP client config, and stand up Mate.

Security surface deserves explicit callout, and deprecation makes it worse. Profiler data is not innocuous. It contains request bodies, headers (including bearer tokens and cookies), session payloads, and SQL statements with bound parameters. An MCP server exposing that to an AI agent means that data can flow into a third-party model provider's context. In a dev-only, single-developer container this is acceptable. In any shared staging environment, preview environment, or CI runner with real credentials, it is a data exfiltration path. Critically, a deprecated package receives no security patches — if a header-redaction or transport-auth weakness is found, it will not be fixed here. Any residual use needs a hard guarantee that the server only ever starts in local development.

Key questions before any decision:

• Is there Symfony anywhere in the estate — a legacy service, a shared library, a polyglot monorepo — or is this purely a Laravel shop? If purely Laravel, stop here.
• If Symfony is in scope: has this bundle already been installed anywhere? The 0.2.1 notes give a clean removal recipe, so the question is inventory and cleanup, not evaluation.
• Does the Mate extension API support a custom data source for the Laravel case, or is a bespoke MCP server still required? Worth a short read of the Mate docs; the extension model suggests reuse is plausible even outside Symfony's profiler.
• What is the actual user need? If it is "let Claude Code see why this request was slow," Laravel Telescope plus a thin MCP wrapper solves it natively and stays on a maintained dependency.
• Who owns the decision to standardise on Symfony AI / Mate tooling across the estate, if anyone?

Integration Approach

Stack fit: no, unless there is a Symfony foothold. For a Laravel codebase the honest answer is that this package is a reference implementation, not a dependency. Adding it would mean shipping a Symfony bundle into a Laravel app that never boots it — pure dead weight and a supply-chain surface for zero benefit. That was true at 0.2.0 and is more true at 0.2.1, where the package declares itself terminal.

Migration path if a Symfony service does exist — this is now a documented, low-risk path, so execute it rather than plan it. Treat 0.2.1 as an exit release:

1. composer require --dev symfony/ai-mate and run vendor/bin/mate init.
2. Add the relevant extensions — symfony/ai-symfony-mate-extension, symfony/ai-monolog-mate-extension — and run vendor/bin/mate discover.
3. composer remove killerwolf/mcp-profiler-bundle.
4. Delete its line from config/bundles.php.
5. Delete the mcp:server:run entry from the MCP client config.
6. Confirm the Agent Skills Mate installs cover the workflows the old bundle served; if a gap exists, that is an extension request upstream, not a reason to keep the bundle.

This is an afternoon, not a project. Do not let the old bundle into a shared library or an internal starter template, because that is how deprecated dev dependencies become permanent. Audit for that now — a stale require-dev in a template will outlive everyone's memory of this decision.

If the goal is Laravel-native capability, sequence it as a port, not an integration:

1. Spike (1–2 days). Stand up an MCP server over Laravel Telescope's storage. Define three tools mirroring the bundle's surface: recent requests with timings, slow queries, and per-request query breakdown.
2. Schema reuse. Copy the tool naming, argument shapes, and response envelope conventions from this bundle — that is the genuinely hard part and it is free to read. Mate's Agent Skills descriptions are also worth reading as prior art for how to phrase tools so an agent picks them correctly.
3. Transport decision. stdio for per-developer local use is simplest and sidesteps auth entirely. HTTP transport requires authentication and network scoping and should be avoided for a v1.
4. Guardrails. Environment gate (APP_ENV=local only), payload truncation, and redaction of Authorization and cookie headers before anything reaches a model.
5. Rollout. One team, one repo, two weeks of dogfooding, then decide.

Compatibility watch items: with the Symfony path now on Mate, PHP floor and Symfony version support track Mate's requirements, not this bundle's. The PHP 8.4 fix in 0.2.1 (#13) is the last compatibility work anyone will do here — after PHP 8.5 or the next Symfony minor, this bundle is on its own. For the Laravel port, the watch items remain MCP client transport support, MCP spec drift, and Telescope schema stability.

Operational Impact

Maintenance: zero, by declaration. 0.2.1 is the final release; the author states no further updates are planned. There is no scenario where "we'll just use the upstream and patch it if something breaks" is defensible — there will be no upstream. If the bundle is embedded anywhere it cannot be quickly removed from, that is a finding to remediate now, not a risk to track.

Support: none, and the successor has a real one. No vendor, no SLA, no security advisory channel for this bundle. The material improvement in 0.2.1 is that support now exists one hop away: Symfony AI Mate is part of the official Symfony AI project, with docs, an extension ecosystem, and an organisation behind it. That is the single biggest change in the operational picture — the capability survives the package, which is not true of most deprecations. It also means the governance concern (an MCP server that reads request payloads needs a CVE response process) is now answerable: inherit Mate's, not this package's.

Scaling: largely a non-issue, which is itself informative. The server runs per-developer over stdio, so there is no shared service to scale. The real scaling concern is profiler storage growth — file-based profiler directories accumulate until something prunes them — and agent context consumption, where a naive "give me all queries for this request" tool will return more tokens than the model can usefully reason over. Truncation and pagination in the tool schema are the actual scaling work, and they carry over unchanged to Mate and to any Laravel port.

Failure modes to plan for:

• Removal step skipped. The mcp:server:run entry lingering in an MCP client config produces connection failures against a package that is no longer installed — an easy-to-misdiagnose "the agent is broken" report. The migration checklist is the mitigation; follow it literally.
• Stale template dependency. The bundle surviving in an internal starter repo or shared dev image reintroduces it into every new project after everyone has forgotten the deprecation.
• Profiler disabled or storage empty → tools return nothing and the agent confidently reports "no slow queries," which is worse than an error. Tools must distinguish empty from unavailable.
• Profiler index staleness or token mismatch after a request is purged → intermittent, hard-to-reproduce agent confusion.
• Secret leakage: auth headers and request bodies flowing into a model provider's logs, with no patch path.
• MCP spec drift → client stops negotiating with the old server after a Claude Code or Cursor update; Mate tracks the spec, this does not.

Ramp-up: near-zero for a Symfony developer, negative for a Laravel team. On Symfony the install is require-dev plus an MCP client config block, and the exit is five documented commands — an hour. On Laravel the ramp-up is not the install, it is the realisation that the tool does not apply, followed by the port. Budget the port at a few days of one engineer's time, not a sprint. Factor in a short read of Mate's extension docs, which may shorten the port if the extension model is adaptable.

Recommendation. Do not take this as a dependency, and treat 0.2.1 as a removal release rather than an upgrade. The score of 19.98 is consistent with what the repository now says about itself in its own title. Use it as a read-only design reference for MCP tool schemas over profiler data; migrate any Symfony installation to Symfony AI Mate using the documented steps; and for a Laravel stack build the equivalent over Telescope — where you keep the maintenance, the security posture, and the framework fit in one place. The opportunity score of 37.42 still reads as "the problem is real, this artifact is not the answer" — but the arrival of a maintained, officially-backed successor is the strongest argument yet that the problem is worth solving, just not with this package.