Laravel Loop Laravel Package

Product Decisions This Supports

• Build vs. buy for an "AI assistant layer": If your roadmap includes a natural-language copilot over your Laravel app (support triage, admin ops, "ask the app" experiences), Loop is a pre-built MCP transport + tool-registry layer. It lets you validate the product hypothesis — do users actually want to query our domain through an LLM? — in days instead of a quarter of custom protocol work.
• Whether MCP is the right integration surface: MCP is a bet on the emerging standard (Anthropic-originated, adopted across Claude Desktop, IDEs, and agent runtimes). Adopting Loop as a spike is a cheap way to test whether MCP beats a bespoke function-calling REST API for your assistant strategy before you commit architecture.
• Internal developer-productivity investment: The lowest-risk use case is giving engineers an MCP-connected assistant that can inspect routes, Eloquent models, config, logs, and run artisan commands. This is a headcount-leverage decision — decide whether "AI-assisted Laravel debugging" is a platform-team deliverable or an ad-hoc per-developer setup.
• Roadmap signal for AI-native features: If Loop's scope (models, routes, commands, logs as tools) matches the surface you'd want exposed, that tells you which domain objects are genuinely "AI-legible" — a useful input for deciding which features get structured/tool-friendly APIs next.
• Ops and support tooling: A read-only MCP endpoint over logs and app state is a credible internal support-assistant foundation — evaluate it against buying an observability vendor's AI features.
• Ecosystem/standards bet: Committing to a small, early package is a bet on the Laravel + MCP ecosystem maturing. Track it as a strategic option, not a commitment.

When to Consider This Package

Consider it when:

• You're on a supported Laravel/PHP stack and want an MCP server without writing the protocol layer — this is the entire value proposition.
• The use case is internal or developer-facing first: local dev assistants, engineering copilots, support debugging. Lower blast radius, fast feedback.
• You're running a time-boxed spike to answer "should we do MCP at all?" — MIT license, no procurement friction.
• Your team is comfortable reading the source and pinning a version; you can absorb breaking changes.
• You want a reference implementation to fork or learn from before building a hardened in-house server.

Look elsewhere (or build in-house) when:

• You need production-grade guarantees: no dependents, ~132 stars, single-agency maintenance, and a July 2025 release signal an early-stage project. Don't put this in a customer-facing path with SLAs without a fork-and-own plan.
• You need enterprise controls Loop doesn't own: per-user authz, multi-tenant scoping, audit logging, PII redaction, rate limiting, tool-level RBAC. Those are your responsibility regardless.
• Non-Laravel services are in scope — you'd want a language-agnostic MCP server.
• You need vendor support contracts or a security-review paper trail; a small OSS package won't supply it.
• Your assistant strategy is already settled on native function calling against your own API, where MCP adds a hop without adding value.
• Your app's value is in complex domain actions (workflows, approvals) rather than read/query surfaces — you'll write most of the tool definitions yourself anyway.

How to Pitch It (Stakeholders)

To executives: Loop is a small, MIT-licensed adapter that lets AI assistants talk to our Laravel app through MCP — the emerging standard connector. It converts a "we should explore AI copilots" talking point into a two-week, near-zero-cost experiment with no vendor lock-in. Recommendation: fund it as a scoped internal spike (dev productivity + read-only app inspection), not as a customer-facing commitment. Success criteria are concrete — time-to-first-useful-query, engineer adoption, and a written go/no-go on MCP as our assistant interface. The risk is maturity, not money: treat it as a prototype dependency and be prepared to fork.

To engineering: It's an MCP server for Laravel — it exposes Eloquent models, routes, config, logs, and artisan commands as MCP tools/resources, so Claude Desktop / IDE agents can inspect and act on the app without us hand-rolling JSON-RPC, capability negotiation, or tool schemas. That's real time saved. Caveats to plan around: early-stage package, zero dependents, one release — pin it, keep it out of customer-facing paths initially, start read-only, and put a security review in front of anything that touches PII or mutating commands. Assume we own authz, tenancy scoping, and audit logging ourselves. Exit criteria: if we keep it past the spike, we fork and own it — or we've learned enough to build the thin layer ourselves.