Analyze a Drupal 7 site for D10 upgrade readiness.

Analyze a Drupal 9+ site for deprecated code and APIs.

List all content types on a Drupal site.

List all modules on a Drupal site.

Map Drupal 7 modules to D10 equivalents using AI + known mappings.

Scan custom modules for deprecated Drupal APIs.

Find which bundles use reference fields targeting an entity type.

Answers "where are these used?" at the configuration level: for entity_type ("taxonomy_term", "node", "media", ...) it lists every field on every bundle whose storage targets that type, e.g. which content types have a tags or category field. Filter by the referencing bundle or by field_name.

This reads field configuration, not content: it reports where references can live, not which individual rows currently point at which entity. For the data, query the field's table with db_query.

Case-insensitive substring search across entity titles and names.

Scans node titles, user names and emails, taxonomy term names, comment subjects, media names, and file names with one read-only LIKE query per type, returning matches grouped by entity type.

Pass entity_types (e.g. ["node", "taxonomy_term"]) to search fewer tables: a LIKE scan reads every row, so keep it narrow on large sites. This does not search node bodies -- for full text use the site's own search or the search_api tools.

Resolve a URL path or alias ("/about", "/node/123") to its entity.

Internal routes such as /node/123 are read directly. Anything else is looked up in the path alias table, and the resolved target is parsed the same way. A full URL is accepted; the query string and fragment are ignored. Returns the entity id and a short summary, or found: false when nothing resolves.

Generate migration YAML configuration.

Generate migration module for a custom module with source plugin, process plugins, and migration template.

Test migration with limited records.

Validate migration configuration.

Rollback a completed migration.

Sync media files between paths.

Migrate taxonomy vocabularies and their terms.

Create or replace a persisted migration plan.

Read a persisted migration plan and its tracked state.

List all persisted migration plans.

Summarize migration progress for a persisted plan.

Copy a batch of source records into the target Drupal site through JSON:API.

Record the outcome of a manually executed migration operation.

Analyze a source Drupal JSON:API resource type and optionally store counts in a plan.

username/password authenticate to the source site: JSON:API field access hides attributes (user name/mail, for example) from anonymous requests, so unauthenticated analysis under-reports.

Compare recorded source counts with current target-site counts.

Fetch and migrate one resource type from the plan's source site into the target site.

source_username/source_password authenticate to the source site. Credentials may instead be stored in the plan's source block (username/password), which keeps waves self-contained.

Run an ordered end-to-end migration for one or all planned entity types.

Waves run in the order given (dependencies first). A failed wave stops the run by default, since a schema or auth problem tends to repeat; set continue_on_error to attempt the remaining types anyway.

Create a single node of the specified bundle with given fields.

Get a single node by ID with optional relationship includes.

Update a single node by ID with given fields.

Delete a single node by ID.

Query nodes with filters, sorts, includes, and pagination.

Upload a file to the media library.

Create media entity from a remote URL (image, video, document, etc.).

Clean duplicate or malformed nodes using AI. Requires confirm=True to execute deletions.

Suggest AI-powered field mappings from a source field list to a target bundle.

Reads the target bundle's available fields, then asks the AI provider to map each source field onto the closest target field.

Apply the same field updates to every node matching a set of filters.

Find broken media references across a content type.

Scans nodes of the given type and checks every media relationship, reporting references whose target media entity no longer resolves.

Regenerate URL aliases for a content type.

Alias generation belongs to the Pathauto module, so this runs drush pathauto:generate. The previous implementation ran drush uuri, which is not a Drush command. pattern is not applied here: patterns are pathauto_pattern config objects, which pathauto_pattern_create / pathauto_pattern_update manage.

Analyze content quality with AI for specific nodes or an entire type.

Generate sample nodes for a bundle to populate a development site.

Get a single configuration object by name.

Set a single configuration value.

Export Drupal configuration to files.

Import Drupal configuration from files.

Sync configuration between environments via Drush.

Show differences in configuration between environments.

Split configuration into separate directories for atomic deployment.

Reads from source_dir (exported config) and creates individual config files in output_dir for each specified config object.

Compare active configuration with the exported sync directory.

Read-only: reports how many config objects are the same, differ, exist only in the database (never exported, or changed since), or exist only in the sync directory, with the differing names. This is what drush config:import would act on; nothing is exported, imported, or written here.

An empty sync directory shows everything as "Only in DB" -- export first with drush config:export (or the export_config tool) before expecting a useful comparison.

Execute any Drush command.

