The global reference mode answers Kirby questions and cannot touch a project; the project-local mode can read and write but requires confirmation for every mutation, keeps PHP evaluation off unless you enable it, and runs CLI commands only from an allowlist. Running both, with the reference server always on and the project server only where needed, is the setup the docs point at.
A CLI-first server for composer-based Kirby projects. It reads the project's structure, talks to a real Kirby runtime, and ships a local knowledge base of Kirby concepts so the agent does not have to guess at the framework.
- Inventory of the project: blueprints, templates, snippets, collections, controllers, models, plugins, routes and roots
- Content read and written for pages, files, users and the site, with writes behind an explicit confirmation
- A page rendered by the real runtime, returning HTML and errors, with a trace id you can use to pull the debug dumps for that render
- A bundled knowledge base searched locally, with fallbacks to the official Kirby docs and the plugin directory when it is not enough
- Kirby CLI commands run behind an allowlist, plus runtime install and status checks
- IDE helper generation and a status report on missing type hints
- Query-language evaluation and PHP evaluation, both gated - evaluation is off by default
A composer-based Kirby project - other setups are out of scope, because much of this runs through the Kirby CLI. Add the package as a dev dependency, run the install command, and start it from the project root. There is also a projectless global reference mode for docs research, which deliberately cannot inspect or change any project. The current inventory is 37 tools, 15 resources, 15 resource templates and 216 knowledge-base articles. HTTP transport is off by default and must never be exposed without bearer-token authorisation.
One command — composer require bnomei/kirby-mcp --dev