Filament Mcp Laravel Package

Technical Evaluation

Architecture fit. Unchanged. filament-mcp remains a thin adapter between the Filament panel (resource forms as the source of truth for field definitions) and laravel/mcp (transport/server layer). The introspection bet — compiling form schemas into MCP tool arguments so tool definitions stay in lockstep with admin UI changes — is still the right thing for a TPM to evaluate, and it is now a slightly safer bet because the adapter has demonstrably tracked its upstream dependency through a major version.

Integration feasibility. Still high on paper, and marginally better in practice. The v0.1 release is a single dependency-alignment change ("Support Laravel MCP 1.0"), which tells you the integration surface is narrow enough that a protocol major can be absorbed in one PR. That is a useful datapoint: the package's coupling to laravel/mcp is real but shallow. The core install path (composer, publish config, register resources, authorization callback, point a client at the endpoint) is unchanged, as is the sensible default that create/read/update are generated while delete is per-resource opt-in.

Technical risk. The risk profile shifts in two ways, one favourable and one not.

Favourable — maintainer depth. @freekmurze (Freek Van der Herten, Spatie) landing the MCP 1.0 support PR is the most meaningful signal since the original assessment. It does not make this a supported product, but it materially improves the odds of timely patches for exactly the class of breakage you were most worried about, and it makes the "fork if necessary" contingency more credible rather than less. Bus factor is still 1.x, not 2, but the direction is right.

Unfavourable — version semantics. A 0.0.10 → 0.1 bump accompanying "Support Laravel MCP 1.0" is a coordinated major alignment, and the release notes contain no upgrade guide, no deprecation notice, and no statement of whether 0.0.10 configurations, published config files, or registered resources continue to work. In pre-1.0 semver, 0.1 is conventionally a breaking release. Any existing pilot on 0.0.10 + laravel/mcp 0.x should be assumed to need a coordinated bump until proven otherwise.

Risk list, re-prioritised:

• Upstream version coupling (now demonstrated, not hypothetical). MCP 1.0 support arrived as a hard version alignment with no compatibility shim. You must pin filament-mcp and laravel/mcp as a pair and upgrade them together. This is manageable but it is a standing tax.
• Undocumented upgrade path. The absence of an upgrade guide for a 0.1 release is a process gap, not a code gap. For a TPM this means every version bump requires a schema-diff spike rather than a changelog read.
• Filament coupling. Unchanged and still the largest long-term risk: form introspection reaches into Filament's schema API, which churned from v3 Form to v4 Schema. Note that v0.1 addresses the MCP axis, not the Filament axis — no evidence yet that a Filament major would be absorbed as cleanly.
• Write surface equals admin surface. Unchanged. Authorization is delegated to your policies; uneven policy coverage is inherited at machine speed.
• Schema expressiveness gaps. Unchanged. Repeaters, relation managers, nested builders, uploads, and custom components are where round-tripping is weakest. If MCP 1.0 revised tool-schema conventions, this is the area most likely to have shifted in behaviour — verify rather than assume.
• Information disclosure. Unchanged. "Same as the admin panel" is still not the same threat model.

Key questions for the maintainer / spike.

1. What are the exact composer.json constraints for laravel/mcp and filament-mcp at v0.1, and is there any supported path for staying on MCP 0.x?
2. Is v0.1 a breaking change for 0.0.10 users — config keys, resource registration API, authorization callback signature, generated tool schema shape?
3. Did MCP 1.0 change tool schema conventions or client behaviour in ways that alter generated arguments, error surfacing, or transport endpoints?
4. Is the CI matrix now explicit about supported Laravel / Filament / MCP majors?
5. Is @freekmurze a one-off contributor or an ongoing co-maintainer with merge rights? This determines whether the bus-factor improvement is durable.
6. Still open from the prior review: handling of ->hidden(), ->disabled(), canAccess(), panel tenancy; per-tool vs per-record authorization; validation-rule translation and 422 surfacing; audit attribution of agent writes; rate limiting and payload limits; token store vs stateless auth.

Integration Approach

Stack fit. Laravel + Filament panel + PHP 8.2ish, now with laravel/mcp ^1.0 as the target transitive dependency. Fits naturally where Filament is the canonical field contract; does not fit where admin is hand-rolled Blade or Nova.

