MCP server
One MCP server per site that the team installs once, signs in to with Cloudflare Access, and that can only change content after a person approves.
The gateway is built as three packages, @patronage/mcp-core, @patronage/mcp-wordpress and @patronage/mcp-payload, deployed by apps/mcp. They’re published to npm under @patronage. Tool packs are still to come. The design is in ADR 0014.
What a site’s team gets
- One install. One Agent Plugin for Claude, Codex or Cursor that carries only the MCP server’s URL.
- Sign-in through Cloudflare Access. The same Access application that guards the CMS. Reads run as the signed-in person.
- Approved writes only. Every change to CMS content pauses with a before-and-after for a person to approve, and runs as the approver. Changes to code will go through a pull request.
- Tools added over time. New tools ship in the same server, so nobody reinstalls anything.
How it fits together
| Part | Status and role |
|---|---|
packages/mcp-core |
Built. The gateway Worker: sign-in, the code-mode runtime, tool catalog, write approval, logging and the connector contract. It names no CMS |
packages/mcp-wordpress |
Built. The wp connector: WPGraphQL and REST reads, approved post updates (core and ACF fields) |
packages/mcp-payload |
Built. The payload connector: reads through Payload’s own MCP endpoint (@payloadcms/plugin-mcp). Approved edits and new documents are saved as drafts, or published when the operation asks for it and the approval card says so, and rich text can be written as Markdown |
apps/mcp |
Built. Launch’s deployment: it lists the two connectors and holds the Cloudflare config |
| Tool packs | Planned. Typed tools for named workflows, kept in each site’s own repository |
The model sees a short tool list: execute runs JavaScript against the connectors in a Dynamic Worker, describe_site summarizes the content types, and get_run reports on a run after its approval. A write is approved on a card inside the client, where the client supports MCP Apps, or on a browser page at /mcp/approvals/:id. A site depends on the npm packages rather than copying them.
Signing in with something other than Access
Launch ships Access only. Signing in with WorkOS lists what a site would need to change to use WorkOS AuthKit instead.
Usage reporting
Each request writes one wide event to Workers Logs: who called, which tool, the outcome, and any write receipts. Workers Logs keep events for seven days, which is enough to debug a problem.
To keep events longer, build the gateway with WORKER_LOGPUSH=true, and the site’s log bucket will receive them through Logpush (see Logging). A weekly usage report and a read-only connector for querying the logs are not built yet.