WordPress MCP server has solid tool coverage (18 tools) with complete input schemas and descriptions for all tools. However, descriptions are inconsistent in quality and depth. Many parameter descriptions are minimal (10-30 chars), and output schemas are not formally documented. Error handling exists but lacks actionable recovery guidance. The server follows basic tool patterns (verb_noun naming, required parameters, enums for constrained inputs) but misses advanced patterns like idempotency hints, permission declarations, and response field chaining. Average parameter description length is ~35 chars (below 72-char baseline). No tool annotations (readOnlyHint/destructiveHint) despite having clear risk classifications in metadata. Tools are well-composed (each does one thing), and naming is consistent and clear.
Tools (18)
create_categorywriteauthsource verified77/100
新しいカテゴリを作成します。
create_postwriteauthsource verified80/100
新しい投稿を作成します。Markdown 形式のコンテンツを指定すると自動的に HTML に変換されます。ローカル画像は自動的に WordPress にアップロードされます。
Output schemas not documented. No formal schema or description of response structure for any tool. LLMs cannot infer downstream field availability or plan tool chaining.
Tool descriptions are brief (10 - 70 chars) and lack WHEN/WHY guidance. Descriptions like '指定した ID の投稿を取得します' (Get post with specified ID) do not explain discovery, dependency, or use case. Average is ~45 chars vs 194-char baseline.
Add formal output schema definitions (in code comments or a schema registry) for all 18 tools. Specify field names, types, and cardinality. Example for create_post: { post_id: number, status: string, link: string, title: string }.
Expand tool descriptions to 150 - 250 chars following the pattern: WHAT (what does it do?) + WHEN (when should I call it?) + RETURNS (what key fields are in the response?). Example: 'Create a new WordPress post from Markdown or HTML content. Use this after confirming the post title and content with the user. Returns post_id, status, and link for updating or sharing.'
Add readOnlyHint and destructiveHint annotations to tool definitions in src/tools/posts.ts, src/tools/media.ts. Example: get_posts should have readOnlyHint: true; delete_post should have destructiveHint: true. This enables LLM safety filtering.
Enhance error handling in formatErrorResponse() to classify errors: (1) retryable (timeout, 429), (2) user-fixable (missing required field, invalid enum), (3) fatal (auth failure, resource not found). Pair each with a hint. Example: 'Post not found. Verify post_id is correct. Use get_posts() to list available posts.'
Add a dry-run or confirmation step for delete_post and delete_media. Example: add a 'confirm' parameter that defaults to false; when false, return what would be deleted; when true, perform deletion. Or implement Multi-Round-Trip Requests (result: 'input_required') to ask the user before destructive operations.
Document parameter constraints inline. For pagination (page, per_page, limit), specify ranges: 'page (integer, 1 - 10000)' and 'per_page (integer, 1 - 100, default 10)'. For enums like status, explain each option: 'publish (live), draft (saved but hidden), pending (awaiting review), private (access restricted).'
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are categorized as READ_ONLY, WRITE, DESTRUCTIVE in metadata, but not exposed as MCP annotations. LLMs cannot infer safety properties from schemas alone.
Error handling is generic. src/server.ts formatErrorResponse() returns error messages but does not classify them (retryable vs user-fixable vs fatal) or suggest recovery steps. Example: 'WordPress API Error: ...' gives no hint whether to retry, ask user, or escalate.
No confirmation/dry-run pattern for destructive operations (delete_post, delete_media). Agents can permanently delete without confirmation, risking data loss.
Parameter descriptions are sparse. Example: 'page' param in get_posts has description 'ページ番号（デフォルト: 1）' (Page number, default: 1) but omits range constraints. No mention of whether pagination is supported or what happens at the last page. Requires LLM to infer valid range.
No environment variable validation or clear secret injection pattern documented. generate_featured_image requires GEMINI_API_KEY or GOOGLE_API_KEY but no tool description explains this precondition or how to handle missing keys. CRITICAL if API key is ever logged.
Response chaining IDs not documented. Example: create_post returns a post_id, but tool description does not state what fields are in the response or how to use them in subsequent calls (update_post, delete_post, set_post_terms).
Add a precondition check tool or include it in tool descriptions: 'Requires GEMINI_API_KEY environment variable to be set. If missing, the call will fail with an error.' Consider offering a fallback (e.g., use a default image if API key is missing) or a separate fallback_image_url parameter.
In create_post and create_post_from_file descriptions, add: 'Returns post_id (use in update_post, delete_post, set_post_terms). Link is the public URL to share with users.'
Add batch operation hints: 'For bulk category or tag creation, consider calling create_category/create_tag in sequence via agent loops, or offer a create_categories tool accepting an array of { name, slug } objects to reduce round-trips.'
Document pagination behavior: For list tools (get_posts, get_categories, get_tags, get_taxonomy_terms), clarify: 'Returns page of results (max 100 items). If total > results returned, paginate by incrementing page parameter. Total count is in response metadata.'
Add security note in code: 'GEMINI_API_KEY never exposed in responses; confirm in formatErrorResponse() that API keys are scrubbed from error messages before returning to the LLM.'