Symfony Mcp Server Laravel Package

Product Decisions This Supports

• Feature: exposing existing PHP domain services to LLM clients as callable tools. This package is the MCP server layer, so the decision it unblocks is "do we build an agent-facing surface on top of our existing backend, and how?" rather than "do we rewrite our API."
• Roadmap: MCP as the agent integration contract vs. bespoke LLM endpoints. Adopting a spec-compliant server now means tool definitions, transports, and client compatibility are someone else's maintenance problem as the protocol evolves — a meaningful hedge given how fast MCP is moving.
• Build vs. buy. The realistic comparison is not "package vs. nothing" but "package vs. a hand-rolled JSON-RPC/MCP server plus schema validation plus transport handling." For a team without spare platform capacity, the package wins on time-to-first-tool; the buy-side risk is coupling to one maintainer's release cadence.
• 1.9.0 specifically: tool schema expressiveness. oneOf/anyOf/allOf composition in tool input schemas changes product design options, not just code:
  • Fewer, richer tools. Previously, polymorphic arguments (e.g. a filter that is either a range, a set, or a text match) forced either a permissive "anything goes" schema or a fan-out into multiple near-duplicate tools. Composition lets one tool carry a precise contract.
  • Better model behavior. Tighter schemas reduce malformed tool calls and retry loops, which is the difference between a demo and a usable agent. This is a quality/latency lever, not a cosmetic one.
  • Discriminated unions become viable. allOf + a discriminator is the standard way to model variant payloads; before this, those use cases had to be flattened or split.
• Use cases this now covers that it didn't at 1.8.x: agents that must pick between heterogeneous actions in one step, tools wrapping APIs with genuinely polymorphic inputs, and internal copilots where argument precision matters more than tool count.

When to Consider This Package

Adopt when:

• You are a Symfony shop, or a Laravel shop comfortable pulling Symfony components and owning the glue. This is a Symfony bundle; the Laravel path is viable but not first-class, and you should budget for that.
• You have a concrete near-term MCP client (Claude Desktop, an IDE agent, an internal agent runtime) and want tools shipped in weeks, not quarters.
• Your tools are schema-shaped — CRUD over domain entities, query builders, workflow triggers — where declarative input schemas do most of the work.
• You want the protocol details (transports, capability negotiation, schema serialization) off your critical path.
• 1.9.0 raises the ceiling on how complex your tool signatures can be before the package becomes the constraint. If you previously rejected this package because your tool inputs were polymorphic, re-evaluate.

Look elsewhere when:

• Your team is Python- or TypeScript-first. The official SDKs there have more eyes, more examples, and faster coverage of newer protocol features.
• You depend on bleeding-edge MCP capabilities beyond tools — sampling, elicitation, resource subscriptions, auth flows. Verify current coverage before committing; a single-maintainer package typically trails the spec.
• You are not on Symfony and the Laravel bridge is unproven for you. The integration tax can exceed the savings.
• You need vendor SLA, security review artifacts, or multi-team support commitments. This is a community package; treat it as such in your risk register.
• Your agent surface is small and stable (three or four tools). Hand-rolling may be cheaper than adopting a dependency whose upgrade path you now own.

Watch items: the 1.9.0 changelog is a single line — no migration notes, no compatibility statement. Composition support can change how existing schemas are serialized; smoke-test your current tools against an MCP client before rolling out, and pin the version if you ship to customers.

How to Pitch It (Stakeholders)

For executives: We can expose our backend to AI assistants and agent clients without building and maintaining a protocol server ourselves. This is the integration layer for the agent features on the roadmap — it's a dependency, not a platform bet, and it's reversible. The 1.9.0 release removes a real design ceiling: our tool definitions can now describe complex, variant-shaped inputs precisely, which measurably improves how reliably models call them. The trade-off to acknowledge is support: it's a community package with one primary maintainer, so we pin versions and keep an exit path.

For engineering: 1.9.0 adds oneOf/anyOf/allOf composition to tool schemas. Practical effect: stop splitting tools by argument shape and stop shipping permissive schemas that let the model guess. Use allOf + discriminator for variant payloads rather than flattening. Two asks before adoption: (1) regression-test existing tool schemas against a real MCP client on upgrade — the release note says nothing about serialization changes, and composed schemas can alter emitted JSON Schema; (2) pin the minor version in composer.json and review each release manually, since we're taking a direct dependency on a low-bus-factor package. If we're on Laravel rather than Symfony, spike the integration first and timebox it — if the glue exceeds roughly a sprint, revisit the official SDK in another language and wrap our services over HTTP instead.