Statamic Mcp Laravel Package

Technical Evaluation

Scope of the release. v3.2.1 is a patch release containing four bug fixes and no new features, no deprecations, and no breaking API changes. Its significance is disproportionate to its version number: all four defects sit on the write path between an MCP client and Statamic's content store, and two of them are data-integrity issues rather than ergonomics issues.

Architecture fit. The package is an MCP server/adapter layered over Statamic's content API, with a date-normalization step inserted between inbound payloads and Statamic's validation. The fixes reveal that this normalization was previously implemented as a single top-level conversion pass; v3.2.1 replaces it with a conversion applied at every nesting level (grid rows, replicator sets, groups) and across all content types (entries, terms, globals). The architectural observation for a TPM is that date coercion is being handled by enumeration of container types rather than by recursive traversal of the field tree. That is the root pattern that produced four separate bugs at once, and it is the pattern most likely to produce a fifth.

Integration feasibility. Low effort, high value. Composer-level upgrade, no configuration changes implied by the notes, no migration commands mentioned. The one caveat is data, not code — see below.

Technical risk.

• Silent data corruption (highest severity). On sites outside UTC, the old top-level conversion appended a literal Z to a wall-clock value formatted in app timezone, shifting stored times. 2026-06-01 10:00 sent to a Europe/Copenhagen site was stored as 12:00. This means historical records written through the MCP on non-UTC sites may already be wrong, and the fix does not correct them.
• Complete write blockage (high severity, low blast radius). Any entry containing a date inside a grid, replicator set, or group failed validation on every update, regardless of what changed — including the specific case of programme and room entries with a prices grid carrying valid_from. Top-level range fields ({start, end}) and format: U Unix-timestamp fields similarly failed on all creates and updates.
• Test-coverage gap. The notes state plainly that the suite runs in UTC, "where the two agree, which is how it went unnoticed." A passing CI suite therefore provided no signal on timezone correctness. Until a non-UTC matrix exists, confidence in future date-path changes is low.
• Residual risk of incomplete fix. The fix is scoped to the container types that were reported. Whether dates nested more deeply (a grid inside a replicator inside a group, or date-bearing values in Bard/Set or computed fields) are covered is not stated and should be verified rather than assumed.

Key questions for the maintainer.

1. Is the new conversion recursive over the field tree, or an expanded enumeration of known containers? What is the guaranteed nesting depth?
2. Is there a regression test that runs the suite in a non-UTC timezone and asserts round-trip fidelity across grid/replicator/group/range/U combinations?
3. For reads, does a value round-trip unchanged in the field's configured save format, or is output normalized? The notes assert round-trip on write only.
4. What is the remediation guidance for records written through the MCP to non-UTC sites before v3.2.1?
5. What Statamic major versions and fieldtypes are in the supported matrix, and is the date logic intended to stay in the adapter or migrate upstream?

Integration Approach

Stack fit. Laravel + Statamic + an MCP client. The package adds a protocol surface, not a runtime dependency in the application's request path, so it does not alter the host application's architecture. The date-normalization layer is the only piece with meaningful coupling, and it couples to Statamic's fieldtype/validation internals — the most version-sensitive seam in the stack.

Migration path.

1. Pin and stage first. Upgrade in a non-production environment configured with a non-UTC app.timezone, since a UTC staging environment reproduces exactly the blind spot that hid the original bug.
2. Smoke-test the write path explicitly across: entry with prices grid containing valid_from; replicator set with a date; group with a date; top-level {start, end} range; format: U field; and the same matrix on a term and a global.
3. Audit existing data on non-UTC sites. Any record created or updated through the MCP before this release may hold times shifted by the offset difference between the app timezone and UTC. There is no automatic correction. Scope the audit by MCP write history if available, otherwise by sampling date-bearing fields in nested containers.
4. Communicate the behavior change. Values are now stored as sent. Editors or agents that implicitly compensated for the old shift will observe different results post-upgrade; this is a fix, but it is user-visible.
5. Roll forward, then add a guard so this class of defect surfaces earlier — a scheduled or CI job that exercises MCP writes against a non-UTC environment.

Compatibility. Patch-level, semver-compatible. Verify the Statamic version constraint in composer.json before rollout; the fix touches validation behavior, which is sensitive to Statamic minor releases.

Sequencing. Staging validation in a non-UTC timezone → data audit decision (blocking only for non-UTC sites with MCP write history) → production rollout → test-matrix addition. The audit and the code upgrade are independent and can proceed in parallel.

Operational Impact

Maintenance. Four distinct date defects in a single patch, all traceable to one design choice, is a signal to track this subsystem rather than treat v3.2.1 as closure. Ownership question worth raising: whether this logic belongs in the adapter or upstream in Statamic. Duplicating validation-adjacent normalization in an add-on means every Statamic fieldtype or validation change is a potential regression here.

Support. Net reduction in support burden — the grid/replicator date failure blocked all updates to affected records, and range and U-format failures blocked all creates and updates, all of which would have presented as opaque "Not a valid date" or PHP type errors to end users. Countervailing risk: the timezone change alters stored values, so expect a short tail of "the time changed" reports that need a prepared explanation of wall-clock vs. instant semantics.

Scaling. No performance or capacity implications. The added conversion work is per-payload and negligible against Statamic's own write cost.

Failure modes to watch.

• Silent wrong value — the timezone defect class. Highest harm, no error surfaced at write time. This is the mode that justifies the non-UTC test matrix and, ideally, a read-back assertion after write.
• Loud validation failure — the grid/range/U defects. Low harm, high visibility, and the mode most likely to be caught in staging.
• Partial application — not observed in these reports; failures occurred at validation, before persistence. Worth confirming explicitly if batched writes are supported.

Ramp-up. Low for developers (patch upgrade, no API change). Moderate for whoever owns data quality: they need a working model of the date contract — an ISO 8601 Zulu value is an instant and lands on the site's clock; a wall-clock value is read in the app timezone and converted to UTC; stored values round-trip unchanged. That contract should be documented in the integration notes, because it is exactly the distinction whose absence caused both the shift and the failed validation.