options values are rendered as drush expects them. Drush flags take no value, so {"yes": True} must become --yes and not --yes=True, which drush rejects with "The --yes option does not accept a value". That made every confirmation-answering call fail -- including pm:install, so installing a module reported success while nothing was installed. A False means the caller does not want the flag, so it is omitted rather than spelled --yes=False; that direction was the dangerous one, because it used to pass --yes and silently suppress confirmation on destructive commands.

Generate .ddev/config.yaml for a local Drupal environment.

Refuses to overwrite an existing config: calling this with defaults on a working project used to replace the whole file with name: ., which takes the project down.

Start DDEV project.

Stop DDEV project.

Execute command in DDEV container.

Start Lando project.

Stop Lando project.

Execute command in Lando container.

Generate .lando.yml for a local Drupal environment.

Deploy to Acquia Cloud via acquia-cli or Drush acquia integration.

Supports both acquia-cli (preferred) and legacy Drush acquia commands.

Create database backup via Drush.

Clear and rebuild all Drupal caches via Drush.

Run composer install.

Require one or more packages via composer.

Several packages may be given at once, space separated, the way composer require itself accepts them. They used to arrive as a single argv token, so composer read "drupal/pathauto" as a version constraint on "drupal/token" and refused the command with "Could not parse version constraint" -- a confusing error for the ordinary request "install these two modules". A package name never contains a space, so the split is unambiguous.

Run composer update.

Run cron.

Show recent log entries from watchdog.

Clear specific cache bins.

Run database updates.

Execute arbitrary PHP code via Drush.

Analyze content quality using AI.

Suggest field mappings using AI.

Generate migration plan using AI.

Translate content using AI.

Create a taxonomy vocabulary.

Get a taxonomy vocabulary by ID.

Update a taxonomy vocabulary.

Delete a taxonomy vocabulary.

List all taxonomy vocabularies.

Create a taxonomy term in a vocabulary.

Get a taxonomy term by ID.

Update a taxonomy term.

Delete a taxonomy term.

List terms in a vocabulary with filters and pagination.

Create a user account.

Get a user by ID with optional relationship includes.

Get a user by email address.

Update a user account.

Delete a user account.

List users with filters and pagination.

Assign a role to a user.

Remove a role from a user.

List all available roles.

Get roles assigned to a user.

Block a user account.

Unblock a user account.

Execute a single read-only SELECT query on the Drupal database.

One statement only, no comments, and no write or file-access clauses.

List all database tables.

Get table schema information.

Count rows in a table.

List all views on a Drupal site.

Get a single view configuration by ID.

Create a new view.

Update an existing view.

Delete a view.

Execute a view and return its rows.

Runs the view through the Views API rather than guessing at a GraphQL schema. The graphql module ships no view(view_id:...) root field, so the query this used to send could never resolve, and the fallback asked JSON:API for views/{id}/{display}, which is not a resource either. Neither path was reachable, so the tool failed wherever Views was installed and healthy.

args are the view's contextual filters, in order. filters are set on the view's exposed input, which is what a visitor filling in the view's own filter form sets. A display that does not exist is reported along with the displays the view does have: ViewExecutable::setDisplay would otherwise fail later, with a message naming neither the view nor the display the caller asked for.

Export a view as configuration YAML or JSON.

List all paragraph types on a Drupal site.

Get a single paragraph type configuration by ID.

Create a new paragraph type.

Update an existing paragraph type.

Delete a paragraph type.

List paragraph items, optionally filtered by type.

A paragraph's type is its bundle, so filtering by type means addressing the paragraph--{type} collection. filter[paragraphs_type] does not exist -- it answered 400 "the field paragraphs_type does not exist" on every call, because there is no such field; the type lives in the resource type itself.

Get a single paragraph item by ID.

Create a new paragraph item of the specified type.

Update a paragraph item.

Delete a paragraph item.

List all menus on a Drupal site.

Get a single menu configuration by ID.

Create a new menu.

Update an existing menu.

Delete a menu.

List menu links, optionally filtered by menu.

Get a single menu link by ID.

Create a new menu link.

Update a menu link.

Delete a menu link.

List all field configurations on a Drupal site.

Get a single field configuration by ID.

Create a new field configuration.

Update a field configuration.

Delete a field configuration.

List all field storage configurations on a Drupal site.

Get a single field storage configuration by ID.

Create a new field storage configuration.

Update a field storage configuration.

Delete a field storage configuration.

List revisions for an entity.

Only the current revision is enumerable over JSON:API; the tool reports that honestly rather than inventing a collection URL.

