This WordPress MCP server has 27 tools with broadly adequate schemas and descriptions, but exhibits systematic quality gaps that prevent a higher rating. Naming follows verb-first conventions consistently (list_, get_, create_, update_, delete_). However, descriptions are uneven in quality and length, ranging from adequate (40-100 chars) to minimal (20-30 chars). All tools have input schemas with typed parameters, which is a significant strength. The server lacks output schema documentation, responses are undocumented, forcing LLMs to infer structure. Error handling exists at the framework level (catch blocks in server.ts) but tools do not return actionable recovery guidance. No security annotations (destructiveHint, readOnlyHint) are present despite many tools modifying state. The tool set is reasonably composed (list + get + create/update/delete patterns are present), but several clusters (e.g., 6 FluentCart analytics tools) suggest possible over-fragmentation or scope bloat. Baseline comparison: 19/27 tools (70%) have descriptions >30 chars, which is acceptable but below the 94% A+ threshold. All 27 tools have typed input schemas, which is strong. Output schemas are entirely undocumented.

• Add output schema documentation for every tool. For example, list_comments should document: 'Returns {comments: [{id: number, author_name: string, content: string, date: ISO8601}], total: number, page: number}'. This enables LLMs to chain results and extract fields correctly.
• Implement tool annotations in the server. Add readOnlyHint: true to all get_* and list_* tools; add destructiveHint: true to delete_comment; add annotations at registration time or in tool metadata. This aligns with MCP spec 2026-07-28.
• Expand descriptions for debug and analytics tools. Replace vague descriptions with WHEN/WHY guidance. Example: 'Call fmcp_get_site_context first on a new site to discover installed products and ENABLED_TOOLS categories. Required before calling product-specific tools.' and 'Get quick stats (today's sales, pending orders) for dashboard overview. For detailed analytics by product or date range, use fcart_get_analytics.'
• Standardize parameter descriptions. Add format examples and constraints explicitly. For date parameters, write: 'ISO8601 date string, YYYY-MM-DD format, e.g. 2024-01-15. Time ignored; use start of day in UTC.' For enums, write: 'One of: approve, hold, spam, trash. Default: approve.' not just the enum list.
• Consolidate overlapping analytics tools. Clarify in descriptions which tool to call: 'fcart_get_quick_stats for real-time dashboard (small payload). fcart_get_reports_overview for sales/revenue summary over a date range. fcart_get_analytics for detailed breakdown by product, customer, or type.' Remove duplication or provide clear dispatch logic.