Skip to main content
Glama
BlogFactoryHQ

Ghost Publisher MCP

Check Ghost publication health

check_site_health
Read-onlyIdempotent

Verify Ghost content and delivery health in Ghost Publisher MCP by checking delivery surfaces, published targets, canonicals, share prerequisites, and feature images without crawling or writing.

Instructions

Check server-selected Ghost and delivery surfaces, exact published targets, canonicals, share prerequisites, and Ghost-returned feature images without crawling or writing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pagesNo
postsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
siteYes
checksYes
summaryYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.10.1

TDQS

B3.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so safety is covered; the description's 'without crawling or writing' meaningfully confirms no external crawling and no state mutation, which the annotations alone don't convey. It still does not describe response behavior, but the output schema covers that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence listing the checks, with the constraining clause at the end. Dense but no filler sentences; it is efficient, if a bit jargon-saturated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained, and the check list is thorough. However, with zero required parameters and no explanation of the pages/posts inputs or default behavior when omitted, the description is not complete enough for an agent to call it confidently in all cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and neither the pages nor posts array is mentioned in the description, so there is no semantic guidance on what these IDs represent or what happens when they are omitted (0 required params). The regex patterns document format but not meaning, leaving the description responsible for a gap it does not fill.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (check) and enumerates the surfaces inspected: published targets, canonicals, share prerequisites, and feature images. It is distinguishable from siblings like list_pages or check_connection, though phrases like 'server-selected Ghost and delivery surfaces' are jargon-heavy and vague.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'without crawling or writing' clause implies this is a non-invasive validation step, but there is no explicit when-to-use versus check_connection, check_live_posts, or check_live_pages. Usage is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.