The nervous system for an entire WordPress estate.
SpiritMCP is the Model Context Protocol bridge that gives Claude, and every modern AI assistant, direct, audited control over a fleet of WordPress sites, VPSes, and the infrastructure between them. Built for developers and agencies who need their AI to act on production, not just talk about it.
Live
Other WordPress MCP servers stop at the REST API. SpiritMCP starts there.
The first generation of WordPress MCP servers wrap a handful of REST endpoints and call it done. Useful for reading posts. Useless for running a production estate. SpiritMCP was built from the opposite direction, start with the operations a real agency runs every day, then expose them as schema-typed tools an AI can call safely.
Public · REST wrapper
Read-only thinking.
Self-hosted · agency-grade
Estate-wide control.
Built for the operations a real agency runs every day.
Every feature below exists because we needed it ourselves. SpiritMCP runs the Spiritual Agency estate, eight VPSes, four production WordPress sites, hundreds of tasks a week, and every capability ships only after it has been used in production against our own infrastructure first.
bridge_memory_get and bridge_memory_set become Claude's long-term memory across your infrastructure.ssh_exec, file_read, file_write, service_action, db_query, every operation an agency runs by hand, exposed as a typed MCP tool.bridge_health, bridge_metrics, bridge_recent_errors give Claude live introspection across the entire fleet. Tail an audit log, diff memory between sites, snapshot a VPS, from a chat prompt.
A dashboard that mirrors the agency's mental model.
The React+Vite dashboard at mcp.spiritual.agency surfaces what an operator actually needs at a glance, connected VPSes, active sites, audit tail, memory key explorer, tool inventory. Branding and password are per-install; nothing about the deployed dashboard reveals the bridge below it.
Landscape · production
Self-hosted dashboard · branded per install
Two layers. One audited bridge.
SpiritMCP's architecture separates what's designed (committed to git, baked into the image at build time) from what's runtime (your VPSes, your memory overlays, your audit log, on an isolated volume).
Claude talks to the bridge over MCP. The bridge talks to your fleet over SSH. Memory persists across sessions. Audit logs persist across deploys. Nothing in the image holds your secrets.
- Claude Desktop / Code / API connect via MCP transport
- Bridge container is stateless, restart safely
- Seed memory baked into image at build time
- Runtime memory + VPS keys on isolated volume
- SSH to your fleet uses your keys, not ours
- Audit log written for every destructive operation
The full stack, in the layers that matter.
Bridge backend, MCP transport, persistence, and integration tooling. Each rail handles one concern. The same architectura that runs the Spiritual Agency estate ships in every customer install.
Memory and tools, addressable from chat.
The Memory Bridge is what separates SpiritMCP from every other MCP server we've seen. Claude doesn't just call tools, it remembers what you said about your infrastructure across every session. Estate-level keys, per-site overlays, audit-logged writes.
Landscape · production
240 estate keys · 4 site overlays · persistent across Claude sessions
What's running in production today.
Numbers below reflect the SpiritMCP instance running the Spiritual Agency estate. Deployed via Polar.sh license, self-hosted on Hetzner, in continuous production since 8 May 2026.
SpiritMCP is available to developers and agencies.
Self-hosted Docker image, per-purchase license via Polar.sh. The same bridge that runs the Spiritual Agency estate, deployed on your infrastructure, in your control, with your secrets.