Weave Code
Statamic Mcp Laravel Package
cboxdk/statamic-mcp
A Statamic addon that exposes your site to AI assistants through the Model Context Protocol, letting MCP clients like Claude browse and manage entries, taxonomies, and content via secure tools.
MCP (Model Context Protocol) server for Statamic CMS v6 — gives AI assistants structured access to content, blueprints, assets, and more.
Frequently asked questions about Statamic Mcp
- How do I install cboxdk/statamic-mcp in a Laravel Statamic site?
- Install it with Composer using composer require cboxdk/statamic-mcp in your Laravel application running Statamic v6. Because it is a Statamic addon, follow the repository README for addon registration and MCP server configuration. The v3.2.1 release notes do not mention migration commands, new configuration requirements, or breaking changes.
- Does cboxdk/statamic-mcp support Laravel 11 and Statamic v6?
- The package is built as a Statamic CMS v6 addon, so your Laravel application must meet Statamic v6's own Laravel and PHP requirements. The v3.2.1 notes do not list a separate Laravel version matrix for this package. Verify compatibility against your Statamic v6 installation before upgrading.
- What can an AI assistant do through this Statamic MCP server?
- It gives MCP clients such as Claude structured access to Statamic content, entries, taxonomies, blueprints, assets, and related site data. The addon exposes secure tools so an assistant can browse and manage content through the Model Context Protocol rather than through ad hoc API calls. It adds a protocol surface to your Statamic site rather than replacing Statamic's own control panel or content API.
- How do I connect Claude or another MCP client to my Statamic site?
- Configure your MCP client with the server endpoint, transport, and credentials described in the package README. The addon runs as a Statamic MCP server, so access should be limited to trusted clients and environments. The v3.2.1 release notes do not indicate any configuration changes required for existing MCP client setups.
- What date and timezone bugs were fixed in cboxdk/statamic-mcp v3.2.1?
- v3.2.1 fixes four write-path defects involving date normalization between MCP clients and Statamic. It corrects a non-UTC issue where a wall-clock value could be stored shifted, such as 10:00 becoming 12:00 on a Europe/Copenhagen site. It also fixes validation failures for dates nested in grids, replicator sets, and groups, plus range fields with start and end values and format U Unix timestamp fields.
- Do I need to fix existing content after upgrading to v3.2.1?
- Yes, you should audit content written through the MCP on non-UTC sites before v3.2.1. The release fixes future writes but does not correct historical records that may already have shifted times. The notes do not provide remediation guidance, so compare stored values against expected local times and plan corrections in staging before touching production data.
- Why did dates inside grids, replicator sets, or groups block entry updates before v3.2.1?
- The earlier date-normalization step was applied only at the top level, so nested date values were not converted correctly before Statamic validation. Any entry containing a date inside a grid, replicator set, or group could fail validation on every update, even when that field was not being changed. v3.2.1 applies the conversion at every nesting level and across entries, terms, and globals.
- Does v3.2.1 cover dates nested in Bard, Set, computed fields, or deeper combinations?
- The release notes scope the fix to the reported container types and do not state a guaranteed nesting depth beyond that. It is not clear whether the new conversion is recursive over the field tree or an expanded enumeration of known containers. Verify your specific Bard, Set, computed-field, and deeply nested grid/replicator/group combinations in a non-UTC environment rather than assuming coverage.
- How should I test cboxdk/statamic-mcp for timezone correctness?
- Run your test suite and staging site with a non-UTC app.timezone, because the package's CI suite runs in UTC where the old bugs did not surface. Create, update, and read entries containing dates at the top level, inside grids, replicator sets, groups, range fields, and Unix timestamp fields. Assert that values round-trip unchanged in the field's configured save format and that unrelated updates do not fail validation.
- Is upgrading to cboxdk/statamic-mcp v3.2.1 safe for production?
- v3.2.1 is a patch release with no new features, deprecations, or breaking API changes, and the notes imply no configuration or migration steps. The main production concern is data integrity, because records written through the MCP on non-UTC sites before the upgrade may already be wrong. Stage the Composer upgrade in a non-UTC environment, verify write and read behavior, audit existing date values, then deploy.
Weaver
How can I help you explore Laravel packages today?