shellwright

Safe Drupal tools for AI agents

Let agents work your Drupal sites. Not your database.

Shellwright is a curated, safety-first set of Drupal tools an AI agent reaches over MCP, Drush, or HTTP. Read-only by default. Guarded when it writes. It will never be a shell.

See what it does Why not a shell

The problem

Today it is all or nothing. To let an agent touch a Drupal site, you hand it a shell: full read, full write, full destroy.

The only thing standing between "check the site" and "drop the database" is a human watching prompts. That does not scale to automation, and it is not safe to point at production.

What it does

A narrow window onto a Drupal site, not the vault door.

Every capability is a bounded tool with a stable, machine-readable contract. Same answer over MCP, Drush, or HTTP.

Inspect

A read-only site audit

Eight checks, one JSON contract, safe to run against production because nothing can write.

  • Security updates and insecure releases
  • Cron health, system requirements, queues
  • Deprecated code and upgrade readiness
  • Filesystem hardening and orphaned config
Operate a fleet

Every site, one report

Roll up the health and security of a whole estate over HTTPS, with a scoped token and no shell on any site.

  • Worst-first summary, JSON, or an HTML report
  • A CI-friendly exit code to gate deploys
  • Keyed to each site's own identity
Change, within rails

Guarded write operations

Opt-in, CLI-only operations that an agent can run only through a gateway that enforces every guard.

  • Clear caches, enable modules
  • Import config through config sync
  • Dry-run first, always
Connect

MCP-native

Any MCP client calls the tools as first-class functions, no glue code. Drush and HTTP are there too.

  • Works with Claude, Cursor, agent workspaces
  • Extensible: contrib modules add bounded tools
  • One contract behind every transport

The guards

An agent can change your site, only within rails you set.

Writes never run except through the gateway, which enforces this order and stops at the first failure.

01
Plan first
Every operation produces a dry-run diff. You see exactly what would change before anything does.
02
Confirm
No apply proceeds without an explicit confirmation. Silence is a no.
03
Match the environment
The caller must name the environment, and it must match the site. Production is default-deny.
04
Opt in to destructive
Anything that can delete refuses to run unless the caller explicitly opts in.
05
Route through config sync
Config changes go through the sync workflow, never poked straight into a live database.

The line

What Shellwright will never do.

A product is defined by its refusals. This is the one that competitors and a plain shell cannot copy.

It will never expose a shell, even over MCP.

  • no a run-arbitrary-command tool
  • no a raw SQL tool
  • no a way around the audit's read-only contract or the write gateway's guards

A generic Drupal MCP could hand out all of these. Shellwright refuses. That refusal is what makes it safe to point at a production site, and it is the product.

How it connects

One contract, four ways in.

MCP client Drush HTTP + scoped token Fleet CLI
# inspect one site, machine-readable $ drush shellwright:audit --format=json # roll up an estate, gate CI on the exit code $ php fleet/shellwright-fleet.php --summary sources.json [CRITICAL] shop.example (prod) crit 1, warn 2 [OK] blog.example (stage) crit 0, warn 0 # change something, only within the rails $ drush shellwright:op-apply config_import --environment=stage --destructive