Laravel Vurb Laravel Package

Product Decisions This Supports

• Agent-readiness as a roadmap item. v1.0.0 makes "expose our product to AI agents" a scoped, shippable feature rather than a research spike. A Laravel team can publish MCP tools over existing domain logic (controllers, actions, services) instead of standing up a parallel TypeScript/Node service — directly informing whether agent access lands in the next quarter or the next year.
• Build vs. buy on MCP infrastructure. The package bundles the undifferentiated heavy lifting — tool registration, presenters (schema shaping), middleware, FSM state gates for multi-step workflows, DLP redaction, governance hooks, and observability. Buying this (MIT, zero license cost) shifts the internal build from "protocol server + governance layer" to "which of our capabilities should be tools."
• Scope negotiation for the first agent surface. Because tools are declared inside Laravel, PMs can prioritize a small, high-value tool set (e.g., order lookup, ticket creation) and ship iteratively — the package doesn't force a big-bang platform migration.
• Enterprise/compliance gating. DLP redaction and governance/audit features are the difference between "we can demo this" and "we can let a regulated customer's agent call it." That directly affects which segments you can sell agent features into and what security review artifacts you'll need.
• Use-case validation for internal vs. external agents. The same server can back internal copilots (low risk, fast feedback) and customer-facing agents (needs the governance layer). This supports sequencing: internal first, external once observability and redaction are proven.

When to Consider This Package

Good fit when:

• The product is a Laravel 11/12/13 app on PHP 8.2+, and the domain logic you want agents to reach already lives there.
• You want to expose app capabilities as MCP tools without hiring or reallocating TypeScript/Node expertise — "zero TypeScript" is the core value proposition.
• Governance is a requirement, not an afterthought: DLP redaction, FSM state gates, middleware, and observability shipped in the box rather than being a later hardening phase.
• You need auditability of agent actions for security review, SOC2-style questionnaires, or customer procurement.
• You're standardizing on MCP as the integration contract and want one server serving multiple agent clients (IDE assistants, chat agents, internal copilots).

Look elsewhere or defer when:

• The stack isn't Laravel/PHP, or the agent-facing surface must be polyglot — a language-agnostic MCP server may be a better long-term home.
• You cannot run a Node.js process in production. The bridge daemon spawns and supervises a Vurb.ts Node process via npx. That's an operational dependency (runtime availability, process supervision, version pinning, and npm supply-chain exposure) that some platform/security teams will veto. Treat this as a first-class adoption gate, not a footnote.
• You need protocol-level control or non-standard transport behavior that a bridge abstraction may not expose.
• Maturity tolerance is low. Despite 750 tests / 1,815 assertions / 97.59% coverage, this is a v1.0.0 with a single release — no track record of upgrade paths, deprecation policy, or production incident history. Coverage measures tested behavior, not battle-tested behavior.
• Latency budgets are tight and an extra process hop per tool call is material.

Recommended evaluation path: prototype one or two tools in a staging environment, explicitly validating (a) daemon lifecycle and failure modes under load, (b) how tool schemas evolve as your domain changes, and (c) what the DLP/governance config actually redacts versus what your security team expects.

How to Pitch It (Stakeholders)

For executives: This is the shortest credible path to making our product callable by AI agents. It's MIT-licensed, so there's no commercial commitment or vendor lock-in, and it lets our existing Laravel team deliver the capability instead of funding a new TypeScript service. The package ships with the governance and audit controls that enterprise buyers will ask about, which is what makes this sellable rather than demo-able.

For engineering: A single composer require plus php artisan vurb:install / vurb:serve gives us an MCP server built on our existing conventions — tools, presenters, middleware, and FSM state gates are declarative in Laravel, so there's no second stack to maintain. The test posture is unusually strong for a v1 (97.6% coverage), and MIT terms mean no procurement cycle before we spike it.

For security/platform: The one thing to scrutinize before sign-off is the bridge daemon: it runs a Node process via npx, so we need a pinned version, a supervised process, and a decision on npm dependency risk in production. The compensating factor is that DLP redaction, governance, and observability are in-scope from day one rather than bolted on later — but we should verify the redaction behavior against our own data classification rules rather than assume.

Bottom line: Green-light a bounded pilot on internal, low-risk tools; gate customer-facing exposure on the daemon-in-production decision and a security review of the redaction/governance layer.