Fancy Flow Mcp Laravel Package

Product Decisions This Supports

• Build vs buy. This package is an authoring/convention layer over laravel/mcp, not a runtime. It defines Server, Tool, and Resource classes and pins a version contract; the transport, protocol handshakes, and route registration stay in laravel/mcp. That makes it a low-lock-in buy — worth taking for the conventions and the test scaffolding, cheap to drop if it stops earning its place.
• Feature sequencing. Because v0.5.0 only widens the constraint to ^0.9|^1.0, migration to laravel/mcp 1.x becomes a schedulable roadmap item rather than a forced one. You can ship MCP features on 0.9 today and move the runtime later, independently of this package.
• Dependency risk budgeting. Adopting this package ties your upgrade cadence to laravel/mcp's, not the reverse. The real upgrade work in 1.x lands on your side of the wire — Mcp::web(...) routes now require MCP-Protocol-Version / Mcp-Method / Mcp-Name headers from 2026-07-28 clients (legacy initialize clients exempt), and Request::sessionId() is removed. Budget for that as an app-side task, not a package-side one.
• Observability and support triage. The #[Version] fix is quietly product-relevant: serverInfo is emitted in every initialize response, so the package was telling every connecting agent it was 0.1.0 while shipping 0.4.0. Any client-side compatibility gating, telemetry, or "what version are you on?" support conversation was reading a value three minors stale. Now it's pinned to the newest changelog entry by a test, with a second assertion that the attribute actually consumes the constant — a stale-but-correct constant would still lie.
• Use cases worth scoping now. Internal tool servers, agent-facing read APIs over existing Laravel models, and any place where you want MCP tools to live alongside existing app code and test conventions rather than in a separate service.

When to Consider This Package

Adopt when:

• You're on Laravel and building an MCP server with more than a handful of tools — the conventions pay for themselves once there's more than one contributor.
• You want to stay on laravel/mcp 0.9 for now but not be stranded there; v0.5.0 explicitly buys you that optionality, and CI now tests both 0.9.* and 1.* so the untested half of the range isn't a fiction.
• You want version reporting you can trust in agent handshakes without hand-maintaining it.
• You value a release process with a changelog gate over one without.

Look elsewhere when:

• You need transport, auth, or protocol-level control — go to laravel/mcp directly; this layer adds indirection without adding capability there.
• You're not on Laravel.
• You have one or two trivial tools, where the abstraction costs more than it saves.
• You need hardened supply-chain guarantees (SBOM, attestation, strict pinning). This is a 0.x package from a small publisher; the workflow rename to a shared publish.yml is a house-style consolidation, not a maturity signal.
• Treat 0.x as pre-1.0: no API-stability promise, and minor bumps can carry behavior changes.

How to Pitch It (Stakeholders)

To executives: a small, low-risk dependency that unblocks MCP work without committing us to a specific laravel/mcp major. v0.5.0 is a compatibility widen plus a correctness fix. No migration, no cost of action, no breaking changes.

To engineering: upgrade is a no-op — ^0.9 is still in range, so existing installs resolve unchanged. Moving to laravel/mcp 1.x is opt-in: require ^1.0 and run composer update laravel/mcp -W; this package needed no code changes for 1.0 because the classes it defines are unaffected per the upgrade guide. The one thing to actually verify is our own MCP endpoint tests: 1.0 changed HTTP header requirements on Mcp::web(...) routes and removed Request::sessionId(). If we assert on HTTP responses, read laravel/mcp's UPGRADE.md before bumping.

The one-line version: safe to take now, takes nothing away, and buys us the option to move to laravel/mcp 1.x on our own schedule — with the caveat that the upgrade work lives in our app, not in this package.