What Droost is
An AI agent asked to write Drupal code is usually working blind. It does not know which modules and versions are installed, what entity types and fields exist, which services it should inject instead of calling \Drupal::, what the routes and permissions are, or whether the last request errored. It guesses, and guesses age badly as a project evolves.
Droost takes a different path. It exposes that information as explicit, schema-described tools that return structured JSON, gates every write behind a decision a human makes, and runs each change through a pipeline that verifies before anyone says "done".
The three pieces
| Piece | What it is | Where |
|---|---|---|
| Droost | A Drupal module: 65 Model Context Protocol (MCP) tools in three profiles. Introspection, semantic search, a decision router, and gated build tools. | drupal.org/project/droost |
| Droost Workflow | A framework-free PHP library: the plan → code → test → complete pipeline, its gates, the wall, the seeker. Runs with a live site or from a plain checkout. | github.com/Ignibyte/droost-workflow · Packagist droost/workflow |
| Droost CMS | A Drupal recipe layered on Drupal CMS that installs both, plus UI Patterns, Canvas and Droost Theme. The reference install. | drupal.org/project/droost_cms |
Droost Theme is part of the Droost CMS story rather than a fourth piece: an agent-first base theme (Tailwind v4 + daisyUI, tokens as CSS, a Canvas-clean component library) that the recipe installs as the site default. It has its own project page at drupal.org/project/droost_theme.
What the module knows
Droost answers from the site, not from training data:
- Structure. Entity types, bundles and fields; routes with their controllers and access requirements; services with the interface to type-hint and an injection snippet; permissions and role grants; config values with sensitive keys redacted.
- State. Installed modules with versions, pending updates, recent log entries and the last error, queue and cache-bin contents, live hook implementors.
- Code. A code graph of what the project already has (services, routes, hooks, plugins, who calls whom) and a semantic search over core, contrib and custom code plus the project's own wiki.
- Conventions. Curated guidelines topics that version-branch on the running core major, and an offline deprecation ledger that says "deprecated in X, removed in Y, use Z" for a core symbol.
What it lets an agent build, and how
Build tools exist, but each one sits behind an allow_* gate that is off until the operator arms it, and every refusal names the flag. Scaffolding from green-by-default blueprints, authoring fields and bundles and view modes, composing displays and views, setting config: all of it returns the read-back of what was actually written.
Routing is the module's job too. droost_decide walks shipped decision graphs server-side and answers "which surface builds this?" with the exact command, consulting gate state and this site's drush generate list live. Droost extends Drush; it never competes with it.
Why the workflow exists
Tools that can build are half of it. The other half is making sure the agent builds the way a good Drupal team would. The workflow is that discipline as software: a spec before code, static analysis and a clean-config check on the diff, tests and a real rendered request, an adversarial review whose findings the engine parses, and a wall that blocks custom-code edits when no run is active.
Local development only
Droost is a local-only toolkit, the same class as Devel. Install it with --dev, run it beside your editor, and do not deploy a site with Droost enabled.
Where to go next
- Install on an existing site: four commands.
- Install Droost CMS: the recipe path.
- Coming from 1.x: why there is no upgrade path, and what to do instead.