Loading ToolBench
Ghost MCP server has 12 tools covering posts, pages, and tags with clear verb-noun naming. Tool definitions are present and mostly follow MCP conventions, but several critical gaps limit production readiness. All tools have descriptions (baseline: 194 chars average; these range 50-90 chars, meeting minimum but below ideal). Schemas are present for all tools with typed parameters. However, parameter descriptions are sparse or missing context, error handling is not documented, and output schemas are not visible in the provided source. The implementation uses proper factory patterns for code reuse (content-operations, tag-operations) which is good architectural practice, but the tool definitions themselves lack richness expected in production systems.
Creates a new page in Ghost blog
Creates a new post in Ghost blog
Creates a new tag in Ghost blog
Deletes a page from Ghost blog
Deletes a post from Ghost blog
Deletes a tag from Ghost blog
Lists pages from Ghost blog with pagination and filtering options
Output schemas not visible in provided source code. Cannot verify what create_ghost_post, update_ghost_post, etc. return. LLMs need documented return types to understand downstream data availability and plan multi-step operations.
Parameter descriptions are minimal or generic. Example: 'List of tag objects (each with 'name')' lacks clarity on structure. 'Filter by post status (draft, published, scheduled)' in list_ghost_posts should describe what filtering means (AND/OR logic, partial match vs exact). Baseline for param annotations is 72 chars; these average ~40-50 chars.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Lists posts from Ghost blog with pagination and filtering options
Lists tags from Ghost blog with pagination
Updates an existing page in Ghost blog
Updates an existing post in Ghost blog
Updates an existing tag in Ghost blog
No error handling guidance visible. If delete_ghost_post is called with a non-existent post_id, what error does the LLM receive? Is it retryable? Should it search for the post first? No recovery guidance means agents hit dead ends.
Destructive operations (delete_ghost_post, delete_ghost_page, delete_ghost_tag) lack confirmation or dry-run support. An agent could delete a published post without warning. Pattern:confirmation-request recommends a confirmation step for irreversible operations.
The 'tags' parameter in create_ghost_post and update_ghost_post is documented as 'List of tag objects (each with 'name')' but no schema is shown for the nested objects. What fields does each tag object require? Is 'id' optional? This ambiguity forces agents to guess structure.
create_ghost_post and create_ghost_page have 'status' parameter with enum values shown in description but not as formal enum constraint in schema (defaulting to 'draft'). Using enums prevents LLM hallucination of invalid values like 'pending' or 'archived'.
Tool descriptions are 50-90 characters, below the 194-char baseline for production tools. Example: 'Creates a new post in Ghost blog' lacks context on when to use it vs alternatives, what data is required, or what the return value contains. LLM selection accuracy suffers with minimal descriptions.
Pagination parameters in list_ghost_posts, list_ghost_pages, and list_ghost_tags lack documentation of what happens at page boundaries. Does limit=15 mean 'at most 15' or 'exactly 15'? No mention of total_count or next_cursor in response, which agents need to know before calling.
No tool annotations visible (readOnlyHint, destructiveHint, idempotentHint). The MCP spec 2026-07-28 supports tool annotations to signal tool safety. destroy_ghost_post should have destructiveHint=true; list_ghost_posts should have readOnlyHint=true.