Weave Code
Mcp Bundle Laravel Package
sulu/mcp-bundle
Sulu MCP Bundle integrates the Model Context Protocol into Sulu CMS, letting AI assistants and MCP clients query content, manage pages, and automate editorial workflows through configurable, secure tools and resources.
Sulu MCP Bundle connects your Sulu CMS to Model Context Protocol (MCP) clients, letting AI assistants and developer tools query and interact with Sulu through a standardized interface. It fits into Sulu’s Symfony stack and provides a practical foundation for building AI-assisted content workflows.
- Exposes Sulu functionality as MCP tools for compatible clients
- Symfony bundle integration with configurable services
- Extensible architecture for registering custom tools
- Designed to work with Sulu’s existing security model
- Lightweight setup for AI-assisted CMS development
Frequently asked questions about Mcp Bundle
- What is sulu/mcp-bundle and what does it do?
- sulu/mcp-bundle is a Symfony bundle from the Sulu CMS project that adds a Model Context Protocol (MCP) server to your Sulu installation. It exposes Sulu pages, content and admin capabilities as MCP tools so AI assistants and MCP clients such as Claude Desktop, IDE agents or custom orchestrators can query and manage content through a standard interface. It is not a standalone CMS or a separate data store; it is an adapter tier that sits in front of Sulu's existing content services and Doctrine/PHPCR storage. Installation is via Composer, then bundle registration and endpoint configuration.
- Can I use sulu/mcp-bundle in a Laravel application?
- No. sulu/mcp-bundle is a Symfony bundle built specifically for Sulu CMS, which is a Symfony-native content management system. It plugs into the Symfony dependency injection container, bundle registration and config tree, and has no Laravel service provider or Laravel integration path. If your application is Laravel-based and not running Sulu, this package is out of scope for you. Look for a dedicated Laravel MCP package instead.
- How do I install sulu/mcp-bundle?
- Install it with Composer using composer require sulu/mcp-bundle, then enable the bundle in your Symfony kernel or bundles.php. From there you configure the MCP endpoint through the bundle's config tree and point an MCP client at that endpoint. A read-only spike is typically a matter of days rather than weeks. Productionizing it requires additional project work around authorization mapping, transport hardening and audit logging.
- Which Sulu, Symfony and PHP versions does sulu/mcp-bundle support?
- The bundle targets Sulu 2.x on Symfony 6 or 7 with PHP 8.1 or newer, but you should confirm the exact supported matrix before committing because the package is pre-1.0 and version constraints can move. Ask the maintainers whether the compatibility matrix is CI-enforced. Pin exact versions in composer.json and gate upgrades behind testing, since Sulu minor releases and Symfony changes can affect behavior. This is a blocking prerequisite for teams with pinned dependencies.
- Which tools does sulu/mcp-bundle expose, and can AI agents modify content?
- The bundle surfaces Sulu content operations as MCP tools, which includes reading pages and content but also admin-level actions that can mutate content. That means the blast radius of an automated tool call includes publishing and unpublishing pages, overwriting translations, and changing navigation or SEO fields. Treat this as an AI-agent-shaped write path into production content, not a read-only API. Enable only the tools you actually need and keep human approval gates around destructive operations.
- Is there a read-only mode or per-tool authorization in sulu/mcp-bundle?
- A global read-only mode and per-tool authorization are the key questions to raise with the maintainers, because the package is early-stage and tool schemas may change. In practice you should plan to allow-list individual tools and scope each one rather than exposing the full tool set to every client. Prompt injection through content is a realistic vector here: an agent reading an untrusted page could be steered into a mutating tool call. Restricting the exposed tool surface and requiring human approval for writes mitigates most of that risk.
- Which MCP transports does sulu/mcp-bundle support — stdio, HTTP+SSE or streamable HTTP?
- The bundle is designed to run an MCP server alongside your Symfony application, but the exact transport support (stdio, HTTP with server-sent events, or streamable HTTP) should be verified with the maintainers before you design your deployment. Remote and multi-client deployments depend entirely on which transports are available and how authentication is handled for each. Budget for running the MCP server as a new deployable or a new route group in your stack. Treat the protocol boundary as a volatile dependency rather than a stable contract.
- How are Sulu roles and per-webspace permissions enforced for MCP tool calls?
- Because tool calls route through Sulu's content services, permission enforcement depends on how the bundle maps MCP clients onto Sulu roles and per-webspace or per-site security. You should confirm whether each tool call is evaluated against a real Sulu user context or whether it runs with elevated system permissions. If per-tool authorization is not built in, implement it at the MCP client or gateway layer. This mapping work is project responsibility, not something the package solves out of the box.
- Are AI-initiated tool calls audited or logged in sulu/mcp-bundle?
- Audit logging is one of the areas the maintainers should be asked about directly, since it is not clearly part of the package's core guarantees. For production use you will likely need to log who called which tool, when, and the before/after payloads, either through Sulu's own logging or a wrapper around the MCP endpoint. Telemetry hooks and rate limiting should be verified too, especially if multiple clients share one endpoint. Plan for this as integration work rather than assuming it ships by default.
- Is sulu/mcp-bundle production-ready, and how stable are its tool schemas?
- Treat it as pre-1.0 and early-stage: it has minimal adoption, a single-vendor provenance and no independent production evidence, so tool names and schemas may change between releases. Ask the maintainers about their semver and deprecation policy for tool identifiers, and whether breaking schema changes ship as major versions. To keep exit cheap, wrap tool names and payloads behind your own internal abstraction rather than calling them directly throughout your codebase. Removing the package later is a simple bundle deregistration, provided you have not coupled internal tooling to its tool schema.
Weaver
How can I help you explore Laravel packages today?