Get a specific revision of an entity.

Revert an entity to a specific revision.

Applies the revision's field values to the current entity. A PATCH that Drupal rejects is atomic, so a failure leaves the entity untouched.

Delete a specific revision of an entity.

Diff two revisions of an entity.

List all redirects on a Drupal site.

Get a single redirect configuration by ID.

Create a new redirect.

Update an existing redirect.

Delete a redirect.

Create multiple redirects in bulk.

Delete multiple redirects in bulk.

Run cron.

List the jobs Drupal runs on cron, and when cron last ran.

In Drupal 8+ a "cron job" is a module implementing hook_cron; there is no job registry and no drupal_get_cron_jobs() - that Drupal 7 function is what this tool used to call, so it returned "Call to undefined function" on every site it has ever run against.

The implementations sit behind ModuleHandler::invokeAllWith(), whose callback is handed the listener without being forced to invoke it. Only $module is relied on: through Drupal 8-10 the callback receives ($function, $module, $arguments) and in Drupal 11 ($listener, $module), so the module is the second argument in every version, and never calling the first argument is what stops listing a job from running cron.

List all queues.

Run a specific queue.

Delete queue items: one by id, the oldest count, or the whole queue.

Drush's queue:delete takes exactly one argument - the queue name - so the item_id and count forms cannot go through it: they passed extra arguments that Drush refused with "Too many arguments", and all three branches failed, so this tool never once succeeded.

Even the plain case now runs in PHP rather than through Drush, because queue:delete only resolves queues that are registered as services and answers "Queue not found" for anything else - including a queue this very server just created with queue_create. Queue::deleteQueue() is what Drush calls internally, so the result is the same operation without Drush's registration requirement.

item_id deliberately repeats the queue name in its condition even though core's own DatabaseQueue::deleteItem() does not - that method deletes by item_id alone, so without the name a request for an item in one queue would happily delete a different queue's item that happened to share the id.

Get queue information.

Create a queue and make it ready to accept items.

class_name is refused rather than silently dropped. Drupal resolves a queue's implementation in settings.php - queue_service_<name>, else queue_default, else the queue.database service - and that service must already exist in the container, so no API accepts a class name when a queue is created. Accepting it would let a caller believe they had a custom queue implementation when they had the default one.

Run PHPStan static analysis on Drupal custom modules.

Run Drupal Check for deprecated code detection.

Run PHP_CodeSniffer with Drupal coding standards.

Scan for deprecated Drupal API usage.

Run security-focused static analysis.

Run Composer security audit on dependencies.

Run multiple code quality tools and generate combined report.

Rebuild the local codebase module index.

Call after installing, enabling or creating modules so the other codebase tools see the current state. Returns counts of indexed modules by type and the module directories that were scanned.

Search the local codebase for modules providing a capability.

Ranks exact machine-name/name matches above description matches, which rank above code-body matches (hooks, services, routes, classes). Use scope 'custom' or 'contrib' to filter by module origin; 'all' includes core.

List indexed local modules with metadata.

Each item carries machine name, human name, type (custom/contrib/ core), version, dependencies, path and description. With show_unused=True each item is flagged when nothing references it and it implements no hooks.

Describe one local module in full.

Returns the module's info.yml fields, dependencies, reverse dependencies, hooks, services, routes, classes and file count — everything the index knows about it.

List custom/contrib modules nothing references and that define no hooks.

A module counts as used when another module depends on it, when another module's services inject one of its services, or when it implements hooks itself. Candidates for removal.

Check whether the local codebase already covers a capability.

Searches the index and reports the closest existing modules plus a recommendation: extend what exists rather than duplicating it.

Find which local modules implement a hook, with file and line.

Accepts the hook with or without its 'hook_' prefix (both 'form_alter' and 'hook_form_alter' work). Implementations are reported per module with the file and line of the function.

Show the configured docroot and the module directories indexed.

