Agent-first documentation for every Drupal 11 compatible contrib module: what each module is for, how to judge it, and how to configure and extend it, written so a coding agent can use a module without reading its source.
- 8,794 Drupal 11 compatible projects, 10,607 modules including submodules
- 24,000+ agent docs, generated by installing each module on a real Drupal 11 site and reading its code and config
- Kept current: scanners watch the drupal.org release feeds and re-document new stable minors
Browse it: https://drupal-ai.github.io/agent-module-documentation/
The easiest way is the DDEV add-on, which runs a local MCP server with hybrid (lexical and semantic) search over this repository:
ddev add-on get Drupal-AI/ddev-drupal-agent-module-knowledge-mcp
ddev restart
claude mcp add --transport http agent-module-docs http://<project>.ddev.site:9130/mcpSee ddev-drupal-agent-module-knowledge-mcp
for details. You can also point an agent straight at the files in modules/.
Modules are bucketed by the first two letters of their machine name, one directory per
major.minor.x release line. Submodules nest under their parent:
modules/to/token/1.17.x/
├── data.json # metadata: versions, installs, maintenance and security-advisory status,
│ # categories, keywords, dependencies, shipped tool plugins and agent skills
├── usage.md # short summary · long, honest summary · 15–30 use cases in plain words
└── agent/
├── start.md # token-cheap index: key facts and links to the docs below
└── {configure,api,plugins,drush,hooks,…}/*.md
- Finding a module:
usage.mduse cases and thedata.jsoncategories and keywords. - Evaluating it: maintenance, development and security-advisory status, installs, and the trade-offs in the long summary.
- Using it:
agent/start.mdplus the solution docs. Every agent doc must be shorter than reading the equivalent source.
Some popular modules also have eval/evals.json (easy, medium and hard tasks, verified against a
live site) and a human-facing human-docs/ folder.
| Path | What |
|---|---|
modules/ |
The documentation, one directory per module version |
unsupported_modules/ |
Modules moved out because drupal.org no longer lists them as supported |
categories.yml |
The category and subcategory taxonomy |
AGENTS.md |
The specification the documenting agents follow |
documentation/ |
Method details: data source, file formats, workflow, screenshots |
scripts/ |
Campaign, install, release-scan and validation helpers |
evaluation/ |
The eval harness (vanilla vs. docs, live-site verification) |
site/ |
The catalog and eval dashboard published to GitHub Pages |
Each module is installed on a Drupal 11 site in DDEV, its code and config are read, and the
docs are written to the spec in AGENTS.md. The step-by-step method is in
documentation/, and the eval method and results format in
evaluation/README.md.
Corrections and new modules are welcome as issues or pull requests. Please follow the formats
in documentation/file-formats.md.
Security: if you find a security issue in a Drupal module, don't open a public issue or put it in these docs. Report it to the Drupal Security Team.
The repository (README, scripts, site, evaluation harness and structure) is licensed under the MIT License.
The per-module documentation is the exception. Each file under modules/ starts with an
SPDX header, an invisible first-line comment such as
<!-- SPDX-License-Identifier: GPL-2.0-or-later -->, naming the license of the module it
documents, because these docs summarise and quote that module's code and configuration. For
almost all modules that is GPL-2.0-or-later. Text taken from drupal.org (such as
project_description in data.json) stays under its original terms.