Sentinel-MCP WordPress plugin — MCP server exposing 40+ abilities for content management, media, users, system info, WooCommerce, SEO, i18n, and more.
Sentinel-MCP demonstrates solid tool design with complete schemas, clear descriptions, and proper parameter typing across all 6 visible tools. Naming follows verb_noun convention (list-, manage-, create-, delete-, read-, search-). Descriptions are substantive (100-300 chars), explaining WHAT, WHEN, and any prerequisites. All parameters have types and descriptions. However, several patterns are underutilized: no error recovery guidance, no confirmation steps for destructive ops, no pagination metadata (total_count/next_cursor), and responses lack chaining IDs. The Gutenberg block markup requirement in create-content is well-documented but adds friction. Overall, this is a well-structured WordPress-specific toolkit that would benefit from error handling and response enrichment.
Required: title (string). Creates content in any post type (post, page, or custom CPTs). Supports title, content, excerpt, status, taxonomies (categories, tags, custom), meta fields (standard and ACF), parent page (for hierarchical), and menu order. IMPORTANT: Content MUST use Gutenberg block markup (<!-- wp:paragraph --><p>text</p><!-- /wp:paragraph -->). Plain HTML without block delimiters may be emptied by sanitization. Call "sentinel/gutenberg-reference" FIRST to get the correct block syntax. Use "sentinel/inspect-post-type" to discover available fields for the CPT.
Required: post_id (integer). Moves a post to the trash or permanently deletes it. Alias: id is also accepted instead of post_id.
All parameters optional. Lists site comments with flexible filters: by post, status, author, date range, or free text. Useful for summarizing recent comments, finding comments pending moderation, or analyzing reader engagement on a specific post.
Required: comment_id (integer), action (string). Manages a specific comment: approve, unapprove, mark as spam, trash, permanently delete, or reply. To reply, provide reply_content with the response text. Alias: id is also accepted instead of comment_id.
Required: post_id (integer). Reads the full content of any post by its ID. Includes title, content, meta, taxonomies with terms, and post type. Alias: id is also accepted instead of post_id.
No error recovery guidance in tool descriptions. When a tool fails (e.g., post not found, invalid taxonomy), the description does not tell the LLM what to do next (e.g., 'Try search-content first'). This forces agents to guess recovery steps.
Destructive operations (delete-content, manage-comment with spam/trash/delete actions) lack confirmation or dry-run support. Agents can permanently delete posts without a confirmation step, risking data loss.
List and search tools do not document pagination metadata in responses. No mention of total_count, next_cursor, or has_more. LLMs cannot determine if results are complete or if pagination is needed.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | <=2025-11-25 | v2 |
All parameters optional. Searches content across any post type by text, category, custom taxonomy, meta field, date range, or any combination of filters. Supports publish date and modified date filters to find outdated or recently updated content.
Response schemas are not documented. Tool descriptions do not specify what fields are returned (e.g., does list-comments return comment_id, author, content, date?). LLMs cannot plan downstream calls without knowing output structure.
create-content requires Gutenberg block markup (<!-- wp:paragraph -->...) but does not provide a tool to generate valid markup. The description references sentinel/gutenberg-reference, but this tool is not in the provided list. Agents may struggle to format content correctly.