Migration path. Still near-zero-data migration — configuration and governance, not schema. Two changes to the path. First, pin the pair explicitly: filament-mcp ^0.1 with laravel/mcp ^1.0, and do not mix with 0.0.10-era installs. Second, because there is no published upgrade guide, treat the version bump itself as a mini-spike: install v0.1, regenerate tool schemas for one resource, and diff against the schemas produced under 0.0.10 before touching anything else. If you have no existing install, skip that and start clean on v0.1 — this release makes greenfield adoption simpler, not harder.

Compatibility. Co-version filament-mcp, laravel/mcp, and Filament as a single upgrade unit; never upgrade one independently. The v0.1 release is evidence that the maintainer (and now at least one experienced outside contributor) will do this alignment work, which lowers but does not eliminate the need for your own CI matrix — with 0 dependents there are still no third-party compatibility reports. Fork-readiness remains a Phase-2 prerequisite rather than a Phase-4 afterthought; the code surface is small enough that this is realistic.

Sequencing.

• Phase 0 — Read-only spike on staging, single content resource, on v0.1 / MCP 1.0. Capture generated tool schemas and diff against the form. Exit criterion: schema fidelity for every field, and a written note of any schema differences versus pre-1.0 output.
• Phase 1 — Create on low-risk resource, with request logging and a kill switch. Exit criterion: validation errors reach the agent as actionable, not as 500s.
• Phase 2 — Update, gated on a policy coverage audit across exposed resources and a written blast-radius statement per resource.
• Phase 3 — Delete opt-in, sandbox data only, soft deletes where available.
• Phase 4 — Developer-facing agent workflows (Claude Code / Cursor against staging) before any customer- or content-facing automation.

Deliberately defer: tenancy, file uploads, relation-manager-heavy resources. Also defer any upgrade of an in-flight pilot until the schema diff in Phase 0 confirms v0.1 is behaviourally equivalent for your resources.

Operational Impact

Maintenance. Small code surface, low commit volume, and now one credible outside contributor. The burden you inherit is still mostly your config and policy hygiene plus tracking two upstreams (Filament, laravel/mcp). The v0.1 release is a good demonstration of the maintenance model working — a major upstream bump absorbed quickly — but it also confirms you inherit the upgrade cadence of laravel/mcp whether you want to or not. Plan for the possibility of maintaining a fork; the package remains small enough that this is realistic.

Support. No vendor, no SLA. README, changelog, releases, GitHub issues — and, notably, release notes that are auto-generated changelogs rather than upgrade guidance. Your internal runbook needs to cover: how to disable the endpoint, how to revoke a token, how to identify which agent wrote which record, and how to diff generated tool schemas between package versions (this last one is new and belongs in the runbook, not in someone's head).

Scaling. Unchanged. MCP calls land as ordinary HTTP requests in your app process; scaling is your existing app's scaling problem with an agent traffic shape — bursty, retry-heavy, prone to re-reading the same records. Add explicit throttling on the MCP route, watch for N+1s introduced by form introspection, and note there is no queueing story: long-running tool calls are your request timeouts. Do not assume MCP 1.0 changes transport-level scaling characteristics; verify it if you are load-testing.

Failure modes to instrument for.

• Coordinated-version drift: filament-mcp and laravel/mcp upgraded out of step, producing failures at boot or at tool-call time rather than at review time.
• Silent behaviour change across the 0.1 boundary — generated tool schema shape, error format, or transport endpoint differing from 0.0.10 with no changelog entry explaining it.
• Form field added or renamed → tool schema drifts, agent sends stale arguments, confusing validation failures.
• Policy gap → over-broad write access no human reviewer would have approved.
• Partial multi-field updates leaving records in an inconsistent intermediate state.
• Non-representable field types (uploads, repeaters) failing opaquely rather than being excluded from the tool schema.
• MCP protocol/client version mismatch after a client upgrade — reduced but not eliminated by 1.0 support.
• Token leakage in client configs — treat these tokens as production credentials, because they are.

Ramp-up. Low for a Laravel developer (hours to a working endpoint). Moderate for the team: someone must own MCP client literacy and, more importantly, own the tool descriptions and policy audit — tool-use quality is governed by schema clarity, and vague generated descriptions produce bad agent behaviour that looks like a package bug. One new line item: whoever owns the dependency pins now owns an upgrade ritual (bump both packages together, regenerate schemas, diff). Overall: the v0.1 release improves the case for a bounded spike and slightly improves the fork contingency, but it does not by itself justify a production dependency without an explicit policy audit, a co-versioning policy, and a documented upgrade procedure.