Statamic Mcp Laravel Package

Product Decisions This Supports

• Whether automated/AI-assisted content operations become a first-class workflow. The package is the write path between an MCP client (agent or automation) and Statamic content. v3.2.1 removes the class of failures where an agent could read a content model but could not update it, which is the difference between a demo and an operational capability.
• Which content models are safe to expose to automation. Previously, any entry carrying a date inside a grid, replicator, or group was effectively read-only through this package — every update failed validation with "Not a valid date," regardless of what changed. Common models hit this: programmes with a prices grid (valid_from), room/availability listings, anything with a schedule embedded in a block. Those models can now be scoped into the automation surface deliberately rather than excluded by accident.
• Multi-site and non-UTC rollout. The timezone defect meant a value sent as 2026-06-01 10:00 to a Europe/Copenhagen site was persisted as 12:00 — invisible in a UTC test suite, silently wrong in production. For any product where a date is the content (events, publications, embargoes, bookings), this was a correctness blocker for adopting automation on non-UTC sites at all.
• Data remediation is now a decision, not just a bug fix. The old top-level conversion ran on writes for some time. If automation has been writing to non-UTC sites, stored values may be offset. Product needs to decide whether to audit and correct historical entries before scaling usage — that is a scoping call with editorial cost attached.
• Build vs buy for the MCP layer. The alternative to adopting this is maintaining bespoke REST endpoints plus fieldtype-aware serialization. Each bug fixed here (nested fieldtypes, range mode, format: U, timezone round-tripping) is work you would otherwise own permanently, and each is a bug you would only find after shipping.
• Roadmap sequencing for editorial automation. Range-mode and Unix-timestamp fields were fully broken for writes; that closed off content types (scheduled ranges, timestamps-as-integers) from automation. Those can now enter scope. Conversely, this release tells you the package's hardening is ongoing and driven by real usage — plan adoption in waves, starting with the content models that have the highest ratio of volume to editorial judgment.
• Risk posture for agent-driven writes. No breaking changes here, but the release is a reminder that this layer sits between an autonomous writer and canonical content. The relevant product decision is not "can it write" but "what is the blast radius when it writes something wrong, and how do we detect it."

When to Consider This Package

Adopt when:

• You run Statamic (Laravel) as the system of record for content and want agent or script-driven authoring rather than manual Control Panel work.
• Your content models rely on nested fieldtypes — grids, replicators, groups — especially with dates inside them. This release is the specific unlock for those models.
• You operate multiple sites outside UTC, or your content is date-critical (events, releases, embargoes, availability). The timezone fix is a correctness prerequisite, not a nicety.
• You have an MCP-capable client or agent framework already in the stack, or are prepared to adopt one.
• You want to buy the fieldtype serialization and validation-translation problem rather than own it. This release is a good demonstration of how much subtle surface area that problem has.
• You can stage the rollout: enable automation per content model, with a rollback path into manual editing.

Look elsewhere or wait when:

• Your CMS is not Statamic, or you are headless-first on a different platform — the package's value is largely its fieldtype-aware handling of Statamic's data model.
• You need fine-grained field-level permissions, approval workflows, or a durable per-write audit trail. That is a governance layer above this package; adopting it without one means trusting the agent and the logs of the calling system.
• You require vendor SLAs or a support contract. This is community-maintained and its stability story is a changelog of field-type edge cases being closed one at a time.
• Your content models lean on custom or third-party fieldtypes that do not yet have proven round-trip coverage. Verify against your own schema before committing.
• You have no appetite to re-verify after releases. Bug-fix cadence means you should re-run write-path checks on upgrade.

Immediate validation step regardless of decision: if automation has already written to non-UTC sites, audit entries with date fields for offset drift before trusting the corpus. The fix corrects future writes; it does not repair past ones.

How to Pitch It (Stakeholders)

For executives: This release closes the gap between "AI can read our content" and "AI can safely change it." Before v3.2.1, a whole category of content — anything with a date buried inside a structured block, which is most of our scheduling and pricing content — could not be updated through the automation layer at all. Just as importantly, it corrects a silent timezone defect that wrote the wrong time onto non-UTC sites while passing every test we ran in UTC. Neither was a feature; both were the difference between an automation capability we could pilot and one we could not defend in production. There are no breaking changes and no migration required to upgrade. What it does change is our confidence: the tool now handles the content models we actually have, on the sites we actually run. The open question it hands back to us is governance — how much autonomy we grant the writer, and what review step sits in front of it — not whether the plumbing works.

For engineering: Bug-fix release, no breaking changes, no deprecations. Four fixes, all in the date-value translation layer between MCP-submitted values and Statamic's stored format. The substantive one is #64: conversion to the storage format previously ran only at the top level of a record, so dates nested in grids, replicators, and groups were validated against a different format than they were stored in and failed on every write. That is now applied at every level across entries, terms, and globals. The old top-level pass also formatted wall-clock time with a literal Z, shifting values on non-UTC sites by the app-timezone offset — masked by a UTC test suite. That is replaced with a proper wall-clock-in-app-timezone → UTC conversion. Range values ({start, end}) and format: U fields, both previously broken on write, now validate and round-trip. Action items: run a write-path smoke test against a non-UTC site and against a model with a date inside a grid before deploying; if automation has been writing to non-UTC sites, backfill-audit affected date fields, since this fixes future writes but not the stored corpus.