Use this to verify which locations the codebase tools actually scan (modules, web/modules, sites/*/modules, core) before relying on search results.

List every file in a local module as module-relative paths.

Useful to find the right path before calling codebase_file_read or codebase_function_read.

Show a local module's directory structure as a nested tree.

Directories have children; files carry a size. The tree is depth and item capped to keep responses bounded.

Read one file from a local module.

path is module-relative (e.g. 'mymod.module'). Content is truncated at 64 KB with a truncated flag. Absolute paths, '..' traversal and symlinks escaping the codebase are rejected.

Extract a single PHP function (with its docblock) from a module.

Returns the file path, the line of the function and its code — enough to review one hook or method without reading whole files. Searches all PHP-ish files in the module, including class methods.

Run security-focused SAST using PHPStan with security extensions.

Scan dependencies for vulnerabilities using Composer audit and other tools.

Check Drupal configuration for security issues.

Audit user permissions and roles.

Scan for SQL injection vulnerabilities in custom code.

Scan for XSS vulnerabilities in custom code.

Content Security Policy audit.

Audit file permissions for security issues.

Scan custom code for vulnerability patterns — no tools to install.

Matches PHP/JS/Drupal files against a curated registry of XSS, SQL injection, command injection, path traversal, hardcoded secrets, access-control, CSRF, and deprecated-API patterns, with Drupal-aware false-positive rules (EntityQuery conditions, stream wrappers, escapeshellarg, and similar safe APIs are recognized). The counterpart of security_scan, which needs PHPStan installed.

Target one module by machine name, or a directory relative to DRUPAL_ROOT; with neither, the site's own modules/ and themes/ directories are scanned (contrib and core excluded). categories narrows to registry keys ('xss', 'sql_injection', 'command_injection', 'path_traversal', 'hardcoded_secrets', 'access_control', 'csrf', 'deprecated_api'); severity narrows to one level. Findings carry file, line, snippet, and a fix recommendation; counts cover the full run even when max_findings truncates the list.

Classify every route's access control from *.routing.yml files.

The routing half of a pre-deployment review: each route is classified by what it requires — fully anonymous (access: TRUE), a permission, roles, entity access, a custom access callback, or nothing at all, which is the finding. Controllers are mapped to the file that declares the class when it can be found, so a risky route leads straight to code. Targets work like code_security_scan: one module by machine name, a DRUPAL_ROOT directory, or the site's own modules/ and themes/ by default.

Run the site's status report (what /admin/reports/status shows).

Read-only. Returns each requirement with its title, severity ("error", "warning", "info", or "ok"), description, and value. By default errors and warnings are returned; use include_ok for the whole report or severity_filter for one level.

A failure here is usually the site's own requirements checker breaking, not this tool: the drush error is returned verbatim.

List pending database updates (read-only; runs nothing).

Answers "did the modules I just updated leave schema behind?". Use drush_command("updatedb") (or the drush_updb tool) to apply them, after a database backup.

List packages with newer versions available, from composer.

Read-only (composer outdated); needs the project's composer.json and network access. Packages are grouped into core, contrib, and other. Dev dependencies are excluded unless include_dev is set -- filtered via composer.json's require-dev, because composer marks none of them itself.

With security_only, the outdated list is cross-referenced against composer audit: only packages that are both outdated and covered by a security advisory are returned, with the advisories attached. (The composer_audit tool lists advisories regardless of updates.)

Check that this server can actually reach a working Drupal site.

Runs four read-only probes: Drush and the site status, the database connection, the JSON:API index, and the modules the other tools assume (jsonapi required; dblog and basic_auth recommended). Each failure comes with the concrete fix. Run this first when other tools return opaque connection errors.

Search Drupal.org for modules by name or description.

Get module details from Drupal.org by machine name.

Get all available releases for a module.

Get the packages a module release requires.

Read from Composer metadata on packages.drupal.org, which is where Drupal publishes dependency data today. Omit version for the newest release.

Search Drupal.org for themes by name or description.

Get theme details from Drupal.org by machine name.

Get release history for a project.

Get download/usage statistics for a project.

Check whether a project has releases for a given core version.

Search a module's drupal.org issue queue for issues that match a problem.

Describes the problem (e.g. "Azure AD attribute mapping fails") and the most recently updated issues are scored on keyword overlap with their titles and bodies; the best matches come back first, each with a link. Set drupal_version (e.g. "10") to hide issues filed against other major versions; when unset it is detected from DRUPAL_ROOT if configured.

List the most-installed modules on Drupal.org, newest usage first.

Optionally filter by a drupal.org category such as "E-commerce", "Security", "SEO", or "Media" (case-insensitive, substrings work). Usage is summed across every release line, so a module's full install base shows up in one number. Categories are listed in the error if the name does not match one.

Recommend modules for a need: what the local codebase already ships, plus drupal.org options.

Combines the local codebase index (available when DRUPAL_ROOT is set) with drupal.org search, so the answer starts with modules you already have before suggesting downloads.

List all moderation states.

Get a single moderation state by ID.

Create a new moderation state.

Update a moderation state.

Delete a moderation state.

List a workflow's moderation transitions.

Transitions are configuration inside the workflow entity, not entities of their own, so there is no workflow_transition resource for JSON:API to list. They are read from the workflow's workflow-type plugin (WorkflowTypeInterface::getTransitions()), which is where Drupal keeps them.

Every workflow is read when workflow_id is left out. Naming a workflow that does not exist answers an error listing the ones this site has, rather than an empty list that reads as "no transitions".

Get a single moderation transition by ID.

Transitions belong to a workflow rather than being entities, so this searches every workflow's transitions for the named one. Pass include=states to attach the states of the workflow that owns it -- transitions have no JSON:API relationships to include.

Create a new moderation transition on a workflow.

Transitions are configuration inside the workflow entity, so they cannot be POSTed as a JSON:API resource. This adds one the way Drupal's own transition form does: through WorkflowTypeInterface::addTransition() and a save of the workflow, which writes the change back into the workflow's configuration.

Both the origin states and the target state must already exist in the workflow; an error names the ones that do not and lists the states the workflow does have. weight defaults to 0, which places the transition first -- pass a higher number to append it.

Delete a moderation transition from a workflow.

The counterpart of moderation_transition_create: a transition is configuration inside its workflow, so this removes it through WorkflowTypeInterface::deleteTransition() and saves the workflow, exactly as Drupal's own delete form does. The reply reports how many transitions the workflow has left, and warns when that was the last one -- a workflow with no transitions cannot move content at all.

Execute a moderation transition on an entity.

Looks the transition up on its workflow and applies its target state to the entity, refusing when the entity's current state is not one the transition starts from. The old version fetched the transition through JSON:API, which has no such resource, so this never ran.

Get content pending moderation - dashboard view.

List all workflows.

Get a single workflow by ID.

Create a new Drupal module with full scaffolding.

Create a service definition with PHP class stub.

Create a plugin (block, field, views, etc.) with proper scaffolding.

Create a form class (ConfigForm, ConfirmForm, FormBase, etc.) with proper scaffolding.

Create a controller class with routing.

Create an event subscriber service with getSubscribedEvents method.

Implement a hook in an existing module.

Generate .info.yml from existing module code (reverse engineering).

Create or update permissions.yml with custom permissions.

Create or update config schema YAML for module settings.

Create a PHPUnit/Kernel test skeleton.

Analyze module code and suggest missing dependencies.

Create a new Drupal theme with full scaffolding.

Create or update a theme library.

Add a region to theme.

Create a template override in theme.

Add a preprocess function to theme.

Add a breakpoint to theme.

Change the base theme.

Generate theme settings form.

Configure theme asset optimization.

Enable theme debugging (Twig debug, etc.).

Lint Twig templates in theme.

List all blocks.

Get a single block by ID.

Create a new block.

Update a block.

Delete a block.

Place a block in a region with weight.

Report which entity view displays have Layout Builder enabled.

Layouts themselves are not readable over JSON:API (see the other layout_builder_* tools), but the display config that switches Layout Builder on for a bundle is, so this returns that instead of a 404.

Read the Layout Builder layout for an entity type and bundle.

Returns whether Layout Builder is enabled and overridable for the bundle, plus every section with its layout plugin, region and components. This reads the real view display rather than the JSON:API resource that does not exist.

Replace the Layout Builder layout for a bundle.

layout may be a list of section specs, {"sections": [...]}, or a single {"layout_id": ..., "components": [...]}. Layout Builder is switched on if it was off. lock marks each component as locked against per-entity editing; Layout Builder has no display-level lock, so this is a component lock.

Update the Layout Builder layout for a bundle.

With layout given it replaces every section, exactly like layout_builder_create. With layout omitted it only applies lock, or just reports the current state when both are omitted.

List the sections in a bundle's Layout Builder layout.

Each section reports its layout plugin, and the components in it report region, plugin id and weight.

Append a section to a bundle's Layout Builder layout.

section takes layout_id (default layout_onecol) and components, which may be plugin ids or objects with plugin, region and configuration. Layout Builder is switched on if it was off. Returns the full section list afterwards.

List available block plugins.

List available regions for a theme.

Remove a Layout Builder override so an entity falls back to the default.

Pass entity_id (for a node, its nid) to revert that one entity. Omit it to list the entities of this bundle that currently carry an override, which is what you need before you can pick one.

Reverting clears the entity's layout_builder__layout field through OverridesSectionStorage, which is where Drupal keeps overrides - they are not config and cannot be read from entity_view_display.

List all Search API servers.

Get a single Search API server by ID.

Create a new Search API server.

List Search API indexes.

Get a single Search API index by ID.

Create a new Search API index.

Update a Search API index.

Trigger reindexing of a Search API index.

Clear a Search API index.

Enable a Search API server.

Disable a Search API server.

List Search API facets.

index_id is no longer applied. A facet is attached to a facet source, not to the index, and the only field it carries is facet_source_id -- so filter[index] answered 400 "the field index does not exist" on every call, and there is no field to filter on instead. Each returned facet carries its facet_source_id, which is what a caller needs to match facets to an index.

Create a Search API facet.

List all languages.

Get a single language by langcode.

Add a new language.

Enable a language.

Disable a language.

Delete a language.

Enable content translation for entity type/bundle.

Get translation status for an entity.

Add translation for an entity.

Update translation for an entity.

List the interface translations Drupal holds.

Locale does not store translations as entities, so there is no interface_translation resource to page through: they live in Locale's own storage, joined from each source string to its translation in a language -- which is where drush locale:export reads them from too.

langcode narrows the list to one language; left out, every language is listed and each row says which one it is. filters accepts search (a substring of the source text) and context (the source context, matched exactly). Only translated strings are returned: an untranslated source is not a translation. count is the total that matched, before paging.

Add an interface translation for one source string.

Written through Locale's own string storage -- createString() / createTranslation() plus save() -- which is what locale:import does with a .po file, one entry at a time. There is no locale:translate:* command to run instead.

If the source string is not one Drupal has already collected, it is created too and the reply says so: a translation nobody will ever look up is worth knowing about. The locale lookup cache is invalidated, so the new text is visible without a cache rebuild.

Change an existing interface translation.

Same storage as interface_translation_add, but this one refuses to invent anything: an unknown source string, or a source with no translation in langcode, is an error that says which of those it is and points at interface_translation_add. The string is marked customized so a later locale:import does not overwrite it.

Remove an interface translation from one language.

Drops the row from locales_target for this source and language; the source string itself stays, because it is Drupal's own string and other languages still use it. There is no locale:translate:delete command, and re-importing a .po file without the entry is no longer the only way to do this.

List the config objects that support translation.

There is no config_translation resource in JSON:API, because Drupal does not store config translations as entities: a translation belongs to the config object that declares a translation mapping. Asking JSON:API for a resource that cannot exist returned a 404 that read exactly like a missing module, so the tool looked uninstalled rather than wrong.

Each mapping is returned with the entity type it translates. The mapping's own config-name list is empty until Drupal builds it inside the translation form, so it is not reported here -- the id and the entity type are what config_translation_add needs.

Translate a config entity.

config_name is {entity_type}/{entity_id}, for example node_type/article. config_translation_list shows which entity types this site can translate. translation is a flat map of property to translated value.

A config entity is not a translatable entity. There is no TranslatableInterface to call, no addTranslation(), and no config:translation:add Drush command -- which is what this tool tried, twice, both failing every time. Drupal keeps a config translation as a language config override: the same config object, overridden per language. So the entity type is resolved through the config translation mapper to the config object it is stored as, and that object's override for the target language is what gets written.

Get language negotiation configuration.

Set language negotiation method.

List all media types.

Get a single media type by ID.

Create a new media type.

Create media from URL (oEmbed).

Create media from base64 encoded file data.

Generate a specific derivative for media.

Bulk import media files from directory.

List media library items.

List pathauto patterns.

A pattern's target entity type and bundle are encoded in its id, as {entity_type}--{bundle}, rather than held in fields of their own. filter[entity_type] and filter[bundle] therefore answered 400 "the field ... does not exist" on every call. Both are needed to filter server-side; with only one there is no field to match on, so every pattern is returned and the caller narrows from the ids.

Get a single pathauto pattern by ID.

Create a new pathauto pattern.

Update a pathauto pattern.

Delete a pathauto pattern.

Generate pathauto aliases.

List available pathauto tokens.

List redirect patterns.

List all metatag configurations.

Get a single metatag configuration by ID.

Create a new metatag configuration.

Update a metatag configuration.

Get default metatag values for entity type/bundle.

Set default metatag values for entity type/bundle.

List available metatag tokens.

Set canonical URL for an entity.

Generate JSON-LD structured data for entity.

List all commerce stores.

Get a single commerce store by ID.

Create a new commerce store.

Update a commerce store.

List commerce products.

Get a single commerce product by ID.

Create a new commerce product.

Update a commerce product.

List commerce orders.

Get a single commerce order by ID.

Create a new commerce order.

Update a commerce order.

List payment gateways.

Get a single payment gateway by ID.

List commerce promotions.

Create a new commerce promotion.

List shipping methods.

Create a new shipping method.

List all webforms.

Get a single webform by ID.

Create a new webform.

Update a webform.

Delete a webform.

List webform submissions.

Get a single webform submission by ID.

Delete a webform submission.

List elements in a webform.

Add an element to a webform.

List the handlers attached to a webform.

Handlers are plugins configured on the webform, not entities, so there is no webform_handler resource for JSON:API to list. This reads them off the webform instead, which is where they live.

Create a webform handler (email, remote post, etc.).

A handler is a plugin held inside the webform's own configuration -- there is no webform_handler entity and JSON:API cannot POST one. This builds the plugin through plugin.manager.webform.handler and attaches it with Webform::addWebformHandler(), which is the same sequence Webform's own add-handler form runs.

id is the handler's id within the webform (email_confirmation, not email); handler_type is the plugin (email, webhook, auto_save, ...). configuration supplies plugin settings, which are merged over the plugin's defaults -- the reply echoes the whole resulting configuration so you can see what the defaults filled in.

Update a webform handler.

Handlers have no entity id of their own, so this finds the webform that owns handler_id and writes back through Webform::updateWebformHandler(). Pass webform_id to skip the search; without it, a handler id used by more than one webform is an error naming them rather than a guess.

configuration keys are replaced as a whole and keys you leave out keep their current value, so you can change one setting without resending the rest.

Delete a webform handler from its webform.

Removes it the way Webform's own delete form does -- through Webform::deleteWebformHandler(), which also runs the plugin's teardown. The webform's other handlers are left alone.

List available webform tokens.

Export webform submissions.

Get JSON:API schema (OpenAPI/Swagger).

Get optimized include paths for entity type.

Get entity with sparse fieldsets (only requested fields).

Get GraphQL schema.

Execute a GraphQL query.

Extend GraphQL schema with custom fields (requires schema customization module).

Generate Next.js helper functions for Drupal entities.

Generate Gatsby source plugin config and helpers.

List all available JSON:API resources.

Get all resource types available in JSON:API.

Run PHPUnit tests.

Run Kernel tests.

Run Behat tests.

Run Nightwatch tests.

Scaffold a PHPUnit test class.

Scaffold a Behat feature file.

Scaffold a Nightwatch test.

Generate test coverage report.

List available test suites.

Run axe-core accessibility scan on a URL.

Check WCAG compliance for entity content.

Check color contrast ratio.

Pure arithmetic: it deliberately does not touch the site, so it works without Drush configured.

Validate ARIA attributes on entity.

Generate comprehensive accessibility report.

Get slow query log.

Get cache performance statistics.

Get Redis server info.

Check BigPipe status and configuration.

Enable or disable BigPipe.

Get Memcached statistics.

Analyze page load performance.

List all contact forms.

Get a single contact form by ID.

Create a new contact form.

Update a contact form.

Delete a contact form.

List contact form submissions.

Get a single contact message by ID.

Delete a contact message.

Check if a contact message is spam.

List comments.

Get a single comment by ID.

Create a new comment.

Update a comment.

Delete a comment.

List comment thread for an entity.

Returns the whole thread, replies included. It used to add filter[pid] = 0 to get top-level comments only, but pid is an entity reference to the parent comment, so JSON:API rejected it with "must end with one of the following specifiers" -- and had it accepted pid.id = 0 it would have matched nothing, since no comment has id 0. Each row carries its own pid, which is what a caller needs to build the tree.

Approve a comment (set status to published).

Unapprove a comment (set status to unpublished).

Get comment field settings for entity type/bundle.

Configure comment field settings.

List all feeds.

Get a single feed by ID.

Create a new feed.

Update a feed.

Delete a feed.

Run a feed import.

Get feed import status.

List feed import logs.

Superseded by feeds_import_status, which reports the outcome of the current import. Feeds 3.x removed the log entity, so there is nothing of this shape to list on any site.

List tamper plugins for a feed.

List available feed parsers.

List available feed fetchers.

List available feed processors.

Export a node inventory to a CSV or Excel file on disk.

Writes one row per node (id, type, title, status, dates, author, path) and returns only the file path and statistics, so a 5,000-node audit never has to travel through the conversation. The data comes from JSON:API, so titles and bodies with newlines or accents survive intact.

content_type limits the export to one bundle (for example "article"); unpublished nodes are left out unless asked for. With include_fields a final fields column carries the node's remaining field values as JSON, each string capped at 5000 characters. limit caps the rows written (0 = no cap, 100000 maximum). format is "csv" (UTF-8 with BOM, opens cleanly in Excel) or "xlsx". The file may be written only inside the Drupal root, the system temp directory, or your home directory; without output_path it lands in {Drupal root}/exports/ or /tmp/drupal-mcp-exports/ with a timestamped name.

Export the site's user accounts to a CSV or Excel file on disk.

One row per user: id, name, email, active/blocked status, role labels, registration/last-login dates. Blocked accounts are always included (their status column says so) - an audit needs them. The file lands in {Drupal root}/exports/ or /tmp/drupal-mcp-exports/ unless output_path says otherwise (confined to the Drupal root, the temp directory, or your home). Drupal's uid-0 anonymous pseudo-account carries no id attributes and is skipped rather than exported as a row of nulls (see skipped_without_id).

Export the media library to a CSV or Excel file on disk.

One row per media item: id, bundle, name, status, dates, owner, and the managed file's filename and URI when there is one (found through relationships, so renamed file fields still work). media_type limits the export to a bundle such as "image". Empty sites write nothing and say so.

Export taxonomy terms to a CSV or Excel file on disk.

One row per term: id, vocabulary, name, description, weight, status, and - with include_usage (the default) - how many entities reference the term, through which fields, and a safe_to_delete verdict ("yes" only when nothing references it, and withheld entirely whenever some field could not be counted). Usage comes from one COUNT query per field storage targeting taxonomy terms, so a 5,000-term vocabulary costs a handful of queries, not 5,000.

vocabulary limits the export to one vocabulary machine name (for example "tags"). When Drush is unavailable the export still succeeds and says the usage columns are empty.

List the site's themes: default, admin, and every enabled one.

Reads system.theme and drush pm:list; returns the default and admin theme machine names plus each enabled theme's package, path, and version, with counts of the disabled ones.

Describe one theme: metadata, base-theme chain, regions, libraries.

Combines drush pm:list (status, version, path) with a YAML parse of the theme's own .info.yml (description, regions in declaration order, libraries, dependencies) and follows the base theme chain upward as far as the site allows. Requires DRUPAL_ROOT: the info.yml lives on the local docroot.

Region layout of a theme with the blocks placed in each one.

Regions come from the theme's info.yml in declaration order; each carries its blocks (label, plugin, weight, enabled state) and a count, so empty regions and placements in regions the theme no longer defines are both visible at a glance. Needs DRUPAL_ROOT (info.yml) and the JSON:API client (block placements).

List placed blocks with optional theme, region, and text filters.

Reads every block.block.* placement from JSON:API: id, theme, region, label, plugin, weight, and enabled state. search matches label and plugin case-insensitively (the "do we have a block like Site branding?" question); theme_name and region narrow the list to one placement set. With no filters every placement on the site is returned, most specific sort first (theme, region, weight).

List a theme's Twig templates (*.html.twig) with sizes.

Walks the theme directory on the local docroot (symlinks skipped, nothing outside DRUPAL_ROOT reported). pattern is a case-insensitive substring matched against the template name — "node--", "views", "field" — to narrow the list. Returns docroot-relative paths and byte sizes, sorted.

Which core/module templates a theme overrides, and which it invented.

For every Twig file in the theme, the docroot is indexed once for files with the same name outside that theme; a match means the theme's copy wins at render time (an override), no match means a theme-original template. Returns both lists with paths, plus how many Twig files were scanned. Requires DRUPAL_ROOT.

Twig template names Drupal will try for an entity, specific first.

The suggestion chain for node, block, taxonomy_term, user, field, or page rendering (bracketed parts are placeholders Drupal fills in, e.g. node--article--123.html.twig beats node--article.html.twig). Unknown entity types get the generic chain. When DRUPAL_ROOT is configured each suggestion is marked in_checked_theme: whether the default theme already ships that file, so you know which name creating one would actually take effect.

Template names for overriding a Views display, verified against the site.

Looks the view up in the JSON:API view collection by its machine id (drupal_internal__id), so the display list is real: with display_id the chain starts at views-view--NAME--DISPLAY and falls back to the whole view; without it every display gets an entry, then the views-view base template. An unknown view errors with the views the site has, an unknown display_id with the displays that view has, and suggestions are marked in_checked_theme when the default theme's templates can be read (DRUPAL_ROOT). Views config changed names between Drupal generations (view.* on older sites, views.view.* on Drupal 11.4+), so the collection — addressed by entity id — is the stable source.