- Is milton/vibedebug-bundle a Laravel package I can install with Composer?
- No. It is a Symfony bundle that depends on the Symfony kernel, dependency injection compilation, config/bundles.php registration, the event dispatcher, and the Symfony Profiler subsystem, none of which exist in a Laravel application. Installing it as a Laravel dependency is not feasible today. Its only Laravel-relevant surface is that a Laravel process could act as an MCP client consuming the bundle's profiler tools from a separate Symfony host.
- Which Laravel versions does milton/vibedebug-bundle support?
- It does not declare Laravel support at all, because it is a Symfony bundle rather than a Laravel package. Compatibility is defined by Symfony and by the symfony/ai components the MCP tools are built against. If you are evaluating it for a Laravel estate, treat it as an external service integration and validate the Symfony side's requirements instead of looking for a Laravel version constraint.
- How do I install and register this bundle in a Symfony application?
- Install it with Composer in the Symfony service, then register the bundle in config/bundles.php and apply the provider configuration it exposes. You also need the Symfony Profiler enabled with profile retention configured so that profiler tokens resolve to real profiles. The incremental setup cost for 0.3.0 is low, but provider setup and data-egress review remain the main effort.
- What do the vibedebug_profiler_summary and vibedebug_profiler_export_collectors MCP tools do?
- They expose Symfony Profiler data as MCP tools that external agents can call through an MCP endpoint or Symfony AI Mate, and internal agents can call through symfony/ai-agent. The summary tool returns a profiler overview, while the export tool exports selected collectors data such as request and response headers, session data, SQL queries with parameters, dumped variables, and logged messages. That is a much richer payload than a stack trace, so treat it as sensitive production-adjacent data.
- Can a Laravel application consume VibeDebug profiler data over MCP?
- In principle yes, because MCP is transport-agnostic and a Laravel process can be an MCP client, but only if a Symfony service actually runs this bundle and its Profiler is populated. You would also need the MCP endpoint to be network-reachable from the Laravel consumer and to have authentication and authorization in place, which the release notes do not describe. In an all-Laravel estate the MCP tools have no data source and the package is effectively inert.
- Is it safe to expose the VibeDebug MCP profiler endpoint in production?
- Do not expose it unreviewed. The bundle is designed to be environment-aware and kept out of production, and the export tool can return session data, SQL parameters, headers, and dumped variables to any MCP client that can reach the endpoint. Profiler tokens are identifiers rather than credentials and can be guessable or enumerable in some configurations. Front it with your own authentication and authorization layer and restrict collectors until upstream proves access control.
- How do I prevent prompt-injection or confused-deputy issues with the profiler export tool?
- A model that can call export_collectors can be steered by attacker-controlled request data captured inside a profile into exporting collectors you did not intend. Treat broad data-fetch tools as an injection vector and replace the free-form collector selector with an explicit allowlist. Keep the MCP endpoint unreachable from untrusted networks and log every tool invocation for review.
- What are the best Laravel alternatives to VibeDebug for debugging and profiling?
- Laravel Telescope, Laravel Debugbar, Clockwork, Ray, and Xdebug cover request tracing, dumps, queries, and profiling inside a Laravel app without a Symfony host. If you specifically want AI-assisted inspection, look for Laravel-native MCP or tool-calling integrations rather than bridging to a Symfony bundle. The main advantage of staying native is that access control and data handling follow Laravel's existing conventions.
- How should I test and secure an integration with this package before adopting it?
- Test the MCP endpoint for authentication, authorization, token enumeration, and collector selection limits before pointing any agent at it. Verify that profiler retention is configured and that the endpoint is unreachable from untrusted networks, and confirm which collectors are exported by default. Because the bundle is pre-1.0 and built on unsettled symfony/ai abstractions, pin versions and re-review on every minor upgrade.
- How mature and well maintained is milton/vibedebug-bundle?
- It is early-stage: pre-1.0, low stars, zero dependents, a single maintainer, and no production evidence. Version 0.3.0 is a minor release on a pre-production package and deepens its dependency on symfony/ai, whose tool-calling API is still unsettled. Treat it as a reference implementation plus a narrow, security-sensitive MCP integration option rather than a dependable production dependency.