Ghost CMS Admin & Newsletter MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action (e.g., list_posts vs get_post, create_member vs update_member). The combination of noun (post, page, tag, member, newsletter, webhook) and verb (list, get, create, update, delete) makes each tool's purpose immediately clear, with no overlapping or ambiguous tools.
Naming Consistency5/5
All tools follow a uniform 'ghost_<verb>_<noun>' pattern in snake_case. Verbs are consistently action-oriented (list, get, create, update, delete) and nouns correspond to specific entities, with only a few compound verbs like 'publish_and_send' that still adhere to the overall pattern.
Tool Count4/5
With 34 tools, the server covers a broad domain (posts, pages, tags, members, newsletters, webhooks, offers, tiers, images, site info). While higher than the typical 3-15 range, it is justified by the number of entities and their CRUD needs, so it remains reasonable and each tool serves a distinct purpose.
Completeness4/5
The tool surface covers full lifecycle operations for most core entities (posts, pages, tags, members, webhooks) and provides listing for auxiliary entities like offers and tiers. Minor gaps exist (e.g., no delete for newsletters, no update for webhooks), but these are edge cases and do not block primary workflows.
Average 3.5/5 across 34 of 34 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it creates a channel, but does not mention side effects, whether the newsletter becomes active immediately, need for additional setup, or any post-creation implications. This is insufficient for a mutation operation.
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?
The description is a single, concise sentence with no redundant wording. It front-loads the core purpose immediately. While it could include a bit more detail, the brevity is not excessive; it's acceptable for a simple action statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain the implications of creating a newsletter (e.g., whether it is immediately sent, how it relates to existing members, or any typical workflow steps). An agent would have to rely entirely on the parameter descriptions and guess at overall behavior, which is inadequate for a complex creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage, meaning each parameter includes a description (e.g., 'Name of the newsletter', 'Opt in existing members automatically'). The tool description adds nothing beyond the schema, which already documents parameter intent. Thus the baseline of 3 is appropriate.
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?
The description clearly states the action ('Create') and the resource ('email newsletter channel'), with context ('for the Ghost publication'). It distinguishes from sibling tools by the verb 'create' versus 'get', 'update', 'list', so an agent can identify it as the creation operation. However, it does not explicitly contrast with alternatives like ghost_update_newsletter, so it's not a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus others, nor any exclusions or prerequisites. It simply states the action. There is no mention of alternatives despite siblings like ghost_update_newsletter or ghost_list_newsletters, leaving the agent to infer usage context on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits but does not. It only states the action 'update' but does not mention idempotency, error behavior (e.g., what if id is invalid), auth requirements, or effects on related fields like html vs markdown. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no filler. However, it is too sparse for a tool with nine parameters; the description could include key details like 'use html for full HTML or markdown for markdown content' without becoming wordy. It is concise but under-specifies, so a middle score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nine parameters, no output schema, and no annotations, the description is extremely minimal. It does not explain return values, behavior on missing id, or how multiple fields are applied. An agent may not know whether updating triggers a publish or other side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All nine parameters have descriptions in the schema, so schema coverage is 100%. The tool description adds no additional meaning beyond the schema, so it earns the baseline score of 3. It does not clarify relationships like the exclusivity of html and markdown.
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?
The description uses the verb 'Update' with the resource 'existing static page in Ghost CMS', which clearly identifies the operation on a page resource. It distinguishes from sibling tools like ghost_update_post by naming 'page', but it doesn't explicitly clarify the difference between a page and a post or specify any edge conditions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus ghost_create_page or ghost_update_post. It does not mention prerequisites (e.g., page must already exist) or alternatives. The agent is left inferring from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden of behavioral disclosure. It only says 'create' without mentioning side effects, permission requirements, or default behavior. It does not note that the status field defaults to 'draft', or that posts can be published or scheduled, nor does it explain the relationship between html and markdown inputs. This is a significant gap for a mutation tool.
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?
The description is a single, clear sentence with no fluff. It is concise and front-loaded with the core purpose. While it is sparse given the tool's complexity, the brevity is not excessive and the sentence earns its place as a basic purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 14 parameters, no annotations, and no output schema, the description is grossly under-specified. It does not mention enums (status, visibility), defaults, or the ability to schedule posts, send newsletters, or handle markdown vs HTML. An agent would have to rely entirely on the schema for correct invocation, leaving critical context about side effects and operational behavior uncovered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with detailed descriptions, so the description adds no additional meaning. The phrase 'blog post or newsletter draft' hints at newsletter-related parameters, but the schema already documents those (newsletter_id, email_segment). The description provides no value beyond what the schema already conveys, so the baseline score of 3 is appropriate.
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?
The description clearly states the verb ('Create') and resource ('blog post or newsletter draft') within Ghost CMS. It is specific enough for an agent to identify the tool's core function. However, it does not explicitly distinguish it from sibling tools like ghost_create_page or ghost_create_newsletter, which handle similar creation operations for different content types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as ghost_create_page or ghost_create_newsletter. There are no mentions of scenarios where this tool is preferable or should be avoided, leaving the agent to infer usage solely from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention side effects, idempotency, validation rules (e.g., duplicate name handling), permissions, or response format. The '#internal' note is a naming constraint already present in the schema, so it adds little beyond what structured data provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, front-loading the verb and resource. It is extremely concise without redundant phrasing, earning its place by stating the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 6 parameters, no output schema, and no annotations, this description is too sparse. It fails to explain the meaning or implications of internal tags beyond the '#', lacks any mention of required fields (name), and provides no insight into expected responses or error conditions. An agent would need to infer too much.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented there. The description does not add any meaning about parameters beyond the schema; it merely repeats the '#internal' hint already in the name parameter's description. Baseline 3 is appropriate since the schema handles parameter documentation adequately.
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 operation ('Create a new tag') with a clear resource and an added nuance about public vs internal tags starting with '#'. This is not a tautology and distinguishes from update/get/delete siblings by using the verb 'create'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like ghost_update_tag or ghost_list_tags. It only says what it does, not when to invoke it or any exclusions. The internal/public distinction is mentioned but not elaborated as a decision point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It communicates a read-oriented operation ('List and search') with filtering, pagination, and sorting, but does not disclose return format, default pagination behavior, rate limits, or any side effects. It is not misleading, but notably incomplete for a tool that performs data retrieval.
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?
The description is a single, efficient sentence that front-loads the core function and capability set. No extraneous content, though it could be structured slightly better to highlight the scope (posts vs newsletters) without ambiguity. It earns points for brevity and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five optional parameters and no output schema, yet the description does not explain the return shape (e.g., list of post objects, whether metadata like total count is included), nor any limitations. Given the absence of annotations and output schema, the description is insufficient for an agent to fully anticipate the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% parameter coverage with descriptions for all five parameters. The description adds no parameter-specific detail beyond what the schema already documents (e.g., filter, page/limit, order). The baseline of 3 applies because the schema does the heavy lifting; the description merely summarizes these capabilities generically.
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?
The description uses a clear verb ('List and search') and a specific resource ('blog posts & newsletters from Ghost CMS'), plus mentions capabilities (filtering, pagination, sorting). It distinguishes itself from ghost_get_post (single post) and ghost_list_pages (pages), but does not explicitly differentiate from ghost_list_newsletters, creating slight ambiguity about overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus siblings. It does not mention when not to use it, such as when a single post is needed (use ghost_get_post) or when specifically listing newsletters (use ghost_list_newsletters). The description only states the general function, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Update an existing tag' without mentioning permissions, effects on existing data, error behavior, or return values. This is a serious omission for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with the action front-loaded. There is no extraneous information, making it optimally concise for the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and no output schema, the description is incomplete. It does not explain how partial updates work, what happens if the tag does not exist, or what the response format is. More context about expected behavior is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described (id, name, slug, etc.). The description itself adds no parameter-level semantics beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Update) and resource (tag) with scope (existing), distinguishing it from create, delete, and get operations on tags. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like ghost_create_tag or ghost_delete_tag. The description does not mention any conditions or exclusions, leaving the agent to infer from sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning default status (e.g., draft), potential side effects, or what happens on success. The schema includes a default for status, but the description does not surface this, leaving the agent unaware of default behavior.
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?
The description is a single sentence with no wasted words. It is appropriately sized for a simple creation action, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter creation tool with no output schema and no annotations, the description is minimal. It lacks information about the return value, default publish status, and when to prefer this over sibling tools. The schema covers parameters, but operational context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 9 parameters have detailed descriptions in the schema. The tool description adds no extra parameter semantics, so the baseline of 3 applies as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new static page in Ghost CMS' – a specific verb, resource, and platform. It distinguishes itself from ghost_create_post (which creates posts) by explicitly mentioning 'static page', making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like ghost_create_post or ghost_update_page. The agent must rely on the tool name and schema to infer usage context, which is insufficient for a nuanced decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action without disclosing behavior such as read-only nature, error handling, rate limits, or response format. This is a minimal, security-less description for a 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the purpose. There is no filler or redundant phrasing, making it highly concise and structurally efficient.
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?
For a simple one-parameter read tool with schema coverage, the description is minimally sufficient. However, 'full details' is vague, and no output schema or return format is specified. It lacks explicit detail on what 'full' means or any error handling, though such details are less critical for a straightforward get operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter (idOrSlug) with description 'Tag ID or slug (e.g. 'news', 'ai', or 24-hex ID)'. The tool description adds 'by ID or slug' which mirrors the schema, adding no new meaning. With 100% schema coverage, the baseline of 3 is appropriate.
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?
The description states a clear verb ('Get'), specific resource ('a tag'), and access method ('by ID or slug'). It is unambiguous and distinct from siblings like ghost_list_tags or ghost_update_tag, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like ghost_get_post or ghost_list_tags. The context for selecting this tool (e.g., needing a single tag's full details) is only implied by the verb and resource, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'update' without specifying side effects such as replace semantics for labels/newsletters, whether the member must exist, modification of subscription status effects, or error conditions. This is insufficient for an 8-parameter mutation tool.
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?
The description is a single, straightforward sentence with no wasted words. It is concise and directly states the primary purpose. It could be slightly better organized (e.g., noting replace semantics upfront), but it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 8 parameters, no output schema, and no annotations, the description should explain return values, error handling, and critical behaviors like replace vs. merge. None of that is present. The agent lacks essential context to call the tool correctly beyond what the schema provides.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are already described in the input schema. The description adds minimal meaning beyond the schema—it groups fields into 'information, labels, or subscription status' but does not clarify the replace behavior that the schema explicitly states for labels and newsletters. Baseline 3 is appropriate because the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and names the resource ('an existing member') plus the affected facets ('information, labels, or subscription status'). It clearly distinguishes from sibling tools like ghost_update_post or ghost_update_tag. It also implicitly differentiates from ghost_add_member_labels by covering all member updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like ghost_add_member_labels for incremental label additions, nor does it clarify that this tool replaces label and newsletter lists. An agent has to infer usage from the schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Add' implies a mutation, it does not disclose side effects such as email sending (send_email parameter), subscription behavior, or any permission requirements. It also does not mention whether the operation is idempotent or what happens on duplicate email. The description is too thin to inform an agent about behavioral consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. There is no extraneous information or filler. It is appropriately front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, no output schema, and no annotations, the description is insufficient. It does not explain return values (e.g., the created member object), nor does it clarify behavioral nuances such as how newsletters or email sending are handled. An agent attempting to use this tool correctly would need to infer too much from the parameter names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 9 parameters are thoroughly documented in the schema itself. The description adds no additional meaning or context beyond what the schema provides. Per the rubric, with coverage above 80%, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('member or subscriber'), making it unambiguous that this is a creation tool for members. It distinguishes itself from sibling create tools (ghost_create_post, ghost_create_tag, etc.) by explicitly naming 'member' as the target. This is a specific and non-tautological statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that ghost_update_member should be used for existing members, nor does it clarify scenarios where ghost_add_member_labels might be more appropriate. There is no context about prerequisites or when to avoid this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral nuances. It only states that it updates configuration, with no mention of side effects (e.g., effect on subscribers, validation of sender_email, or whether updates are partial or full replacement). This leaves significant behavioral ambiguity for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the verb and resource. There is zero redundancy or filler; every word contributes to the core purpose. It is appropriately sized for a straightforward update tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description is too sparse to be complete. It does not explain return values, error conditions, or any behavioral constraints (e.g., whether partial updates are allowed, though the schema suggests this). An agent calling this tool would lack context on consequences and expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for every parameter, so the schema already carries the semantic load. The description's phrase 'configuration' adds no additional meaning beyond the schema. It does not clarify ID format or any parameter-specific behavior, thus meeting the baseline without contributing extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update'), the resource ('newsletter'), and the scope ('configuration'), with identification by ID. It effectively distinguishes this from sibling tools like ghost_create_newsletter (creation) and ghost_get_newsletter (retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. The word 'existing' implicitly suggests it is not for creation, but there is no reference to ghost_create_newsletter or any condition for selection. An agent must infer usage from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it does not. It does not state whether the update is partial (only modifying provided fields) or full overwrite, nor does it mention any side effects like re-triggering webhooks or requiring specific permissions. The phrase 'update an existing post' implies mutation but leaves the exact semantics ambiguous, which is critical for a 13-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. There is no redundant information or unnecessary detail. Every word contributes to clarity without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, one required, no output schema, no annotations), the description is insufficient. It omits crucial operational details such as whether the update is partial, how missing fields are handled, or what the response contains. An agent deploying this tool would lack essential behavioral context, making it incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 100% of parameters, providing clear meaning for each field. The description adds no additional parameter semantics beyond the schema. Since schema coverage is high, the baseline of 3 applies—the description does not compensate for any gaps, but none exist in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update', the resource 'post', and specifies it operates on an existing post identified by ID. This distinguishes it from ghost_create_post (creation) and ghost_get_post (retrieval). The mention of 'by ID' adds necessary specificity without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention when to avoid it (e.g., for creating new posts or publishing and sending newsletters). The only contextual hint is the tool name implying post updates, but no comparison to siblings like ghost_update_page or ghost_publish_and_send_newsletter is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does state 'permanently', implying irreversibility, which is a key behavioral fact. However, it does not mention potential side effects (e.g., removal of associated data), permission requirements, or error conditions, leaving a significant gap for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words, front-loading the action and resource. It is concise without sacrificing clarity.
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?
For a simple single-parameter deletion tool, the description covers the core purpose. However, it does not explain the outcome (no output schema), potential consequences, or when to prefer this over related member tools, making it minimally complete but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of the only parameter ('id' with a description of '24 hex characters'), and the tool description adds no further semantics about the id or its use. The baseline of 3 applies since the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('delete') and resource ('member') with an explicit qualifier ('permanently'), making the tool's purpose unambiguous. It is clearly distinguishable from sibling delete tools (e.g., ghost_delete_tag, ghost_delete_post) by naming the member as the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as ghost_update_member or ghost_list_members. It does not provide context for deletion decisions, prerequisites, or cautionary notes, leaving the agent to infer usage purely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It implies a read-only operation ('List, search, filter') but states nothing about authentication requirements, pagination behavior, response format, or rate limits—critical gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality (list, search, filter) without any filler. It is appropriately sized for the tool's simplicity.
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?
For a simple list tool with all-optional parameters and no output schema, the description is minimally adequate. It does not explain the return format, pagination details, or NQL filter syntax beyond the schema's examples, leaving some gaps for an agent that needs to handle results or filters correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal semantic value beyond the schema; it reinforces the tool's purpose ('search' and 'filter' map to parameters) but does not elaborate on any parameter nuances, such as NQL syntax or special behaviors, beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('List, search, and filter') and a clear resource ('members/subscribers of the Ghost publication'), which fully conveys the tool's scope. It is distinct from sibling list tools like ghost_list_posts or ghost_list_tiers by naming the member resource explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, nor does it mention exclusions or conditions. An agent must rely solely on the tool name and context to infer its appropriate use, with no explicit routing away from other list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It states 'append,' which implies additive behavior, but it does not disclose error handling (e.g., invalid member ID, duplicate labels), permissions required, or whether existing labels are preserved. The description is minimal and leaves important behavioral unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action ('Append') and resource ('labels to an existing member'). No extraneous information, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description lacks guidance on when to use it, error behavior, and idempotency. It is too sparse for an agent to fully understand the implications of calling this tool, especially for a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters with clear descriptions (id as Member ID, labels as Labels to add with an example). The description adds the context of segmentation but no additional constraints or format details. Given 100% schema coverage, the description adds limited value beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Append') and resource ('labels to an existing member') with the purpose ('for segmentation'). It distinguishes from siblings like ghost_update_member (which updates multiple fields) and ghost_delete_member (deletes). An agent can immediately know what this tool does and when to reach for it.
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 description implies this tool is for adding labels only, but it does not explicitly mention when to use this tool versus ghost_update_member or other member-related tools. There is no exclusion or alternative mentioned, so the agent must infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Delete a webhook,' which implies mutation but does not disclose that deletion is irreversible, may require permissions, or what happens on failure or nonexistent IDs. This is a destructive operation lacking caveats, similar to the update_drive calibration example that scored 2.
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?
The description is a single, compact sentence that front-loads the action and resource. It is appropriately sized for a simple operation, with no wasted words. It loses one point because it omits any behavioral context that could have been added without bloat.
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?
Given the tool's simplicity (one parameter, no output schema), the description conveys the basic operation adequately. However, it lacks critical contextual details such as the irreversibility of deletion, permission requirements, or response behavior. For a destructive action, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already thoroughly documents the sole parameter 'id' with description 'Webhook ID to delete' (100% coverage). The description adds no extra semantic detail beyond 'by ID,' which aligns with the schema. Since schema coverage is high, the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (delete), the resource (webhook), and the identifier (by ID). It also scopes to 'Ghost CMS', which distinguishes it from other delete tools in the sibling list like ghost_delete_tag or ghost_delete_post. The purpose is unambiguous and directly distinguishes it from webhook create/list siblings.
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 description implies the tool is for removing a specific webhook, but it does not explicitly state when to use it versus alternatives. There is no mention of exclusions, prerequisites (e.g., needing a valid ID), or when not to use it. However, the resource-specific naming makes the intended context reasonably clear, so it earns a baseline score rather than a failing one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action but does not disclose important side effects such as the post's status change to 'published', whether the email send is immediate and irreversible, or any failure modes (e.g., what happens if the post is not a draft). For a combined mutation operation, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the primary action ('Publish a draft post') and adds the secondary action. No filler or redundancy. Every word contributes to understanding the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a combined mutation tool with no annotations and no output schema. The description fails to mention prerequisites (e.g., the post must be a draft), return value (e.g., success/failure info, newsletter ID), or edge cases (e.g., what if newsletter_id is invalid). Given the action's impact, the description is too sparse to reliably guide an agent through invocation and result handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (id, email_segment, newsletter_id) are already well-documented with descriptions. The tool description adds no extra meaning beyond the schema. Baseline of 3 is appropriate because the schema does the heavy lifting; the description does not compensate or enrich parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb–resource pair: 'Publish a draft post' and 'broadcast it as an email newsletter'. This clearly differentiates it from sibling tools like ghost_update_post (which updates posts) and ghost_list_newsletters (which manages newsletters). The combined action is unambiguous.
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 description implies a clear use case: when you need to both publish a draft and email it in one step. However, it does not mention when this combined tool should NOT be used (e.g., when you want to publish without emailing, or send a newsletter without publishing) or suggest alternatives like calling ghost_update_post and a newsletter send separately. This leaves usage boundary ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only says 'upload an image' and that it returns a URL, but omits important details such as whether the operation is idempotent, any file size/type restrictions, permission requirements, or what happens if multiple sources (filePath, imageUrl, base64Data) are provided simultaneously. This is a significant transparency gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The primary action and purpose are front-loaded, and the return type is stated. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 optional parameters, no output schema, and no annotations, the description should guide the agent on parameter selection and constraints. It fails to explain how to choose among filePath, imageUrl, or base64Data, whether multiple can be used, or what happens if none are provided. The return URL is stated but error handling and edge cases are absent, making the tool under-specified for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is already documented. The description adds value by summarizing the three source options (local path, URL, base64) and mentioning the return URL, but it does not clarify how the parameters interact (e.g., mutual exclusivity, precedence) or the meaning of 'purpose' beyond its enum. It meets the baseline for 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (upload), the resource (image to Ghost CMS), and the three input methods (local file, URL, base64). It also specifies the output (public Ghost image URL). This is specific and unambiguous, and no sibling tool offers image upload, so there is no confusion.
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 description implies usage for feature images or inline content, but does not explicitly state when to use this tool versus alternatives. Since there are no similar sibling tools, this is less critical, but there is no guidance on whether to prefer this over other methods or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does mention permanence, which signals irreversibility—a key trait. However, it does not disclose other potential side effects (e.g., cascading deletions, associated content impact) or permission requirements, so it only partially informs the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that gets straight to the point with zero wasted words. It is appropriately sized for a simple delete operation and conveys the essential action and permanence efficiently.
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?
Given the minimal complexity (one parameter, no output schema), the description covers the basic action and permanence. However, it omits any mention of side effects or prerequisites beyond that, which is a gap for a destructive operation, though not severe given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the only parameter 'id' as 'Tag ID to delete' (100% coverage). The tool description adds no additional meaning beyond the schema, so it stays at the baseline 3 for a simple single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (a tag), and the system (Ghost CMS), and adds the critical qualifier 'permanently'. This distinguishes it from sibling tools like ghost_update_tag and ghost_get_tag without needing to inspect schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no warnings about side effects. It merely states what the tool does, leaving the agent to infer its usage context from the action name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. 'Get' implies a read-only operation, but the description does not explicitly state that it has no side effects, does not require special permissions, or how it handles missing/invalid IDs. It also omits any mention of return structure or potential errors, which would help an agent understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action and object, then adds the qualifier 'by ID'. It is front-loaded and contains no filler, earning high marks for efficiency.
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?
The tool is simple (one required parameter, no output schema, no annotations), so the description provides a baseline level of completeness. However, it could be more complete by clarifying what 'configuration and stats' entails (e.g., whether the response includes demographic data, open rates, etc.) and explicitly confirming it is a read operation, given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter 'id' with a description 'Newsletter ID'. The description repeats 'by ID' without adding new meaning, such as format expectations (e.g., UUID format) or any constraints. Since schema coverage is high, a baseline of 3 is appropriate; the description does not surpass it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), resource ('newsletter'), and scope ('by ID'), distinguishing it from sibling tools like ghost_list_newsletters (listing all) and ghost_update_newsletter (modifying). The mention of 'detailed configuration and stats' adds specificity beyond a generic retrieve.
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 description implies usage for retrieving a single newsletter by ID, but does not explicitly compare with alternatives or state when to prefer this over ghost_list_newsletters or ghost_get_site_info. The guidance is implicit rather than explicit, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only says 'Get full details and content' without revealing important traits like return format nuances (despite the format parameter), authentication needs, error behavior for non-existent posts, or rate limits. This is a significant gap for a tool that could have complex response structures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that front-loads the action and resource. It avoids unnecessary words and is perfectly sized for the tool's simple purpose, making it easy for an agent to scan and understand.
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?
The tool has no output schema and no annotations, so the description is the only source of behavioral context. It does not explain the structure of the returned content (e.g., whether tags, authors, or metadata are included), nor does it discuss how the format parameter affects the output. While adequate for a basic fetch, it leaves important details that could impact correct invocation or interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with detailed descriptions for both idOrSlug and format, including an enum for format. The description adds no additional parameter-level context beyond what the schema already explains, so the baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'full details and content of a single Ghost post', and the identifier parameter 'by its ID or Slug'. It effectively differentiates from siblings like ghost_list_posts (which returns multiple) and ghost_get_page (which targets pages), making the tool's purpose unambiguous.
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 description implies usage for fetching one specific post but does not explicitly mention when not to use it or point to alternatives such as ghost_list_posts for multiple posts or ghost_get_page for pages. There is no explicit routing guidance, though the 'single' wording gives a subtle cue.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'List' without explicitly stating it is a read-only operation, pagination behavior, or any side effects. The minimal wording leaves important behavioral traits to inference, which is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource, followed by relevant examples in parentheses. It contains no redundant words and is efficiently structured, making it easy for an agent to parse quickly.
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?
Given that this is a list tool with three parameters, no output schema, and no annotations, the description is minimal. It does not mention return format, pagination defaults, or filter syntax — though the schema covers defaults. It adequately identifies the resource but leaves room for more completeness, such as noting that results are paginated or that filter uses NQL.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so each parameter (page, limit, filter) already has a description. The tool description adds no additional meaning to the parameters; it only provides examples of the resource type. Since the schema handles parameter documentation, a baseline score of 3 is appropriate, as the description neither enhances nor detracts from parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists static pages in Ghost CMS, with examples (About, Contact) that distinguish it from posts. The verb 'List' and resource 'static pages' are specific and unambiguous, making it easy to differentiate from sibling tools like ghost_list_posts.
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 description provides context that it handles static pages (as opposed to posts), but it does not explicitly mention alternatives or when not to use this tool. It lacks direct guidance such as 'use ghost_list_posts for regular posts' or any exclusions, leaving some ambiguity for an agent choosing between similar list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does state that deletion is 'permanent', which is a critical irreversible effect. However, it does not mention potential side effects (e.g., removal of related content, permissions needed, or whether the action can be undone). This is partially covered 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. The core action and key qualifier ('permanently') are front-loaded, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete-by-ID operation with one parameter and no output schema, the description is adequately complete. It covers what is deleted, how (by ID), and the permanence. Minor gaps like response format or error handling are acceptable given the simplicity and lack of complex dependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single parameter 'id' with a clear description. The tool description adds no additional meaning beyond the schema, meeting the baseline for 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete), the resource (static page), and the scope (permanently by ID). It is unambiguous and distinguishes from siblings like ghost_delete_post or ghost_delete_tag by explicitly naming 'static page'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, prerequisites, or confirmations. While the action is obvious, the description does not mention that deletion is irreversible beyond the word 'permanently' or suggest when one would choose to delete a page vs. a post.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full responsibility for behavioral disclosure. It only states what data is returned, but does not mention whether the operation is read-only, the behavior on invalid or missing IDs, authentication requirements, or any potential side effects. For a tool with no annotation safety hints, this is a significant gap, similar to the update_drive example.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and resource, then specifies the returned data categories. There is zero fluff and every word adds value. It is appropriately sized for a simple getter with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description covers the core aspects: what it returns (profile, subscription tiers, email history) and the input (via schema). However, it omits error behavior (e.g., what happens if the ID is not found) and does not explicitly state the read-only nature. Given the tool's simplicity, this is nearly complete but has a minor gap around failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameters (the 'id' field is described as 'Member ID (24 hex characters)'). The description adds no extra detail about the parameter, so the baseline is 3. Since the schema is sufficient, no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the target resource ('member'), and the scope of what is returned ('detailed profile, subscription tiers, and email history'). This distinguishes it from listing tools like ghost_list_members and other getters such as ghost_get_post or ghost_get_tag. An agent can immediately tell what this tool does and what it serves for.
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 description implies usage when you need a single member's details by ID, but it provides no explicit guidance on when to use it versus alternatives like ghost_list_members, nor does it mention any prerequisites or context. The name and verb make it clear enough for a simple getter, but there is no explicit 'when to use' or 'when not to use' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states this creates a new webhook, but does not mention side effects, prerequisites, authentication, or success/error behavior. For a mutation tool with zero annotation coverage, the description is minimally adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the primary action and purpose without any wasted words or redundancy.
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?
For a simple create operation with four parameters and no output schema, the description is adequate but thin. It does not mention prerequisites (e.g., testing connection), expected return values, or any side effects, and with no annotations, the agent is left to assume standard behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all four parameters with 100% coverage, and the description adds no extra meaning beyond the schema. The example event names in the description are also present in the schema's parameter descriptions, so it provides no incremental value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create'), a resource ('webhook'), and a scope ('in Ghost CMS') with concrete event examples ('post.published', 'member.added'). This clearly distinguishes the tool from siblings like ghost_list_webhooks and ghost_delete_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying the purpose ('for event notifications') and even lists example events. However, it does not explicitly mention alternatives or conditions when this tool should not be used, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('list all email newsletters') but does not disclose any quirks like pagination, ordering, or whether archived newsletters are included. For a read-only list operation this is minimally sufficient, but it adds no additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and resource. No filler or redundant information. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, nothing is missing. The description and schema together fully equip an agent to call it correctly. No additional context is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'include' is fully described in the schema ('Include member & post counts') with 100% coverage. The description adds no extra meaning beyond the schema, so the baseline of 3 applies. No undocumented parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the specific verb 'List' and resource 'email newsletters' on the 'Ghost CMS publication'. The word 'all' clearly distinguishes it from ghost_get_newsletter (singular) and ghost_create_newsletter. No ambiguity about what the tool does.
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 description implies usage for retrieving all newsletters, which naturally contrasts with get_newsletter for a single one. However, it does not explicitly mention when not to use it or name alternatives. It provides clear context but lacks explicit exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states a read-only listing operation but gives no details about pagination, result limits, or the structure of the response. The behavior is simple and clear (returns all webhooks), but the description lacks depth about potential side effects or environmental constraints that an agent might need to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundancy. It immediately states the purpose and resource, and is perfectly concise for a tool of this simplicity. Every word earns its place.
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?
Given the tool has no parameters and no output schema, the description is minimal. It doesn't mention what the response looks like (e.g., an array of webhook objects) or whether there are any ordering/filtering behaviors. For a list-all operation, these details could be helpful but are not strictly required. The description is adequate but leaves missing context that an agent might need to parse the response correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms an empty object. With no parameters to explain, the description adds no parameter-specific information, which is appropriate. Baseline 4 applies for 0-parameter tools, and nothing detracts from this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List') and resource ('configured webhooks in Ghost CMS'), and it distinguishes itself from sibling tools like ghost_create_webhook and ghost_delete_webhook by focusing on the listing operation. Even without explicit sibling comparison, the intent is unambiguous.
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 description implies the use case—when you need to see all webhooks—but provides no explicit guidance on when to choose this over other list tools (e.g., ghost_list_posts) or when not to use it. It doesn't mention alternative tools or exclusions, leaving the agent to infer usage from the resource name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It correctly notes the operation is permanent, which is a critical behavioral trait. However, it does not mention any other relevant aspects such as authentication requirements, irreversibility (beyond 'permanently'), or implications of deleting a post (e.g., cascading effects). The description adds minimal value beyond the word 'permanently'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that states the action and the target. There is no redundancy or filler. It is front-loaded with the key information before any ambiguity, which is ideal for agent scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter, the description provides sufficient information: what it does (delete a post), the scope (permanent), and the mechanism (by ID). No output schema is needed for a delete that likely returns a success status. It is complete for an agent to invoke correctly, though it could mention prerequisites like admin permissions, but that is not critical given the operation's clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the sole parameter 'id' with a clear specification ('Post ID (24 hex characters) to delete'). Schema description coverage is 100%, so the description adds no additional semantic value for parameters. This meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and an explicit resource ('a post permanently from Ghost CMS by ID'). It clearly distinguishes from sibling delete tools like ghost_delete_tag and ghost_delete_member by naming the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly states when to use this tool—when you want to delete a post permanently. It does not explicitly contrast with alternatives, but the action is unambiguous and the sibling set makes the resource-specific purpose obvious. No exclusions are needed for such a direct operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states 'Get full details and content' which implies a read operation, but does not disclose potential side effects (none expected), permissions, response format, or error behavior. 'Full details' is vague and could lead to assumptions about return structure. Adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and resource, then specifies the lookup method. No filler or redundancy. Every word earns its place, and the key differentiator ('static page') is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with only two parameters and no output schema, the description covers the essential purpose and identification method. However, it does not mention the format parameter or hint at the response structure, which could lead to uncertainty about what 'full details' includes. Given the schema richness, this is minor but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% – both parameters have descriptions explaining their meaning and the enum for format. The description only mentions 'by ID or Slug' which mirrors the schema and adds no new information about the format parameter or its usage. Baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'static Ghost page', and the lookup method 'by ID or Slug'. It distinguishes from siblings like ghost_get_post (posts) and ghost_list_pages (list) by specifying 'full details and content' of a single page. This is precise and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you have a page ID or slug and need full details. It clearly clarifies the target (static page vs. post) which differentiates from ghost_get_post, but it does not explicitly mention alternatives like ghost_list_pages for browsing or when not to use this tool. Slight gap but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys a read-only nature via 'list' but does not disclose pagination, sorting, response format, or the definition of 'active'. Minimal behavioral context is given beyond the core purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource. There is no extraneous wording, making it appropriately concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless list tool with no output schema, the description adequately states what it does—listing active offers and codes. It could mention pagination or fields, but the simplicity of the operation makes this level of detail acceptable. Overall, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The schema is empty and the description correctly adds no parameter information, which is appropriate as there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific verb 'list' and the resource 'active discount offers and promotional codes' in Ghost CMS. This clearly distinguishes it from sibling tools that deal with other resources such as posts, members, or tags, even without naming alternatives.
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 description implies the use case (listing offers) but provides no explicit guidance on when to choose this tool over alternatives. It doesn't mention exclusions or compare with sibling list tools, so the agent must infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It does add value by specifying that both public and internal tags are returned, and 'list' implies a read-only operation. However, it does not state the absence of side effects, mention pagination behavior, or note any rate limits—information that would be helpful given no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource, with no redundant words. It precisely conveys the scope without elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no required parameters, an output schema, or nested objects, the description is largely complete. It covers the scope (all tags, public and internal) and the schema covers all parameter details. It does not mention return format or pagination, but these are not critical for a basic list operation and are partially implied by the schema defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (limit, order, filter) have complete descriptions in the input schema, including an example for filter. The description adds no additional meaning beyond what the schema already provides, so it neither helps nor hinders. Baseline 3 is appropriate since the schema fully documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all tags') and the resource ('tags used across Ghost posts'), explicitly distinguishing between public and internal tags. This differentiates it from sibling tools like ghost_get_tag (single tag) and ghost_create_tag (mutation), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user needs an overview of all tags across posts, which is clear context. However, it does not explicitly mention alternatives or exclusions (e.g., 'use ghost_get_tag for a single tag'). The naming and scope make the use case fairly obvious, but it lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the core behavior (verifies authentication and connection), but doesn't state whether the call is non-destructive/safe, what happens on failed auth (error vs. boolean result), or what the return value looks like. The intent is clear, but operational details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler. Both the subject (self-hosted Ghost CMS) and the action (verify authentication and connection) appear immediately, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool with a simple purpose, the description covers the essential context. The only gap is what the agent can expect on success or failure, which would help an agent interpret the result, but the overall simplicity keeps this close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema carries no semantics to clarify. Per calibration, a 0-parameter tool receives a baseline of 4; the description correctly adds no parameter information because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (verify) and resource (authentication and connection to the Ghost CMS instance). It unambiguously distinguishes itself from the 34 sibling tools, which are all content CRUD operations (posts, tags, members, pages, newsletters), by being the only connectivity/auth-check tool in the set.
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 description implies usage by naming its action, but it doesn't explicitly frame when an agent should invoke it — e.g., before running other Ghost operations, or when diagnosing connection failures. It also doesn't state alternatives (like attempting a real operation to implicitly validate connectivity), so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. The description implies a read-only operation ('List') and gives insight into the contents of the response (Free, Paid, pricing, Benefits), but does not explicitly state that there are no side effects, authentication requirements, or pagination behavior. For a simple list operation this is adequate, but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that immediately states the action and resource, followed by clarifying examples. There is no waste or redundancy, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, no output schema), the description sufficiently tells the agent what the tool does and what kind of data is included. It could mention the response format or any limitations (e.g., pagination), but the absence is not a significant gap for a simple list tool. The provided details about tiers are helpful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly avoids unnecessary parameter details and the schema confirms no parameters exist. There is nothing else needed here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all membership and subscription tiers', and further clarifies the content with examples (Free, Paid, Monthly/Yearly pricing, Benefits). This distinguishes it from all sibling tools, none of which deal with tiers. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool lists tiers, but does not explicitly mention when to use it versus alternatives or any exclusions. Since there are no sibling tools for tiers, the context is sufficient and no alternative exists to differentiate, but the lack of an explicit 'when to use' statement prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses what the tool returns, effectively describing its read-only behavior and output scope. It does not mention rate limits or permissions, but for a zero-parameter get, the enumeration of return fields provides adequate transparency about the tool's effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the core action ('Get full site metadata') and then lists specific items. There is no fluff, and every word contributes to clarity. It is optimally concise for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description fully specifies the tool's purpose and expected return. It covers all relevant facets an agent would need to invoke it correctly, with no missing prerequisites or downstream effects to explain. Nothing essential is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description correctly avoids param details. Schema coverage is 100% (empty object), and the description adds nothing needed for parameters. The baseline of 4 for 0-param tools applies, and the description does not distract or omit anything relevant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get') and resource ('site info'), enumerating specific data fields (metadata, settings, title, timezone, version, navigation structure). This distinguishes it from sibling tools focused on individual entities like posts, tags, or members, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states what the tool returns, implying when it should be used (whenever site-wide metadata is needed). It does not explicitly mention exclusions or alternatives, but the tool is unique among siblings for site info, so the context is clear without needing to name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![self-hosted-ghost-admin-mcp MCP server](https://glama.ai/mcp/servers/vizionik25/self-hosted-ghost-admin-mcp/badges/card.svg)](https://glama.ai/mcp/servers/vizionik25/self-hosted-ghost-admin-mcp)

Score Badge

Copy to your README.md:

[![self-hosted-ghost-admin-mcp MCP server](https://glama.ai/mcp/servers/vizionik25/self-hosted-ghost-admin-mcp/badges/score.svg)](https://glama.ai/mcp/servers/vizionik25/self-hosted-ghost-admin-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vizionik25/self-hosted-ghost-admin-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server