For Drupal teams using Claude Code, Cursor and Codex
Droost gives an AI coding agent first-hand knowledge of your Drupal site, its modules, entity model, routes, services, configuration and code, and a workflow that takes every change through plan → code → test → complete.
$ composer require --dev 'drupal/droost:^2.0@alpha' \
'drupal/mcp_server:^2.0@alpha'
$ drush en droost -y # wires .mcp.json, AGENTS.md, CLAUDE.md
$ drush droost:install # the toolset: knowledge of this site
$ drush droost:workflow:install # the workflow: plan → code → test → completeThe problem
The answer
Droost, the module
65 MCP tools in three profiles, all answering from this site. The read side is ungated; the build side is a small set of tools that return the read-back of what they wrote.
Versions, installed modules, entity types with bundles and fields, routes with controllers and access, services with the interface to type-hint, permissions and roles, config with sensitive keys redacted.
droost_app_info · droost_entities · droost_routes · droost_services · droost_config_get
Recent log entries and the last error, pending updates, queue and cache-bin contents, live hook implementors, event listeners, profiled requests with their slowest queries.
droost_logs · droost_last_error · droost_runtime_inspect · droost_profile
Semantic and lexical search over core, contrib and custom code, plus edges: which class backs a service, who injects it, which route maps to which controller, which hook fires where. Rebuilt incrementally, only what changed.
droost_search · droost_module_patterns · droost_capabilities
Curated guideline topics that branch on the running core major, module docs and API files, and an offline deprecation ledger: deprecated in X, removed in Y, use Z, with the change record.
droost_guidelines · droost_module_docs · droost_deprecations
Shipped decision graphs, walked server-side against this site's blueprints and its live drush generate list. The answer is the exact command, never "write the YAML by hand".
droost_decide
Green-by-default scaffolds with a test, fields and bundles and view modes, deterministic display and Views composers validated by Drupal before saving, and a verify loop that runs phpcs and phpstan with structured findings. Each write returns what it actually wrote.
droost_scaffold · droost_structure_create · droost_views_compose · droost_display_compose · droost_verify
Droost Workflow
A framework-free PHP library the agent runs each build through. Each phase has an exit gate; pass and the run advances, fail and it enters a bounded fix loop. The whole run is a record on disk, so it can be resumed, inspected and reported without trusting anyone's summary.
A researcher agent finds out what the site actually has before the spec claims anything. A spec-writer drafts the spec in EARS form from the conversation and those findings. Before the run may enter code, the spec carries a Tooling plan: one router answer per construct, so the build is decided before it starts.
## Tooling plan
event bundle → droost_structure_create kind=bundle
event listing → droost_views_compose (page + block)
permissions.yml → drush generate yml:permissionsThe agent builds through the surfaces the plan named. The diff is held by the static gates Drupal core develops with, and by config_clean: a fresh config export must change nothing, because a hand-written file that imports fine can still diverge from Drupal's canonical serialization. A seeker inspects the diff before the phase closes.
phpcs passed Drupal, DrupalPractice
phpstan passed level 6 · 0 errors
config_clean passed export diff: 0 filesPHPUnit runs the suite. rendered_check makes a real request to the routes the change touches and reads the status. With a browser declared, the agent drives Playwright against the running site and the run records what it saw. Artifacts are truth; a test that could not run is reported as such, never as a pass.
phpunit passed 3 tests, 9 assertions
rendered_check passed /events → 200
playwright passed events.spec: 2 passedDocument, then close. The record captures what was actually built, the project's wiki page is written with provenance Droost composes from the code, and wiki_fresh asks the site whether the docs still match. Every gate re-runs as the terminal safety net, the seeker reviews once more, and the run is archived.
## Realized event bundle, 4 fields, /events page + block, 3 tests
wiki_fresh passed droost/wiki/events.md verified @ 3f9c2e1
seeker Inspector: (no findings) → run completeThe ecosystem
The module is what an agent knows. The workflow is how it works. Droost CMS is the two of them, plus a theme, installed as one recipe on Drupal CMS.
The knowledge and the tools. Introspection that answers from the real site, search over its code, guidelines and deprecations for its core version, a router that names the surface for a build, and the composers and scaffolds that build through it.
· 65 tools, three profiles, read-only by default
· a knowledge brain that rebuilds only what changed
· wires Claude Code, Cursor and Codex on drush en
The process. Plan → code → test → complete with phase gates from one lever file, a seeker whose ledger the engine parses rather than trusts, and a run record on disk. The same pipeline runs against a live site or from a plain checkout with no site at all.
· phpcs, phpstan, phpunit are mandatory, never levers
· config_clean: a fresh export must change nothing
· documentation is part of completing, not an afterthought
The reference install. Drupal CMS with Droost, the workflow, UI Patterns, Canvas and Droost Theme wired in one apply, plus a shipped design pattern showing entity fields rendered through components. What droost.org itself runs on.
Includes Droost Theme
Tailwind v4 + daisyUI, design tokens as one editable CSS file, a Canvas-clean component library, and a compiled production stylesheet so no site needs node to install it.
Evaluated against reality
A real ticket, a real agent, a clean-room site, an acceptance script written red-first. Every round and every defect it found is public.
Roadmap
The big pieces, in the order we intend to build them. Each lands with a live-agent eval ticket that exercises it, the same way everything shipped so far did. No dates until the evals say a piece is close.
Add it to a site you have, or start from Droost CMS.