Laravel Laravel Package

Technical Evaluation

php-mcp/laravel is the Laravel integration layer for the Model Context Protocol (MCP), letting a Laravel application expose tools, resources, and prompts to MCP-speaking clients (AI IDEs, desktop assistants, agent runtimes). 4.0.0 is a major bump landing two changes: stateless mode for HTTP transports (PR #36) and Laravel 13 support (PR #48). The version number is the headline risk — a major bump on a two-PR changelog implies at least one change to public surface (transport/session contracts, config keys, or default transport behavior) that is not enumerated in the notes. Treat 4.0.0 as a breaking release until the upgrade guide and diff prove otherwise.

Architecture fit. Strong for teams already on Laravel. The package reuses the framework's routing, middleware, container, events, and auth, so an MCP surface becomes another delivery channel over existing domain services rather than a parallel app. Stateless mode is the architecturally significant addition: it removes the requirement for server-side session state per MCP connection, which is what previously forced sticky sessions or a shared session store behind a load balancer. That materially widens deployment topology options (multi-replica, autoscaled, and potentially serverless/FaaS HTTP runtimes) and is the main reason this release matters beyond version hygiene.

Integration feasibility. High. Composer install plus config publish plus route registration is the expected path; tool/resource definitions are ordinary PHP classes resolved from the container. Laravel 13 support means the package stays on the supported framework track and does not become the pin that blocks a platform upgrade. The real integration work is not mechanical — it is deciding which domain capabilities to expose, because every exposed tool is an authenticated-but-model-driven write path into the application.

Technical risk.

• Breaking-change uncertainty (highest). Changelog omits migration notes. Unknown whether stateless mode is opt-in via config or a changed default; whether session-bound features are now no-ops; whether transport interfaces, config keys, or published route definitions changed. Budget an audit of the 3.1.0→4.0.0 diff before committing.
• Stateless semantics gap. Stateless HTTP generally cannot support server-initiated or connection-scoped behavior: server→client notifications, progress reporting, resource subscriptions, sampling/elicitation round-trips, and multi-turn session context. If your tool handlers currently rely on session continuity or push updates, stateless mode silently degrades them. This must be validated per-tool, not globally.
• Protocol churn. MCP is a fast-moving spec. Transport and auth expectations (notably OAuth-based authorization for remote servers) have shifted repeatedly. Pin the package and track the MCP spec separately from the Laravel release cadence.
• Security surface. Tool invocation is model-directed. Prompt injection via tool output, over-broad tool scopes, missing per-tool authorization, and unbounded/expensive tool calls are the failure modes that matter. The package provides the plumbing; policy is yours.
• Long-lived connection behavior. SSE/streamable HTTP interacts poorly with load balancer idle timeouts, proxies that buffer, and PHP-FPM request time limits.

Key questions.

1. What exactly breaks between 3.1.0 and 4.0.0 — config keys, transport contracts, route definitions, or defaults?
2. Is stateless mode opt-in or default, and is it per-route/config-selectable?
3. Which MCP capabilities are unavailable in stateless mode, and does the package fail loudly or silently when a handler uses them?
4. Does the package ship authorization/authentication middleware recommendations, and are per-tool scopes supported?
5. What are the tested PHP and Laravel version floors for 4.0.0, and is Laravel 12 still supported on the 4.x line?
6. Are there timeouts, concurrency limits, or backpressure hooks for tool execution?
7. Is there an upgrade guide, and how active is the maintainer base (bus factor, release cadence, issue latency)?

Integration Approach

Stack fit. Native. Requires an existing Laravel app on a supported PHP/Laravel combination; Laravel 13 is now covered, which matters if the platform upgrade is on the roadmap. No new datastore is required for stateless mode — that is the point of the release. If you keep stateful transports, you retain the Redis/session-affinity requirement. Front with the same auth middleware, rate limiter, and logging pipeline as the rest of the app; do not stand up a separate edge for MCP.

Migration path (3.x → 4.x).

1. Read the diff and any upgrade notes for PRs #36 and #48; enumerate changed config keys, interfaces, and defaults.
2. Re-publish or diff the config file (vendor:publish --force into a scratch dir, then compare) — never overwrite a live config blindly.
3. Grep for direct use of transport/session classes and any handler reading request-scoped or session-scoped state.
4. Run the existing test suite against 4.0.0 on a branch before any behavioral change; add contract tests for each exposed tool.
5. Only then evaluate enabling stateless mode, per route, in staging.

Compatibility. Verify PHP floor and Laravel floor against your matrix. Third-party packages that touch the same container bindings or route groups are the usual collateral damage on a major bump. If you are mid-flight on a Laravel major upgrade, sequence framework upgrade and package major bump as separate changes — combining them makes bisecting failures materially harder.

Sequencing.

• Phase 0 — Audit (days). Diff review, breaking-change inventory, go/no-go.
• Phase 1 — Compatibility. Upgrade to 4.x in stateful mode only. No functional change. Prove parity in staging.
• Phase 2 — Stateless pilot. Enable stateless transport on a single low-risk toolset behind a feature flag. Validate behavior for tools that previously depended on session continuity.
• Phase 3 — Topology change. Once stateless is proven, remove sticky sessions / shared session dependency for the MCP route group and validate under multi-replica load.
• Phase 4 — Hardening. Per-tool authorization, rate limits, execution timeouts, audit logging of tool invocations and their arguments.

Do not invert Phase 1 and Phase 2. Stateless adoption should be a deliberate, reversible step, not a side effect of the version bump.

Operational Impact

Maintenance. The package now tracks the Laravel release train, which reduces the risk of being stranded on an EOL framework, but it also means a recurring upgrade obligation tied to Laravel majors. The MCP spec is the faster-moving of the two dependencies; expect to pin the package and review transport/auth changes on a quarterly cadence. A two-PR major release with a new contributor is a mild signal on maintainer bandwidth — worth watching release cadence and issue response time rather than assuming enterprise-grade support.

Support. No commercial backing implied. Internal ownership must be explicit: someone owns the tool catalog, the authorization model, and the upgrade cadence. Tool definitions are effectively a public API for AI clients — treat additions and removals as versioned contract changes with deprecation windows, or client agents will break silently.

Scaling. Stateless mode is the meaningful operational win: horizontal scaling without session affinity, compatibility with autoscaling groups and scale-to-zero HTTP runtimes, and simpler failover (any replica can serve any request). Costs shift from infrastructure to compute and model-adjacent spend: each tool call is real work, and an agent can generate high call volume. Enforce per-principal rate limits and per-tool concurrency caps at the Laravel middleware layer. Watch payload sizes — tool results are fed back into model context, so oversized responses inflate latency and token cost.

Failure modes.

• Silent capability loss — handlers depending on server-initiated messages no-op under stateless mode without erroring. Highest-severity risk; mitigate with per-tool contract tests.
• Timeout cascades — long tool executions exceed proxy/FPM limits, the client retries, and expensive work is duplicated. Enforce idempotency keys and hard execution budgets.
• Connection starvation — stateful SSE ties up PHP workers; size the pool or stay stateless.
• Authorization drift — a tool added without a scope check becomes an unguarded write path. Enforce via a checklist/CI lint on tool registration.
• Upgrade regression — a config key silently defaults differently post-major-bump; pin config in version control and assert it.
• Model-driven abuse — prompt injection inducing destructive tool calls. Require confirmation gates or dry-run modes for mutating tools.

Ramp-up. Two distinct skill sets: Laravel developers can define tools in hours, but reasoning about transport semantics, MCP capability negotiation, and agent-driven invocation patterns takes longer. Expect roughly: half a day for a Laravel engineer to ship a read-only tool in staging; one to two weeks for a team to be genuinely confident with stateless transport behavior, authz, and failure handling. Add review capacity for a security-minded pass on the tool catalog before any external exposure, and write down the tool catalog and its scopes early — it is the artifact both engineering and security will keep coming back to.