Mcp Kit Laravel Package

Product Decisions This Supports

• Build vs. buy on the "AI staff copilot" layer. This package is the governance substrate you'd otherwise write a spec for: identity (per-person tokens), authorization (ability catalogue mapped to existing policies), audit trail, and human-in-the-loop confirmation for writes. Deciding to adopt it is really deciding not to staff that work internally.
• Roadmap sequencing: read-only first, writes later. The preview/confirm-writes mechanism makes "assistant can read, drafts changes for a human to approve" a shippable milestone distinct from "assistant mutates data." That's a roadmap lever, not just a feature.
• Scope of the AI surface area. The ability catalogue is the product definition — every ability added is an explicit decision about what staff may ask an assistant to do. Treat it as a curated, versioned product artifact with an owner, not an auto-generated dump of routes.
• Compliance and internal-controls posture. Per-person tokens plus audit middleware give per-user attribution and revocation. That's the artifact you need when security or audit asks "who told the assistant to do that, and can you prove it?"
• Personalization as a product bet. Per-user assistant memory and onboarding are a retention/activation feature for internal tooling — but also a data-retention and offboarding obligation. Decide deliberately whether memory is in scope before the pilot, because retrofitting deletion semantics is painful.
• Concrete use cases to validate against: back-office ops (order/account lookup), support triage, admin-console automation, refund or credit drafts rather than executions, and onboarding flows where the assistant walks a new hire through permitted actions.
• Input to internal API prioritization. Gaps in the ability catalogue surface which internal endpoints are undocumented, unstable, or unsafe to expose — useful signal for platform investment regardless of whether you keep the package.

When to Consider This Package

Adopt-consideration criteria (all should hold):

• Laravel app with established authentication (Sanctum/Passport) and a real policies/gates layer — abilities need something legitimate to hang off.
• An internal staff user base, not end customers.
• You've already concluded assistants should reach internal tools via MCP rather than bespoke per-assistant integrations.
• Compliance or internal controls require per-user attribution and an audit log for AI-initiated actions.
• A small platform team that cannot absorb 4–8 weeks of token issuance, middleware, audit, and confirmation-flow work.
• Appetite for early-stage dependency risk: 0 stars, 0 dependents, single maintainer. Treat as an evaluated prototype: read the source, pin the commit, plan to fork (MIT makes that cheap).

Look elsewhere when:

• The assistant is customer-facing — different threat model: abuse, rate limiting, prompt injection from untrusted input, PII exposure, and brand risk. This package's per-person token model assumes known, trusted staff.
• Stack is polyglot or non-Laravel; nearly all the value is in the Laravel middleware/auth integration.
• You have no meaningful RBAC today — the catalogue would be aspirational and the audit log would record decisions made on fictional permissions.
• You need a hosted MCP gateway with SSO/SCIM, DLP, egress allowlists, or vendor SLAs and security attestations now.
• Needs are read-only and narrow — a hand-rolled MCP server over a handful of endpoints is less code than vetting and maintaining a dependency.
• Prompt-injection or data-exfiltration risk from tool output is a first-order concern; confirm nothing in the package addresses output sanitization before relying on it.

How to Pitch It (Stakeholders)

For executives: We want staff using AI assistants against our internal Laravel tools, and the blocker has been governance, not capability. This is a thin, MIT-licensed layer that ties every assistant action to a named person, checks it against the permissions we already enforce, logs it, and — for anything that changes data — shows the human a preview and waits for confirmation. That turns "should we let AI touch our systems?" from an open-ended security debate into a staged rollout: read-only first, then writes approved one ability at a time, with an audit trail from day one. The alternative is roughly one to two months of platform engineering to build equivalent token, permission, and audit plumbing we'd then own forever. The honest caveat: it has no public adoption yet, so we should budget a code review and assume we may fork it. MIT licensing makes that a bounded cost, not a lock-in.

For engineering: It is not a framework rewrite and it does not introduce a second permission system — abilities are gated by the policies you already have, and the middleware sits in the normal request path. Preview/confirm gives you a clean interception point for dry-runs and test fixtures. Two things to hold firm on: keep the ability catalogue behind an internal interface of our own so replacing the package is a contained change, and pin the version with the source vendored for review, given zero dependents and a single maintainer.