Loading ToolBench
MCP server for interacting with Ghost CMS Admin API
Ghost MCP server has basic tool structure with schemas and descriptions present, but significant gaps in parameter documentation, error guidance, and output schema clarity. All 4 tools have descriptions (10-200 chars range) and input schemas with types, but descriptions lack actionable context for LLM selection. Parameters like 'status' and 'tags' have descriptions but lack enum constraints or format guidance. Output schemas are not formally documented, responses are JSON strings rather than structured objects. Error handling returns raw API errors without recovery guidance. No tool annotations (readOnlyHint, destructiveHint) despite clear read/write distinctions.
Create a new post in Ghost. Args: title: The title of the post content: The content/body of the post in HTML format status: Post status (draft, published, scheduled) tags: Optional list of tags to associate with the post
Debug the Ghost API connection to help diagnose issues.
Edit an existing post in Ghost. Args: post_id: The ID of the post to edit title: New title for the post (optional) content: New content/body for the post in HTML format (optional) status: New post status (draft, published, scheduled) (optional) tags: New list of tags to associate with the post (optional)
List posts from Ghost. Args: limit: Maximum number of posts to retrieve (default: 10) status: Filter by post status (all, draft, published, scheduled)
Missing enum constraints on 'status' parameter across create_post, list_posts, edit_post. Descriptions state '(draft, published, scheduled)' but no formal enum in schema, LLMs may hallucinate invalid values like 'pending' or 'archived'.
Output schemas not documented. Tools return JSON strings (e.g., create_post returns stringified JSON with 'id', 'title', 'url', 'status', 'created_at') but LLM has no formal schema to parse downstream. Breaks tool chaining, agent cannot reliably extract post_id for edit_post.
Error responses lack recovery guidance. make_ghost_request() returns raw API errors (e.g., 'Invalid API key format', HTTP status codes, response text) without actionable next steps. LLM cannot determine if error is retryable, user-fixable, or fatal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
No tool annotations. create_post and edit_post are destructive (WRITE risk) but lack destructiveHint annotation. list_posts and debug_api_connection are read-only but lack readOnlyHint. Agents cannot distinguish safe from risky tools without reading descriptions.
Parameter 'tags' in create_post and edit_post accepts array of strings but no format/length constraints documented. LLM may pass empty tags, tags with special characters, or extremely long tag names without validation.