Provides tools for managing Ghost CMS content and settings, including posts, pages, tags, images, members, tiers, offers, newsletters, webhooks, users, and themes via the Ghost Admin API.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ghost-mcp-secure list my recent posts"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A secure-by-default, full-capability Model Context Protocol (MCP) server for Ghost CMS.
It can drive almost the entire Ghost Admin API — posts, pages, tags, images, members, tiers, offers, newsletters, settings, webhooks, users, and themes — but every mutating capability is off until you explicitly opt in via an environment flag. Out of the box it is strictly read-only. You decide, per session, exactly how much power the assistant gets.
Community Ghost MCP servers usually expose the full Admin API unconditionally. That is a large attack surface: a prompt-injected model could delete content or leak member data. This server keeps the full feature set but puts each dangerous domain behind its own switch, so a typical session grants only what's needed and nothing more.
Related MCP server: Ghost MCP Server
Concern | How this server handles it |
Read-only by default | Nothing mutates unless a flag is set. Fresh install = read-only. |
Accidental / injected deletion | Delete tools do not exist unless |
Accidental publishing | New content is always created as a draft. Publishing needs |
Member (PII) data | Member tools don't exist unless |
High-privilege admin | Settings/webhooks/users/themes are off unless |
Supply chain | Pinned versions, only 2 runtime deps ( |
Secret leakage | Admin secret is never logged and never returned to the model. JWTs are short-lived (5 min) and generated locally with |
Context bloat | Tool results are slimmed and capped at 25k chars. |
All default to false. Reads of posts/pages/tags/site are always available.
Flag | Unlocks |
| Create/update posts, pages, tags; upload images & themes |
| Set content status to |
| All delete tools (posts, pages, tags, members, webhooks, users) |
| Member tools (read + write of PII) |
| Tiers, offers, newsletters |
| Settings, webhooks, users, theme upload/activate |
Treat deletion and publishing as deliberate actions: enable those flags only for the session where you actually intend to use them. A delete tool that doesn't exist can't be triggered by a stray prompt.
npm install # installs the 2 pinned deps
cp .env.example .env # then fill in your URL + Admin API key + the flags you wantHow env vars are loaded: the server reads variables straight from its environment — it does not auto-load
.env. With Claude Desktop/Code, set them in the MCP client config'senvblock (see below). The.envfile only takes effect if you launch the server yourself withnode --env-file=.env src/index.js(Node ≥ 20.6).
Ghost Admin → Settings → Integrations → Add custom integration. Copy the Admin API
Key (format id:secret). Keep it private — it grants admin access to the Ghost API, so
treat it like a password. Create the integration specifically for this tool so you can
revoke just this key later without affecting anything else.
Add to claude_desktop_config.json (or your MCP client config). Use an absolute path:
{
"mcpServers": {
"ghost": {
"command": "node",
"args": ["/absolute/path/to/ghost-mcp-secure/src/index.js"],
"env": {
"GHOST_API_URL": "https://cuongn.com",
"GHOST_ADMIN_API_KEY": "id:secret",
"GHOST_WRITE_ENABLED": "true",
"GHOST_ALLOW_PUBLISH": "false",
"GHOST_ALLOW_DELETE": "false",
"GHOST_ALLOW_MEMBERS": "false",
"GHOST_ALLOW_MONETIZATION": "false",
"GHOST_ALLOW_SYSTEM": "false"
}
}
}
}Set only the flags you need. Omit one and it defaults to false.
The same code also runs as a hosted server for claude.ai custom connectors and
ChatGPT Developer Mode, via src/http-server.js: MCP Streamable HTTP + a
self-contained OAuth 2.1 + PKCE layer (dynamic client registration, a password
login gate, HMAC-signed tokens — no extra dependency, all node:crypto). A
Dockerfile plus one-command deploy scripts for Google Cloud Run and
Railway are included.
One-click deploy:
Both prompt for GHOST_ADMIN_API_KEY and MCP_AUTH_PASSWORD (MCP_OAUTH_SECRET
is auto-generated). Or run it yourself:
npm run start:http # local run (requires MCP_AUTH_PASSWORD + MCP_OAUTH_SECRET)
npm run smoke:remote # end-to-end OAuth + MCP self-test
GHOST_ADMIN_API_KEY='id:secret' MCP_AUTH_PASSWORD='…' npm run deploy:cloud-run
GHOST_ADMIN_API_KEY='id:secret' MCP_AUTH_PASSWORD='…' npm run deploy:railwayOAuth gates who may connect; the privilege flags still gate what they can do
(keep GHOST_ALLOW_DELETE/GHOST_ALLOW_SYSTEM off for an internet-facing endpoint).
Full Cloud Run / Railway + connector setup is in REMOTE.md.
GitHub Actions workflows for auto-deploy on push to main (Cloud Run via keyless
Workload Identity Federation, and Railway) are included but stay inert until you set
the opt-in repo variables — see REMOTE.md → Continuous deployment.
Read — always available
ghost_site_info — title, description, version, url.
ghost_list_posts / ghost_get_post — list (filter by status/tag, paginate) / fetch one with full HTML.
ghost_list_pages / ghost_get_page — same, for pages.
ghost_list_tags / ghost_get_tag — tags with post counts.
Content write — GHOST_WRITE_ENABLED
ghost_create_post / ghost_update_post — defaults to draft; status honored only with GHOST_ALLOW_PUBLISH.
ghost_create_page / ghost_update_page — same, for pages.
ghost_create_tag / ghost_update_tag.
ghost_upload_image — upload from a local path, a remote URL, or base64 bytes / data URI (data_base64, for images pasted in chat); returns the hosted URL. Use url/data_base64 when the server is remote (no local disk access). The image type is detected from the bytes (magic numbers) — JPEG/PNG/GIF/WebP/SVG/ICO/AVIF/HEIC/BMP/TIFF — so a mislabelled or extension-less image still uploads correctly. Transient network/5xx failures are retried with backoff; uploads over 25 MB are rejected.
Delete — GHOST_ALLOW_DELETE (irreversible)
ghost_delete_post, ghost_delete_page, ghost_delete_tag (+ member/webhook/user delete when those domains are on).
Members — GHOST_ALLOW_MEMBERS
ghost_list_members, ghost_get_member, ghost_create_member, ghost_update_member, ghost_delete_member.
Monetization — GHOST_ALLOW_MONETIZATION
Tiers: ghost_list_tiers, ghost_create_tier, ghost_update_tier (archive via active=false).
Offers: ghost_list_offers, ghost_create_offer, ghost_update_offer (archive via status).
Newsletters: ghost_list_newsletters, ghost_create_newsletter, ghost_update_newsletter.
System — GHOST_ALLOW_SYSTEM
Settings: ghost_get_settings, ghost_update_settings.
Webhooks: ghost_create_webhook, ghost_update_webhook, ghost_delete_webhook.
Users: ghost_list_users, ghost_get_user, ghost_update_user, ghost_delete_user.
Themes: ghost_upload_theme, ghost_activate_theme.
With every flag enabled the server exposes 42 tools; with none it exposes 7 (reads only).
No build step — what you read is what runs.
src/
index.js LOCAL entrypoint — stdio transport
http-server.js REMOTE entrypoint — Streamable HTTP + OAuth (see REMOTE.md)
core.js transport-agnostic server assembly (shared by both entrypoints)
oauth.js stateless OAuth 2.1 + PKCE authorization server (node:crypto)
config.js env parsing, privilege flags, instructions + remote config
helpers.js result builders, object slimmers, upload utilities
ghost-client.js dependency-free Ghost Admin API client (generic CRUD + uploads)
tools/
site.js ghost_site_info
content.js posts, pages, tags
images.js image upload
members.js members
monetization.js tiers, offers, newsletters
system.js settings, webhooks, users, themes
Dockerfile container image for the remote server (Cloud Run / Railway)
railway.json Railway build/deploy config (Dockerfile, 1 replica, healthcheck)
app.json env prompts for the "Run on Google Cloud" one-click button
deploy/
cloud-run.sh one-command Google Cloud Run deploy (secrets + PUBLIC_URL)
railway.sh one-command Railway deploy
setup-gcp-wif.sh one-time Workload Identity Federation setup for CI
.github/workflows/
deploy-cloud-run.yml auto-deploy to Cloud Run on push to main (keyless WIF)
deploy-railway.yml auto-deploy to Railway on push to mainnpm run check # syntax check (node --check)
npm run audit # vulnerability scan of runtime depsTo smoke-test the live API locally (Node ≥ 20.6), pipe an MCP handshake into the server:
printf '%s\n' \
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"t","version":"1"}}}' \
'{"jsonrpc":"2.0","method":"notifications/initialized"}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"ghost_site_info","arguments":{}}}' \
| node --env-file=.env src/index.jsMIT — see LICENSE.
Fetch a single page by id or slug, including its full HTML body. Provide exactly one of id or slug.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | page id. | |
| slug | No | page slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses that the tool returns 'full HTML body', which is a key behavioral trait. However, it does not cover error cases (e.g., page not found) or permissions, but for a simple fetch, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded: first sentence states action and result, second adds constraint. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple fetch tool with 2 optional parameters, no output schema, and no annotations, the description covers essential aspects: what it does, how to call it (exactly one of id/slug), and what it returns (full HTML body). Completely adequate for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage (id and slug described), so baseline is 3. Description adds 'Provide exactly one of id or slug', clarifying mutual exclusivity and usage constraint, which adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fetch a single page by id or slug, including its full HTML body.' Verb 'fetch' is specific, resource is 'page', method is by id/slug, and output includes full HTML body. Distinguishes from siblings like ghost_list_pages and ghost_get_post by specifying page vs post and single vs list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description only gives the constraint 'Provide exactly one of id or slug.' No explicit when-to-use or when-not-to-use guidance, nor alternatives mentioned. While the constraint is useful, the agent lacks context for choosing this tool over siblings like ghost_list_pages or ghost_get_post.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single post by id or slug, including its full HTML body. Provide exactly one of id or slug.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | post id. | |
| slug | No | post slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the primary behavior (fetching a single post with HTML body) but does not mention read-only nature, auth requirements, or side effects. For a simple read operation, this is minimally adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with no wasted words. It front-loads the core purpose and follows with a critical usage constraint. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters, no nested objects, no output schema), the description is largely sufficient. It covers the action, identifier options, and return detail (HTML body). A minor addition about the return structure could improve completeness, but current info is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both id and slug described as 'post id.' and 'post slug.' respectively. The description adds the important constraint 'Provide exactly one of id or slug', which is not enforced by the schema (both are optional). This adds meaningful usage guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'a single post', specifying the retrieval method 'by id or slug' and the additional detail 'including its full HTML body'. It effectively distinguishes from sibling tools like ghost_list_posts (list multiple posts) and ghost_get_page (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Provide exactly one of id or slug', giving a clear constraint on parameter usage. It does not, however, explicitly compare to sibling tools or provide when-to-use vs. when-not-to-use guidance, though the sibling names imply differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single tag by id or slug. Provide exactly one.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| slug | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavior. It states the tool fetches a single tag, which implies a read operation, but does not address error conditions (e.g., missing tag), rate limits, or whether the operation is safe. The description is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, consisting of two short sentences that convey the essential information without any superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (two optional parameters, no output schema, no nested objects), the description covers the core behavior and constraint. It could mention what happens if both or neither parameter is provided, but overall it is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by clarifying that the two parameters are mutually exclusive ('by id or slug') and that exactly one must be provided. However, it does not specify constraints like valid formats or required presence, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch a single tag by id or slug', specifying the verb, resource, and identifier options. It effectively distinguishes from sibling tools like ghost_list_tags which lists tags, and ghost_get_post which fetches a different resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Provide exactly one' is helpful but lacks explicit guidance on when to use this tool versus alternatives such as ghost_list_tags. There is no mention of prerequisites or context for choosing id over slug.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List pages with optional status/tag filtering and pagination. Returns slimmed metadata (no full body) to keep results compact.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Filter by tag slug, e.g. 'pmo'. | |
| page | No | ||
| limit | No | ||
| status | No | Filter by status. | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses that results are slimmed (no full body) and that pagination and filtering are supported, which is useful. However, it does not mention error behavior, default filtering behavior (e.g., default status is 'all'), or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action and key features (filtering, pagination, slimmed metadata). Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters and no output schema, the description is somewhat incomplete. It mentions slimmed metadata but does not specify which fields are returned, how pagination works in practice, or whether filters are combinable. Adequate but leaves gaps for a tool of moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (tag and status have descriptions; page and limit do not). The description mentions tagging, status, and pagination at a high level, adding context beyond the schema's individual descriptions. But it does not elaborate on each parameter's format or constraints, leaving the schema to do more work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists pages, with optional filtering by status and tag, and pagination. It distinguishes itself from siblings like ghost_list_posts by specifying 'pages' and notes it returns slimmed metadata, differentiating from ghost_get_page which would return full content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing pages with filters, but does not explicitly guide when to use alternatives like ghost_get_page or ghost_list_posts. No exclusions or when-not-to-use advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List posts with optional status/tag filtering and pagination. Returns slimmed metadata (no full body) to keep results compact.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Filter by tag slug, e.g. 'pmo'. | |
| page | No | ||
| limit | No | ||
| status | No | Filter by status. | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. Mentions return of 'slimmed metadata (no full body)', which is useful behavioral info. However, lacks details on authentication, rate limits, or side effects beyond the read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core purpose. Every sentence adds value without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers optional filtering, pagination, and slimmed output. Lacks details like default sorting, return structure, or behavior when no results. Adequate but not fully comprehensive for a listing tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only tag and status have descriptions). Description adds no extra meaning for parameters beyond what schema provides. Baseline of 3 is appropriate given moderate coverage and no additional semantic enrichment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Describes listing posts with optional status/tag filtering and pagination. Clearly distinguishes from sibling tools like 'ghost_get_post' (single post) and 'ghost_list_pages' (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage via filtering and pagination options, but does not explicitly state when to use this tool versus alternatives (e.g., 'ghost_get_post' for a single post). No when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tags on the Ghost blog with their post counts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that results include 'post counts', but with no annotations, it fails to mention other traits like read-only nature, auth requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool, but lacks details on pagination, default behavior, or ordering; could be more complete given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description does not add meaning to the 'limit' parameter (only parameter), leaving the parameter completely without explanation; schema has 0% coverage, so description should compensate but doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List tags' on Ghost blog with 'post counts', which distinguishes it from siblings like ghost_get_tag (single tag) and ghost_list_posts (list posts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like ghost_get_tag or ghost_list_posts; no when-not or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return basic information about the Ghost site (title, description, version, url).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose any behavioral traits (e.g., authentication needs, rate limits, side effects). Only the return values are stated, lacking transparency on other aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with 12 words, no filler, immediately states the core functionality. Optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description lists key return fields (title, description, version, url). For a simple read-only info tool, this is adequate. Could be improved by noting potential error states or response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (0 params), so baseline score of 4 applies. The description does not need to explain parameter meaning since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns basic site info (title, description, version, url), with a specific verb 'Return'. It is distinct from sibling tools that focus on posts, pages, or tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings. Context implies it is for site-level metadata, but no when-not or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: site info, list/get for posts, pages, and tags. No overlap, clear boundaries.
All tools use the 'ghost_' prefix followed by a consistent verb_noun pattern (e.g., list_posts, get_post), all in snake_case.
7 tools is well-scoped for a read-only Ghost CMS server, covering the main resources (site info, posts, pages, tags) without bloat.
The set covers read operations (list and get) for posts, pages, and tags, plus site info, but lacks write operations like create, update, delete, which limits full lifecycle coverage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Security-first WordPress MCP server. 129 tools for Claude, ChatGPT, Gemini. Free on wp.org.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cuonghapvn/ghost-mcp-secure'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
