- How do I expose my Filament admin panel to AI agents over MCP?
- Install mattiasgeniar/filament-mcp and it acts as a thin adapter between your Filament panel and the official laravel/mcp server. It introspects your existing resource forms and generates per-record create, read, and update tools, with delete tools available as a per-resource opt-in. You then point Claude Code, Cursor, or any MCP client at your app, gated by a token and an authorization callback you control. Unlike read or bulk-action oriented alternatives, it creates real per-record CRUD tools and enforces your policies.
- What are the requirements and how do I install filament-mcp?
- You need PHP 8.2 or newer, Laravel 12 or 13, and Filament 5. Install it with composer require mattiasgeniar/filament-mcp, then run php artisan migrate. The config file is published automatically by the install command, or manually with php artisan filament-mcp:install or php artisan vendor:publish --tag=filament-mcp-config.
- Which MCP tools are generated for each Filament resource?
- Each exposed resource gets per-record create, read, and update tools generated from its existing form schema. Delete tools are not generated by default and must be explicitly enabled per resource. Because tools are compiled from your forms, a new field in the admin UI shows up as a tool argument automatically. Only text-like fields are exposed.
- How is access to the MCP server authenticated and authorized?
- Access is forbidden by default, so nobody can connect until you explicitly grant access in config/filament-mcp.php. Connections are gated by a token plus your own authorization callback, so you decide who is allowed. This safe-by-default posture means you must configure both the allowed users and the resources you want to expose before an agent can do anything.
- Does filament-mcp respect my Filament policies?
- Yes. Authorization is delegated to your existing Filament policies, so an agent can only do what a given user is permitted to do. The catch is that uneven policy coverage is inherited at machine speed, so audit your policies before exposing write-capable tools. Access is also audited on every call, which helps you spot gaps.
- What form components and fields does filament-mcp support?
- Only text-like fields are exposed as MCP tool arguments, which keeps the generated schema simple. Repeaters, relation managers, nested builders, file uploads, and custom components are where round-tripping is weakest and should be verified rather than assumed. If a resource relies heavily on those components, expect incomplete create or update behavior through MCP.
- Is there an audit log of MCP tool calls?
- Yes. Every tool call is recorded and attributed to the token that made it. You can review a token's call history on its own activity page inside the Filament panel. That makes it practical to trace what an AI agent changed and which credential was responsible.
- Is filament-mcp compatible with laravel/mcp 1.0?
- Version 0.1 adds support for Laravel MCP 1.0 as a single dependency-alignment change. That bump from 0.0.10 is a coordinated major alignment and, in pre-1.0 semver, should be treated as breaking: there is no published upgrade guide, deprecation notice, or compatibility shim. Pin filament-mcp and laravel/mcp as a pair and upgrade them together, then diff your config keys, resource registration, authorization callback signature, and generated tool schemas.
- Who maintains filament-mcp and what is the bus factor?
- The package is primarily maintained by Mattias Geniar, so the bus factor is roughly one. Freek Van der Herten contributed the Laravel MCP 1.0 support pull request, which is a meaningful signal that upstream breakage of the kind you would worry about can be patched quickly. That makes the fork-if-necessary contingency more credible, but it is still not a formally supported product.
- What should I verify before running filament-mcp in production?
- Treat the MCP write surface as equal to your admin panel surface, because an agent inherits whatever your policies allow at machine speed. Restrict which resources are exposed, confirm policy coverage is complete, scope and rotate tokens, and review per-token audit history regularly. Also pin package versions as a pair and test complex forms for schema round-tripping before rollout, since same-as-the-admin-panel is not the same threat model as human administrators.