Mcp Laravel Package

Product Decisions This Supports

• Build vs. buy for an "AI-integration" surface. If the question on the table is "how do we let Claude/ChatGPT/Cursor/agents talk to our product," this package replaces a bespoke JSON-RPC + auth + schema layer with a first-party, convention-driven Laravel implementation. The buy case is strong on effort saved; the question that remains is protocol risk, not implementation cost.
• Which domain capabilities become agent-callable. The package's Tools / Resources / Resource Templates / Prompts primitives give you a vocabulary to scope the roadmap: which reads become Resources (customer record, order history), which writes become Tools (create ticket, issue refund), which become Prompt templates. This is a product-scoping decision, not an engineering one — the package makes each capability a deliberate, reviewable unit.
• API-surface governance for AI clients. Tools are effectively a second public API. Because each tool is a class with a declared input schema and output schema, you can apply the same deprecation, versioning, and review discipline as your REST API — and make that a roadmap commitment rather than an afterthought.
• New distribution and retention channel. Being callable from inside an IDE or chat client creates a usage surface outside your web UI. That supports decisions on activation metrics ("weekly agent-active accounts"), pricing/packaging for agent access, and whether agent usage is a feature or a tier.
• Prioritizing what "structured output" enables. Native structuredContent / outputSchema support means agents can reliably chain calls and render data — which is the difference between a demo and a workflow. That justifies investing in well-shaped domain responses over free-text answers.
• Security and permissioning roadmap. Built-in OAuth registration, scopes, and session handling let you decide who an AI client is and what it can touch per-tenant. This surfaces the real roadmap item early: agent identity, scoped consent, and audit logging.
• Use cases to validate cheaply. Internal tooling first (support ops querying orders, docs lookup, admin actions), then partner/enterprise integration ("call our MCP server instead of building a connector"), then end-user-facing assistants. The package's Artisan generator + inspector command make each of these a days-not-quarters spike.
• Competitive/positioning input. If competitors ship MCP servers, "we expose a governed MCP endpoint" becomes a checkbox feature; the package makes matching that table stakes cheap, so you can spend differentiators elsewhere.

When to Consider This Package

Adopt when:

• You are on a modern Laravel version (12/13) with PHP 8.2+ — the package has already dropped 8.1 and tracks framework releases closely.
• Your data and actions already live behind Laravel (Eloquent models, policies, jobs, existing REST/GraphQL resources). The package's value scales with how much of your domain is already modeled — it is thin glue over your app, not a new system.
• You want first-party maintenance and Laravel-idiomatic patterns (service providers, attributes, Artisan commands, test helpers like assertStructuredContent) rather than hand-rolling the protocol.
• You need OAuth-protected, multi-tenant, scoped access rather than a single API key — the OAuth registration and scope support is the reason to pick this over a minimal JSON-RPC shim.
• Your team can absorb pre-1.0 churn. This is a 0.x package with a fast release cadence and it has already shipped breaking changes (enum case renames, a JsonSchema contract switch). Budget for upgrade work each quarter.
• You can commit to an eval and QA loop — the inspector command and test assertions are the mechanism, but someone must own tool-quality testing (schema correctness, hallucination-resistant descriptions, failure modes).

Look elsewhere or wait when:

• You need a stability guarantee or an LTS-style support contract. Absent a 1.0, treat this as "pilot / internal-first," not as load-bearing infrastructure for a revenue-critical external integration.
• Your stack isn't Laravel — the value is almost entirely framework integration; a language-agnostic MCP SDK is the better fit for polyglot or non-PHP services.
• Your security posture is strict and unresolved. Exposing write-capable tools to autonomous agents requires consent UX, rate limiting, per-tool authorization, and audit trails. If those aren't on the roadmap this quarter, scope to read-only Resources first.
• You only need one narrow integration that a hosted connector or webhook already covers — protocol plumbing isn't free even when the code is.
• You depend on a specific MCP spec version or transport not yet supported; check protocol version support against your target clients before committing.
• You need a large ecosystem of examples and community answers. Stars (863) and pre-1.0 status mean fewer battle-tested patterns than mature Laravel packages; the "0 dependents" signal is a soft one for first-party packages but confirms limited third-party validation so far.

How to Pitch It (Stakeholders)

To executives (one paragraph): "AI assistants and coding tools are becoming a primary interface to software, and the emerging standard for that interface is MCP. laravel/mcp is Laravel's official package for exposing our application to those clients in days rather than months — it reuses our existing models, permissions, and OAuth, and it's MIT-licensed with no vendor lock-in. The recommendation is a bounded pilot: expose read-only tools for one internal team this quarter, measure whether agent-driven usage actually happens, and decide on external/partner exposure once we've validated demand and hardened permissions. The caveat is maturity — it's pre-1.0 — so we pilot internally and treat external exposure as a Phase 2 decision."

To engineering leadership:

• It's a thin, idiomatic layer over the framework — Tools/Resources/Prompts as classes, auto-generated schemas, OAuth and scopes included, Artisan scaffolding, an inspector for local QA, and test assertions for CI.
• Effort is dominated by domain design (which capabilities to expose, how to shape outputs) and security review, not by protocol code. Budget roughly a sprint for an internal read-only pilot, and plan for quarterly upgrade work while pre-1.0.
• Two adoption risks to own explicitly: protocol/version churn in the MCP spec, and the authz model for autonomous clients. Neither blocks the pilot; both must be resolved before external release.
• Success criteria to agree up front: tools shipped, calls per week by real (non-test) clients, error/failure rate per tool, and whether any workflow completed end-to-end through an agent that couldn't before.