Post editing is the obvious use; the membership side is the one that saves real time - tiers, offers, newsletters and member records are all reachable in the same session, which is normally several screens of the Ghost admin. Errors come back as descriptive messages rather than raw API failures, which matters when the model has to decide what to do next.
A server over Ghost's Admin API, authenticated with JWT through the official admin client. Each Ghost entity gets the same shape of operations - browse, read, create, edit, delete - so the coverage is wide and predictable.
- Posts: list with filters, pagination and ordering, read by ID or slug, create with title, content and status, edit and delete
- Members: list, read by ID or email, create, update and remove
- Newsletters, offers and tiers: full browse, read, create, edit and delete on each
- Tags for organising content, invites for bringing staff in, and roles for reading permissions
- Users: list, read, update and remove
- Webhooks: list, add and delete, for wiring Ghost events to other systems
- Search with both fuzzy and exact matching, and readable output rather than raw API payloads
Node, run with npx @fanyangmeng/ghost-mcp. Three environment variables: GHOST_API_URL pointing at your blog, GHOST_ADMIN_API_KEY, and GHOST_API_VERSION. The admin key carries whatever permissions Ghost grants it, so this reaches member records and staff accounts, not just published posts.
One command plus a key — npx -y @fanyangmeng/ghost-mcp, then supply credentials