---
title: MCP server
description: 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](https://github.com/patronage/launch/blob/main/docs/adr/0014-mcp-gateway-worker.md).

## 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](/references/mcp-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](/references/logging)). A weekly usage report and a read-only connector for querying the logs are not built yet.