The best Ghost MCP server depends on the boundary you need. Some projects expose broad Ghost administration, including members, newsletters, users, themes, and deletion. Others focus on a narrower editorial path: reading content, creating drafts, uploading images, scheduling, publishing with approval, and checking the public result.
This comparison reviews four active open-source approaches using their public repositories and documentation as checked on August 25, 2026. It compares product scope, not an independent security audit or performance benchmark.
Key points
- Choose Ghost Publisher MCP for a narrow, local, approval-gated publishing workflow.
- Choose MFYDev/ghost-mcp when broad Ghost management is more important than a minimal tool surface.
- Consider jgardner04/Ghost-MCP-Server for a straightforward multi-resource server with explicit CRUD-style operations.
- Consider damusix/ghost-mcp when you want broad API dispatch and richer native Ghost authoring options.
- A broader server is not automatically better or worse; it serves a different operator and risk model.
- Review the current registered tools and repository before connecting a production Admin API key.
How we evaluated the Ghost MCP servers
The comparison uses public project documentation, not private testing against each server. Features can change after publication, so verify the current README, release notes, package, and tool inventory before installation.
The evaluation criteria are:
- primary boundary and intended operator;
- posts and Pages support;
- content input and native Ghost authoring depth;
- images, scheduling, and publication controls;
- revision, preview, confirmation, and retry behavior;
- members, newsletters, users, themes, tiers, offers, and deletion;
- local or remote transport model;
- deployment and public-result verification;
- license, requirements, and maintenance signals.
We did not rank projects by GitHub stars, claim an absolute security winner, or treat a longer tool list as inherently better. The right server is the smallest one that still supports the real workflow.
Quick comparison
Ghost Publisher MCP
Best fit: local, publishing-focused workflows that need permission profiles, draft-first creation, approvals, scheduling, images, deploy hooks, and live checks without general Ghost administration.
MFYDev/ghost-mcp
Best fit: operators who want comprehensive Ghost management through an MCP client, including content plus users, members, tiers, offers, newsletters, tags, and webhooks.
jgardner04/Ghost-MCP-Server
Best fit: teams seeking a direct CRUD-style MCP surface across several Ghost resource types with HTML content input and explicit create, update, and delete operations.
damusix/ghost-mcp
Best fit: advanced users who want broad Ghost Admin and Content API access, richer authoring helpers, and the option to work close to native Ghost or API payloads.
1. Ghost Publisher MCP
Ghost Publisher MCP is an unofficial, local-first server maintained by BlogFactoryHQ. It is designed as a bounded editorial surface rather than a complete mirror of the Ghost Admin API.[1]
Its workflow covers posts, Pages, images, schedules, content audits, site-health checks, change previews, publishing, unpublishing, optional deployment hooks, and public live checks. Draft-creation tools always create drafts. Publishing, scheduling, applying change sets, unpublishing, and deployment require separate approval signals.
Permission profiles register different capabilities:
- read-only for reads, audits, previews, checks, and planning;
- draft-editor for drafts, approved changes, and validated image uploads;
- scheduler for schedule and unschedule operations;
- publisher for publish, unpublish, deployment, and published-metadata workflows.
The server deliberately excludes delete tools, members, newsletters, themes, arbitrary API calls, remote transport, and built-in AI billing. It supports Markdown and a bounded set of native Ghost blocks rather than every possible Koenig or Admin API structure.
Where Ghost Publisher is strongest
It makes the publishing boundary explicit. Exact revisions, previews, preflight checks, separate confirmation, no automatic write retry, deployment receipts, and live checks are central to the design.
Where another server may be stronger
Choose a broader project when you need member management, newsletters, offers, tiers, user administration, themes, deletion, arbitrary endpoint access, or deeper native authoring than the bounded surface provides.
See the current Ghost Publisher MCP overview for installation and capability details.
2. MFYDev/ghost-mcp
MFYDev/ghost-mcp describes itself as a comprehensive MCP server for interacting with Ghost CMS through LLM interfaces. Its public README highlights posts, users, members, tiers, offers, newsletters, tags, invites, roles, and webhooks.[2]
This breadth is useful when the operator wants the AI client to act as a general Ghost administrator rather than a publishing assistant. It can reduce the number of separate integrations required for content, membership, and newsletter operations.
Where MFYDev/ghost-mcp is strongest
It offers broad resource coverage and is well suited to users who explicitly need management capabilities beyond posts and Pages. Its public project visibility and established usage make it an obvious server to evaluate.
What to review carefully
A comprehensive surface creates a larger permission set. Review which create, update, and delete operations are registered, how confirmation is handled, whether the client can restrict tool availability, and whether every administrative capability is necessary for the operator.
This is not evidence that broad scope is insecure. It means the server is designed for a different job and should be deployed with correspondingly stronger access governance.
3. jgardner04/Ghost-MCP-Server
jgardner04/Ghost-MCP-Server exposes Ghost CMS management functions as MCP tools for clients such as Cursor and Claude Desktop. Its public documentation describes a multi-resource server with create, read, update, and delete operations and HTML-oriented post and Page input.[3]
The project covers resources including posts, Pages, members, newsletters, and tiers. It is appropriate for teams that prefer explicit entity operations and want a conventional CRUD mental model.
Where jgardner04/Ghost-MCP-Server is strongest
The resource-oriented design is understandable for developers familiar with REST administration. HTML input can be convenient when the publishing pipeline already produces HTML rather than Markdown or native Ghost cards.
What to review carefully
Check the current Node requirement, transport configuration, delete operations, content-format expectations, and how the server handles revisions, confirmation, partial failures, and post-write verification. A CRUD tool is not automatically an editorial approval workflow.
4. damusix/ghost-mcp
damusix/ghost-mcp positions itself as a broad Ghost MCP server for managing content, members, newsletters, and other Ghost resources. Its public documentation includes Admin and Content API access plus authoring helpers for native Ghost content structures.[4]
The project is attractive to advanced operators who want deeper access to Ghost rather than a narrowly prescribed publishing sequence. It can support richer Koenig-style authoring and direct API-oriented workflows.
Where damusix/ghost-mcp is strongest
Its breadth and authoring depth are useful when the client needs to work with complex native Ghost structures or resources beyond editorial publishing.
What to review carefully
Determine whether the deployment uses read-only Content API access, full Admin access, or direct dispatcher behavior. Review arbitrary action capability, deletion, members, newsletters, users, webhooks, images, themes, and the client’s ability to limit the registered surface.
How the servers differ by publishing boundary
The central difference is not whether a server can create a post. All four projects are built around Ghost interaction. The difference is what else the same connection may do and how writes are controlled.
- Narrow publishing boundary: Ghost Publisher MCP.
- Comprehensive Ghost administration: MFYDev/ghost-mcp.
- Entity-oriented CRUD management: jgardner04/Ghost-MCP-Server.
- Broad API dispatch and richer authoring: damusix/ghost-mcp.
A content editor may prefer the first boundary. A Ghost product administrator may legitimately need one of the broader surfaces.
Content format and authoring depth
Content input affects how much of Ghost’s editor model the automation can preserve. Markdown is portable and easy for AI clients to produce, but it does not represent every native Ghost card. HTML is widely supported but may require conversion. Native Koenig or Lexical structures provide richer authoring at the cost of more complex payloads.
Choose based on the publication’s real content. A simple SEO blog may need headings, paragraphs, lists, links, images, callouts, bookmarks, and buttons. A complex membership publication may need newsletters, paywalls, offers, embeds, custom cards, and theme-level behavior.
Write controls and failure behavior
Before using any server in production, look for:
- draft-only creation;
- exact IDs or slugs rather than ambiguous targets;
- current revision or updated-at checks;
- preview-before-apply behavior;
- separate confirmation for schedule, publish, unpublish, and delete;
- preflight of the whole batch before the first mutation;
- readback receipts after writes;
- no automatic retry for uncertain writes.
If a project does not provide these controls, the host application or operator can add external safeguards. The absence of a built-in feature is not proof that safe operation is impossible, but it changes the work required.
Local transport vs broader network access
Local stdio keeps the server process and Ghost credential on the operator’s machine. This reduces the need to trust a hosted credential service, but the local package still has access to the key and must be reviewed.
HTTP or remote transport can support centralized deployment and multiple users, but it requires authentication, authorization, tenancy, logging, secret storage, network restrictions, and incident response. Compare the actual deployment model rather than assuming “local” or “remote” is universally safer.
Which Ghost MCP server should you choose?
Choose Ghost Publisher MCP if
you want a small publishing surface, local setup, permission profiles, draft-first creation, approvals, schedules, deploy hooks, and public checks—and you explicitly do not want general Ghost administration.
Choose MFYDev/ghost-mcp if
your AI client must manage content, users, members, tiers, offers, newsletters, tags, roles, and webhooks through one broad connection.
Choose jgardner04/Ghost-MCP-Server if
you prefer explicit CRUD-style tools, work primarily with HTML input, and need several Ghost resource types without the specific approval architecture of a publishing-only server.
Choose damusix/ghost-mcp if
you need broad Ghost API control, richer native authoring helpers, or direct access patterns that a narrow publishing tool deliberately excludes.
For the surrounding editorial architecture, see Ghost Admin API vs MCP and the complete Ghost CMS automation guide.
Frequently asked questions
Is there an official Ghost MCP server?
The projects compared here are independent open-source integrations built on Ghost APIs. They are not presented as official Ghost Foundation products.
Which Ghost MCP server is safest?
This article does not make an absolute security ranking. Review the source, package, tools, dependencies, transport, credentials, write controls, release history, and your own deployment.
Do I need full Ghost administration for AI publishing?
Usually not. Drafts, metadata, images, schedules, publishing, deployment, and live checks can be handled without members, newsletters, themes, users, or deletion.
Can I use more than one Ghost MCP server?
Technically yes, but overlapping tools can confuse operators and models. Use distinct server names, minimize duplicate capabilities, and document which connection owns each workflow.
Should I connect a production Ghost site immediately?
No. Review the package, test in staging, begin read-only, verify the intended site, and add write permissions only after the workflow and failure behavior are understood.
The practical takeaway
There is no single best Ghost MCP server for every operator. The most important choice is the boundary.
Use a narrow publishing server when the job is editorial delivery. Use a broad administration server when the operator genuinely needs broad Ghost control. Match content format, transport, approval model, failure handling, and maintenance burden to the real workflow rather than choosing by feature count alone.
References
[1] BlogFactoryHQ/ghost-publisher-mcp