Server Laravel Package

Product Decisions This Supports

• Roadmap: "agent-ready" as a real epic, not a checkbox. Shipping an MCP server turns your existing product surface — entities, workflows, reports, catalog data — into callable tools for any MCP-compatible client (Claude Desktop, IDE agents, partner copilots). The decision to fund it is a distribution bet: you make the product addressable by agents without building a bespoke integration per platform.
• Build vs. buy on undifferentiated plumbing. A compliant MCP server means JSON-RPC framing, stdio and HTTP/SSE transports, capability negotiation, tool/resource/prompt schemas, input validation, and session lifecycle — all of which churn as the spec evolves. This package absorbs that. The PM decision is to spend saved cycles on the thing that actually differentiates: which 8–12 capabilities are exposed, and with what permissions.
• Scope and risk trade-offs you own. Read-only resources (docs, catalog, report retrieval) versus mutating tools (create/update/trigger) is a product risk decision, not an engineering one. So is per-tool authorization scoping, rate limits, and what data an agent may never touch.
• GTM and packaging inputs. Agent access raises concrete questions: does it ship in existing tiers or as an "AI/API" add-on? Do we list in MCP directories and agent marketplaces? Does "supports MCP" become an RFP/competitive checkbox?
• Prioritization signal. Tool-invocation telemetry tells you which capabilities agents actually reach for — a cheaper, faster read on API roadmap priorities than customer interviews.
• Internal first, external later. The same server can power internal ops automation (support triage, data pulls, back-office agents) as a low-risk proving ground before customer-facing exposure.
• Sequencing against other AI bets. Adopting this is orthogonal to your model strategy and does not commit you to a chat UI; it keeps the integration layer standardized while the LLM layer stays swappable.

When to Consider This Package

Adopt when:

• PHP/Laravel is the system of record. You want domain logic and permissions to stay where they live rather than standing up a parallel TypeScript/Python gateway just to speak MCP.
• Time-to-market beats spec ownership. You need MCP compatibility this quarter and cannot spare the multi-sprint cost of implementing and tracking the spec yourself.
• Your tool surface is small and well-bounded. A handful of well-understood operations is exactly where a protocol library earns its keep.
• You can wrap it. Putting an internal adapter interface around the server lets you swap implementations if the package stalls or the spec moves.

Look elsewhere or defer when:

• You only need vendor function calling. If your sole requirement is tool use inside one model provider's API, the protocol layer is overhead — use native function/tool schemas.
• You need managed infrastructure. Authentication gateways, SSO, audit trails, SLAs, and SOC 2 are out of scope for a library; pair this with your own gateway or buy a hosted platform.
• The stack is polyglot. Official TypeScript/Python SDKs tend to land spec changes first; a PHP server risks lagging on transports and auth semantics.
• Governance is strict. ~870 stars, an initial release in July 2025, and a small maintainer base imply real bus-factor risk. Without an internal fork, a spike, or an abstraction layer, this should not sit on a critical path unexamined.
• Read-only, low-stakes data. A plain REST endpoint plus a few lines of adapter code may be simpler and cheaper than a protocol dependency.

How to Pitch It (Stakeholders)

One line: An MIT-licensed PHP library that makes the product we already have callable as tools by AI agents over MCP — the emerging standard used by Claude, IDE agents, and a growing client ecosystem.

For executives: It is a low-cost, low-commitment wedge into agent ecosystems. We convert existing PHP investment into an "AI-accessible" surface, gain a credible roadmap and RFP talking point, and avoid rebuilding integration per AI vendor. Ask: one sprint of spike work, then a go/no-go with a defined tool surface.

For engineering: The spec compliance — transports, capability negotiation, schemas, sessions — is undifferentiated work we should not hand-roll. We adopt, wrap it behind an adapter interface, and retain ownership of tool definitions, authorization, and rate limiting. Primary risks are spec churn and maintainer depth; pinning versions and the wrapper contain both.

How we'll know it worked: time to first working tool, number of external clients connected, tool-invocation volume and repeat usage, partner integration time, and support-deflection from internal automation.

Explicit non-goals: this is not our model strategy, not a hosting platform, and not a customer-facing chat product. It is the plumbing that lets agents act on our product — and it should be judged on that alone.