Loading ToolBench
MCP server for WordPress.com Reader API enabling access to WordPress Reader feeds, posts, tags, and notifications through Claude Desktop
The WordPress Reader MCP exhibits inconsistent definition quality across 11 tools. Naming follows verb-noun conventions (get_, subscribe_, follow_) and aligns with the Agentic Tool Patterns baseline. Descriptions are present but vary in quality; most are 100-150 characters and provide adequate context. Input schemas are properly defined with JSON Schema for all tools, and parameter descriptions are generally present. However, several critical gaps exist: (1) Output schemas are not documented, tools do not declare what fields agents can expect back, violating the pattern:tool and pattern:response-shaper requirements. (2) Some parameters lack sufficient constraint documentation (e.g., 'fields' parameter in getFollowingPosts accepts free-form strings rather than enums). (3) Error handling is minimal, no recovery guidance, no user-fixable vs. retryable classification, and no invalid-value-specific error messages visible in the code. (4) Tool descriptions mention warnings about truncation but do not explain what to do if truncation occurs. Pagination is implemented (number, page, fields parameters) but the documentation does not clearly state the default behavior when pagination limits are exceeded. Per-tool analysis shows 5 tools (getReaderMenu, getFeed, getFollowingPosts, getLikedPosts, getTagPosts) with reasonably complete definitions, while others (subscribeToTag, unsubscribeFromTag, followBlog) lack output schema documentation and error guidance for failures.
Follow the specified blog
Get comprehensive details about a WordPress feed including metadata, subscriber count, and feed configuration by URL or ID
Get a list of the feeds the user is following
Retrieve recent posts from all blogs and sites that the authenticated user follows in their WordPress Reader feed. Warning: Large numbers of posts may result in truncated responses.
Retrieve posts that the authenticated user has liked across the WordPress platform, with engagement history. Warning: Large numbers of posts may result in truncated responses.
Retrieve the WordPress Reader default menu with recommended tags, followed sites, and Reader sections for content discovery
Retrieve a single blog post from the WordPress Reader with full content, metadata, and engagement stats
Output schemas are not documented. Tools like getFollowingPosts, getLikedPosts, and getTagPosts return paginated lists but do not declare the structure of returned items, the pagination metadata, or how to extract relevant fields. This forces LLMs to reverse-engineer the response format and guess how to chain calls.
Write tools (subscribeToTag, unsubscribeFromTag, followBlog) lack documented error handling and success responses. No guidance on what constitutes a successful subscription or what errors might occur (already subscribed, tag not found, rate limit). Agents cannot determine whether to retry or ask the user.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 25 | - | v1 |
Get a list of posts from a tag. Warning: Large numbers of posts may result in truncated responses.
Get a list of tags subscribed to by the user
Subscribe to a new tag
Unsubscribe from a tag
Parameter constraints are incomplete. The 'fields' parameter in getFollowingPosts, getLikedPosts, and getTagPosts accepts free-form comma-separated strings without an enum or whitelist. LLMs will hallucinate invalid field names. The description mentions 'Default uses optimized field set excluding content' but does not list the actual default fields.
Pagination documentation is unclear. Tools warn 'Large numbers of posts may result in truncated responses' and mention 'default: 10, maximum: 50', but do not explain the truncation mechanism, what happens beyond the limit, or how to detect incomplete results. This prevents agents from implementing robust pagination loops.
Confidentiality checking is present in getReaderPost but not documented in the tool description. The error 'Access to content from {site} is restricted due to confidentiality settings' is thrown internally but the description does not warn that some blog contents are unreachable. Agents will be surprised when calls fail for sites without the p2_confidentiality_disabled sticker.
Tool descriptions use example values and technical jargon. Phrases like 'site domain (e.g., example.wordpress.com)' and 'numeric site ID' invite LLMs to use literal example domains. Parameter descriptions should replace examples with formal constraints (regex pattern, enum, or description of valid formats).