filament-mcp is a Laravel package that exposes Filament admin panel resources as an MCP server, letting AI agents call typed tools like `create_post` or `update_product` directly instead of using slow browser automation. It auto-generates named tools from existing Filament resource forms, enforces the same authorization layers (gates, policies, query scopes, Eloquent `$hidden`), and audits every call. Delete tools are opt-in only. Tokens are user-bound, hashed, and can be self-managed via a panel UI. Requires PHP 8.2+, Laravel 12 or 13, and Filament 5.
Table of contents
Why a second way in #Installing it #What the agent gets #Customisability, all of it optional #It’s the same panel, with the same locks #Tokens, from the CLI or the panel #Connecting a client #What it won’t do (yet) #Questions this post answers
What are the requirements to install filament-mcp?
filament-mcp requires PHP 8.2 or higher, Laravel 12 or 13, and Filament 5. Installation is two commands: `composer require mattiasgeniar/filament-mcp` followed by `php artisan migrate`. The migration creates two tables — one for hashed access tokens and one for auditing every tool call. A config file is published automatically on install. PHP developers integrating AI agents into Filament panels track packages like this on daily.dev.
How does filament-mcp handle delete operations and why are they not enabled by default?
Delete tools are never generated by default — they require an explicit opt-in per resource in the config (`'delete' => true`). Even when enabled, the model's Filament policy still runs per record before any deletion proceeds. This design treats destructive operations as a deliberate choice rather than a side effect of exposing a resource, keeping the default configuration safe. Teams giving AI agents write access to production data weigh trade-offs like these on daily.dev.
How does filament-mcp prevent AI agents from accessing fields that are hidden in Eloquent models?
Eloquent `$hidden` and `$visible` settings are enforced before any schema is built, so hidden attributes never appear in tool discovery, reads, writes, search, or sorting — even if the field exists in the Filament form. Writes are driven by the form schema, so agents can only set fields the form exposes. Reads return the union of the infolist and writable form fields. Developers scoping AI agent access to sensitive data find security patterns like this on daily.dev.