Statamic Mcp Laravel Package

Product Decisions This Supports

• Shipping AI/agent features on top of existing content models. The package turns "what fields does this thing have?" into a queryable contract. v0.9.1 closes the last obvious gap: blueprints_get now answers for type: navigation, not just collections and page builders. If your roadmap includes agent-assisted authoring, CMS migration tooling, or a schema-aware chatbot, this release is the difference between "agents can write pages" and "agents can write navigation," which is where real site structure actually lives.
• Mega menus and other nested navigation as a first-class agent surface. The release explicitly targets replicator/Bard fields inside navigation branches — a mega menu whose branches hold cards. Previously an agent had to reverse-engineer card field names by reading an existing branch from navigations_get; now blueprints_get returns the fields, an example branch data payload, and per-set field definitions with an example row. That converts a guessing-and-retry loop into a single deterministic read, which is a directly measurable reduction in agent tool calls and malformed writes.
• Scoping the "agent-safe write" epic. The example_notes addition (pass title/url as branch keys, not inside data) is a small but telling signal: the package is being shaped around correctness of generated payloads, not just schema disclosure. That supports a roadmap decision to invest in an agent write-path for navigation (navigations_update) rather than treating navigation as read-only and forcing manual edits.
• Build vs buy. If your team is hand-rolling prompt context by dumping YAML blueprints or serializing fieldset config into a system prompt, this replaces bespoke glue with a maintained, versioned contract. The trade is dependency on a pre-1.0 third-party surface.
• Permission and access-control design. Reads take view {handle} nav, mirroring navigations_get. That consistency means your existing Statamic permission model governs what an agent can inspect, so you can reason about agent capabilities per-role without inventing a parallel ACL — a meaningful de-risking point for security review.
• Use cases enabled now: AI-assisted navigation/mega-menu authoring; content-model discovery for migration or auditing agents; generating seed/fixture data that matches real blueprint shapes; onboarding tooling that explains a site's structure to a new developer or client.

When to Consider This Package

Adopt when:

• You are on Statamic and building any agentic or LLM-backed authoring, migration, or audit workflow that touches structured content.
• Your navigation uses branching structures (mega menus, card-based menus, Bard/Replicator inside nav) — this release is precisely for you; before it, those were the hardest shapes to generate correctly.
• You want agents constrained by the CMS's own schema and permissions rather than free-form generation, and you value the read (blueprints_get) / write (navigations_update) symmetry.
• You already depend on the package for collection or page-builder blueprints — this is an additive capability, no migration implied.

Look elsewhere or wait when:

• You need API stability guarantees. This is 0.9.x. Version numbers below 1.0 mean shapes can and do change between minors; treat the response schema as unstable and pin the dependency. If you cannot absorb a breaking change on short notice, hold until 1.0.
• Your navigation is flat and field-light. If there are no replicator/Bard sets in nav, the headline feature buys you little; the existing navigations_get may already be sufficient.
• You need write-side navigation authoring today with no gap. The release improves reading blueprints for nav; it does not itself add or change a write path. Confirm navigations_update covers your branch shapes before committing to the workflow.
• You require documented deprecation policy, LTS posture, or vendor SLA. Nothing in this release speaks to that, and 0.x packages rarely offer it.
• Your agent stack is not MCP/tool-call oriented — the value is in exposing schema as callable tools; if you are doing static prompt injection, the fit is weaker.

How to Pitch It (Stakeholders)

For executives: This is a small, targeted release to a pre-1.0 package that we use (or are evaluating) to let AI agents work with our CMS safely. The concrete win is that agents can now correctly read and therefore correctly populate navigation menus — including complex mega menus with nested card content — instead of guessing at field names and producing broken output. That removes the single biggest source of agent error in site-structure work and unblocks any roadmap item involving automated navigation changes. Cost and risk are low: it's additive, no breaking changes, no migration, and it inherits our existing permission model, so agents only see what the role allows. The one caveat is maturity — at 0.9.x we should pin the version and expect occasional churn.

For engineering: Adoption is a version bump; the change is additive. blueprints_get now accepts type: navigation with a navigation handle and returns branch data fields plus an example, and for Replicator/Bard fields it returns set-level fields and an example row — the same contract already used for page builders, so the parsing path is not new. Auth reuses view {handle} nav, consistent with navigations_get. Two things to internalize: example_notes now instructs that title and url belong as branch keys, not inside data — make sure our prompt/tooling respects that or we will generate subtly invalid payloads; and pin the dependency, since 0.9.x gives no stability guarantee. Suggested follow-up: add a regression fixture asserting a mega-menu branch round-trips through blueprints_get → navigations_update, so a future minor bump can't silently break the agent write path.