Laravel Mcp Connect Laravel Package

Product Decisions This Supports

• Build vs. buy for AI/tooling integrations: This package turns "which AI tools do we expose / consume?" into a catalog-selection problem rather than a bespoke-integration problem. A PM can ship agentic features (tool execution, server discovery) without staffing a dedicated integration team — 3,400+ governed MCP servers is a large pre-built surface area to evaluate against internal roadmap needs.
• Roadmap acceleration for AI-assistant features: If the roadmap includes copilots, workflow automation, or "let the app reason over external tools," this is a credible v1 dependency to prototype against in a spike, moving the decision from "can we do this?" to "which servers do we activate and how do we govern them?"
• Feature-scoping via discovery primitives: mcp:search, mcp:browse, and mcp:inspect give PMs and analysts a low-effort way to survey capabilities in the catalog before committing to a feature spec — useful for validating demand and scoping a first release.
• Operational and compliance decisions are instrumented: The event-driven observability (ToolExecuted, ServerActivated) and analytics command support the product questions that typically follow adoption — which tools are actually used, who activates what, and what the audit trail looks like. That directly informs pricing, tiering, and internal governance policy.
• Public Marketplace API (no token) lowers the bar for low-risk, read-only surfaces — internal dashboards, docs sites, or a public "browse the catalog" experience can be built without provisioning credentials, which is a cheaper experiment than a full authenticated integration.

When to Consider This Package

Consider adoption when:

• You are on Laravel 11/12 and PHP 8.2+ — the requirements are narrow and modern, so confirm your fleet is already there before scoping.
• The product genuinely needs many heterogeneous external tools; the value proposition is breadth, so a single integration is better served by a direct client.
• You want governed access — the "governed MCP servers" framing and Bearer auth/retry/structured error classification matter if enterprise or security review is in the path.
• You need observability and an audit trail out of the box rather than retrofitting it after launch.
• A discovery-first workflow fits your team — the Artisan commands and 7 guides mean engineers and analysts can self-serve during evaluation.
• You are comfortable depending on the Vinkius catalog as a third party — catalog contents, availability, and governance posture are outside your control.

Look elsewhere when:

• The requirement is one or two tightly-scoped integrations, or you need bespoke protocol behavior the SDK doesn't expose.
• You require vendor independence or self-hosted catalog control; this is a client for a specific commercial catalog.
• Your stack is PHP < 8.2 or Laravel 10 or earlier — this is not a gradual migration candidate.
• You need long-term API stability guarantees — this is a v1.0.0, and the dual API surface and DTO set are likely to evolve.
• Latency-critical or offline paths where an external HTTP round trip plus cache TTLs is unacceptable.

Risk notes to carry into the decision: v1.0.0 means pre-stability; caching is read-through with per-endpoint TTLs (confirm staleness tolerance); the Marketplace API is public and unauthenticated, so treat it as non-sensitive only; and 59 Pest tests / 191 assertions is respectable but thin for a 13-DTO, dual-surface SDK — worth exercising the specific endpoints you depend on.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is the official Laravel SDK for the Vinkius MCP Catalog and it converts "should we build AI tool integrations?" from a multi-month engineering program into a scoped, time-boxed evaluation. We get access to 3,400+ governed MCP servers through a maintained dependency — catalog browsing, tool execution, auth, retries, caching, and audit events are already built — so the team can spend its time on product decisions (which tools, which users, what governance) instead of plumbing. Cost is a Composer dependency plus catalog terms, not headcount. Recommendation: fund a short, contained spike against one real use case, with defined exit criteria, rather than a broad commitment.

For engineering: Small, idiomatic footprint — a fluent Mcp facade, 13 readonly DTOs with typed mapping, HTTP transport with Bearer auth, retry, and structured error classification, plus a read-through cache with per-endpoint TTLs. Six Artisan commands make it debuggable and demo-able from a terminal on day one. Config is publishable via a single vendor:publish tag. The honest caveats: it's v1.0.0, so pin the version and wrap the facade behind a thin internal interface so we can swap or upgrade without touching feature code; and expand test coverage around the specific endpoints we depend on rather than relying on the shipped suite.

For security/compliance: Governed servers, Bearer-authenticated catalog access, structured error classification, and first-class audit events (ToolExecuted, ServerActivated) give us a usable trail without custom instrumentation. Two things to resolve before production: the Marketplace API is public and unauthenticated, so it must stay on non-sensitive, read-only surfaces; and catalog-side governance is a third party's obligation, so we need to document how we validate it.

Ask: Approve a two-week evaluation with a named use case, a version pin, and go/no-go criteria covering catalog fitness, latency under our cache TTLs, and third-party risk acceptance.