Mcp Bundle Laravel Package

Product Decisions This Supports

• Roadmap bet: agent-accessible CMS. Deciding whether AI assistants should be first-class citizens in the content workflow (drafting, updating, auditing, translating, linking) rather than a side integration. RC4 widens the surface with link and shadow page settings, a nested-block removal fix, and an admin-link tool that sends the editor straight to the relevant CMS screen.
• Build vs. buy for the MCP layer. Rather than designing a bespoke LLM tool API on top of Sulu's content APIs, this bundle is a credible off-the-shelf adapter — and RC4 extends it with content-type and third-party tool-gating extension points, so custom tools can layer on top rather than fork. The "build" estimate collapses to integration, hardening, and pilot scoping.
• Prioritizing AI editorial use cases. Informs sequencing of bulk metadata updates, content gap analysis, localization drafts, and editorial QA — each maps to a concrete tool surface. RC4 adds product coverage inside unified content search, which pulls catalog content (not just pages) into the QA/analysis use case.
• Agent permissioning as a product decision, not a config task. RC4 makes this concrete: every tool now declares readOnlyHint / destructiveHint / idempotentHint / openWorldHint, product results are gated behind the product permission, snippet context resolves per group, and deletes require permissions across every locale. This is a usable substrate for a read-only-pilot-then-guarded-write rollout, and for a client-side approval policy that keys off tool hints rather than tool names.
• Identity and access story for assistants. OAuth Client ID Metadata Documents (CIMD), switchable dynamic client registration, stateless MCP protocol support, and a client-management CLI (sulu:mcp:create-client, now with custom and mistral-le-chat types) turn "how do assistants authenticate?" from an open question into a reviewable design. Still a security review item, not a solved one.
• Architecture boundary: core CMS vs. domain bundles. Product tools moved out of the core bundle into SuluProductBundle, and third-party bundles can gate their own dangerous tools. Implication: the "AI surface" is now a federation of bundles, which is good for roadmap scaling (PIM, DAM next) but means permission and audit behaviour must be assessed per bundle, not once.
• CMS platform evaluation. If Sulu is on the shortlist, first-party MCP support plus 3.1 compatibility becomes a differentiator signal for an AI-forward content stack; if Sulu is already in place, this is a low-cost capability unlock.
• Vendor/dependency posture. Still early-stage — pre-1.0 release candidate, thin public adoption, no LTS — but RC4 shows sustained first-party maintenance and an increasingly stable tool contract (resourceKey in results, string resource ids). The bet is on Sulu maintainers' direction, not on a mature ecosystem.

When to Consider This Package

Consider it when:

• You are already running Sulu (Symfony/PHP) and have engineering capacity to integrate and maintain a bundle; 3.1 is now exercised in CI.
• You want to validate agentic content operations quickly — a spike or internal pilot — before committing to a custom MCP server or a broader AI content platform.
• Your requirements are read-mostly or human-in-the-loop (summarize, draft, propose edits, generate admin deep links for review) and you can tolerate an early-stage integration.
• You need a defensible authorization story: per-tool safety hints, permission-gated search results, per-locale delete checks, and a choice of OAuth client registration modes give you something to review rather than a blank page.
• You want assistants usable from mainstream clients without custom glue — documented CIMD, dynamic registration, stateless protocol, and Mistral Le Chat client guides reduce pilot setup time.
• MIT licensing, no per-seat cost, and full source access matter for your procurement or security review.
• You are standardizing on MCP as the tool protocol and want CMS coverage without building it yourself.

Look elsewhere when:

• You are not on Sulu, or are on a CMS with an established, vendor-supported AI/MCP integration.
• You need production SLAs, long-term support commitments, or a track record — a pre-1.0 RC with limited field validation is not that.
• Your security model requires independently audited write access, per-tool authorization policies enforced server-side by default, and mature audit logging out of the box. RC4 adds hints and permission gates, but hints are advisory metadata for clients — you still own enforcement and logging.
• You cannot absorb tool-surface churn: RC4 re-keyed unified content tools by resourceKey and relocated product tools to another bundle, both of which break integrations built on RC3.
• Your team is not PHP/Symfony-native; integration and debugging cost shifts the build-vs-buy math back toward a thin custom service.
• You need broad multi-system tool coverage (PIM, DAM, commerce) out of the box — coverage is spreading across bundles, but it is not one integration to own.

How to Pitch It (Stakeholders)

For executives: This remains a small, reversible bet that tests whether AI assistants can operate our CMS directly. Since the last review the package has matured in exactly the areas a pilot depends on: assistants can be onboarded through standard OAuth flows, every tool now self-describes whether it reads or destroys, permissions are enforced on search results and deletes, and third-party bundles can gate their own risky tools. It is MIT-licensed, runs on the Sulu stack we already have, and lets us run a bounded pilot — one or two editorial workflows, measured on cycle time and rework — instead of funding a custom AI content platform. Costs stay contained and there is no license lock-in. The main new caveat is that the tool contract is still moving ahead of 1.0, so the pilot must be time-boxed and pinned; the decision this informs is unchanged: whether agent-accessible content is a real product capability or a novelty.

For engineering: A Symfony bundle wrapping Sulu's content APIs as MCP tools, now with a per-tool hint contract, extensible content types, third-party tool gating, and OAuth (CIMD, switchable dynamic client registration, stateless MCP, client CLI). Adoption is still a thin integration, and RC4 is still an RC: pin the version and expect breaking churn — product tools moved to SuluProductBundle and unified content tools are now keyed by resourceKey, so anything built on RC3 tool names or shapes needs rework. Treat the safety hints as client-side advisory, not server-side enforcement. Before production content: review exactly which tools are enabled, keep write paths behind an approval flow, add audit logging and scoped credentials, and confirm per-locale permission semantics on delete. First milestone stays a time-boxed spike — read-only tools plus admin-link generation to prove the review loop, then a single guarded write path — with a go/no-go on pilot results. Plan to own maintenance and upstream contributions rather than consume a mature dependency.