Filament Mcp Laravel Package

Product Decisions This Supports

• Extending the admin panel's reach without building a new surface. If your product already runs on Filament, this package turns each existing resource into a set of per-record create/read/update tools an AI agent can call. The core decision it unlocks: do we let agents operate our back office, or do we build a separate integration/API layer for that? This is the cheap version of the former.
• Feature investment in "agent-operable admin." Useful for roadmap framing of internal tooling: content ops, catalog management, support-assisted data entry, QA data seeding, bulk-but-policy-checked updates. If any of those are on your roadmap as manual-work reduction, this is a candidate implementation.
• Build vs. buy (vs. skip) for MCP exposure. Building an MCP server that mirrors your Filament resources by hand means maintaining a second schema that drifts every time a field changes. The value proposition here is zero-marginal-cost schema maintenance: the resource form is the contract, so new fields become tool arguments automatically. That materially shifts the build-vs-buy math toward "buy/adopt" for teams already deep in Filament.
• Authorization architecture decisions. Because it gates access via a token plus an authorization callback and relies on your existing policies, adopting it forces a useful conversation: are our Filament policies actually complete and correct? If they aren't, that's a finding you want before you expose anything to an agent.
• Scope decisions around destructive operations. Delete is explicit per-resource opt-in, which maps cleanly to a product decision about agent autonomy tiers (read → write → destructive) rather than an all-or-nothing "enable AI" switch.
• Platform-alignment decision: track the official MCP SDK. v0.1 moves to laravel/mcp 1.0. That's the version of this package to standardize on, and it means the integration layer now sits on the official SDK's stable major rather than a moving 0.x target — one fewer dependency-drift risk to carry, at the cost of a one-time migration if you prototyped against laravel/mcp 0.x. The package's own version bump to 0.1 is a signal of intent, not a stability guarantee; treat it as "the maintained line," not "1.0-grade."

When to Consider This Package

Adopt for an evaluation / internal-only pilot when all of these hold:

• You run Laravel with Filament as the real admin surface, and your resources/forms are the authoritative definition of your data model.
• Your use case requires writes, not just reads — that's where the generated per-record CRUD tools beat read/bulk-action alternatives.
• Your policies are already enforced and reasonably complete, and you're comfortable that the authorization callback can express your tenancy/role model.
• The consumer is a trusted, known agent (Claude Code, Cursor, an internal ops bot) rather than untrusted end users.
• You are on, or willing to move to, laravel/mcp 1.0 — v0.1 is the release that tracks it. If you have nothing running against the MCP SDK yet, this is a neutral condition; if you prototyped on 0.x, budget for the upgrade.
• You can pin the version and accept reviewing an early-stage package's code and changelog yourself.

Look elsewhere, or don't pursue, when:

• Vendor-risk tolerance is low. Low star count and negligible dependents remain a genuine signal: this is still effectively a single-maintainer, pre-adoption package. v0.1 does not change the bus factor. It is not a dependency to put on a revenue-critical path without a fork-and-own plan or a spike that proves you could maintain it.
• Your admin isn't Filament-based, or your forms don't reliably mirror your domain rules (validation in observers/jobs, computed fields, multi-step wizards will leak).
• You need field-level redaction, PII masking, rate limiting, or audit trails richer than "the token and the callback." Those are governance gaps you'd have to fill yourself.
• You need SLAs, security attestation, or multi-tenant isolation guarantees — nothing here suggests that's in scope.
• The need is read-only analytics or bulk reporting; the read/bulk-action-oriented alternatives are a better fit and a smaller attack surface.

One risk indicator softened slightly, not resolved: v0.1 landed with a contribution from a well-known figure in the Laravel ecosystem, and the package kept pace with the upstream SDK's 1.0 release. That's evidence of a live, responsive maintenance line and modest outside attention — but it is one PR on a compatibility bump, not a co-maintainer commitment. Do not restate the vendor-risk case upward on the strength of it.

Minimum validation before committing: a timeboxed spike covering one resource, one policy denial path, a failed-validation path, and a delete-disabled check — plus a diff test showing a new form field appears as a tool argument without extra work. Add a compatibility check that you're on laravel/mcp 1.x and that nothing else in your stack pins it lower.

How to Pitch It (Stakeholders)

To executives: We can make our existing admin panel operable by AI agents for a fraction of the cost of a bespoke integration, because it reuses the forms and permission rules we already maintain. The trade-off is maturity — this is an early, low-adoption package, though it has just aligned with the official MCP SDK's stable release and picked up an outside contributor, which tells us it's being actively kept current. Recommendation: fund a small spike, keep it internal and read-mostly at first, and treat destructive actions as an explicit opt-in we control per resource.

To engineering: It's a thin adapter, not a new system of record. It introspects Filament resource forms and generates per-record create/read/update tools on the official laravel/mcp server — as of v0.1, the laravel/mcp 1.0 line — gates everything behind a token and an authorization callback, and defers to your existing policies. Delete is off unless you enable it per resource. Three caveats to own: the form becomes the API contract (so form-only validation is now a security boundary); v0.1 is a dependency-compatibility release, so treat the upgrade as a small migration task and read the PR rather than assuming drop-in; and we should still pin the version, read the source, and have a fork plan given the small maintainer base.

To security/compliance: Scope is limited to what a human admin could already do in the panel, subject to the same policies. We will not enable delete, we will log tool invocations, and we will not expose this beyond internal, credentialed clients until the package has more adoption or we've forked it. Note that the current release is primarily an upstream SDK compatibility change and contains no new security or governance features — our open gaps (redaction, rate limiting, audit depth) are unchanged.