Loading ToolBench
Create editable Elementor product pages and blog articles with validated TOC links via WordPress REST or MCP.
This server has 11 tools with significant definition gaps. Most tools lack proper parameter descriptions and input schemas are either missing or minimal. Tool names are reasonable (buildLayout, createPage, writeElementorMeta) but descriptions vary widely in quality. Critical issue: parameters like 'builder' and 'config' in buildLayout/buildBlog have only generic object descriptions with no field-level documentation. No output schemas are documented. Error handling is absent, tools do not guide recovery or categorize failures. The two-step write pattern (createPage → writeElementorMeta) is sound architecture but not reflected in tool composition guidance.
Build a reusable long-form blog article layout with centered reading column, recurring motifs (category eyebrow, H1, meta row, featured image, linked Table of Contents, CTA card, numbered tips/steps, stat banner, comparison table, testimonial card, common-mistakes list, FAQ accordion, footer CTA, related-guides grid, author bio).
Build a reusable 15-section long-form product-page layout from a product config object and Elementor builder, returning an array of top-level sections.
Create a fresh Elementor widget-tree builder with methods for constructing sections, columns, widgets, and helper utilities for padding, backgrounds, icons, headings, text, buttons, images, icon boxes, lists, accordions, dividers, and menu anchors.
Create a WordPress page (draft by default) without heavy meta. Returns the new page id and link.
Read just the persisted _elementor_data string for a page.
Read a WordPress page in edit context (exposes meta). Returns the full page object.
buildLayout and buildBlog accept 'config' and 'builder' parameters with only generic object descriptions. No field-level documentation of what config fields are required (hero, price, images, highlights, features, etc.) or what builder methods are available. LLMs cannot infer valid structure.
No output schemas documented for any tool. LLMs do not know what fields to expect from responses (e.g., does createPage return {id, link, status} or {id, link, url, slug}?). This breaks downstream tool chaining and forces agents to guess.
No error handling or recovery guidance. Tools do not return actionable error messages. E.g., if validateTree finds problems, the response lists them but does not guide the LLM on how to fix the tree or which fields caused the issue.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 47 | 2026-07-28+ | v2 |
Probe the MCP endpoints (/wp-json/wp/v2/wpmcp and /wp-json/wp/v2/wpmcp/streamable) and report which respond to an initialize handshake.
Trash a page safely by clearing elementor meta first to avoid cleanup-hook 500s, then moving the page to trash.
Structural validator that walks the Elementor tree and returns a list of problems. Validates element structure, widget types, menu-anchor IDs (format and uniqueness), and TOC link references before writing to the network.
GET /wp/v2/users/me — confirms WordPress REST auth works and returns the authenticated user's name and id.
Write Elementor meta to an existing page id (the safe second step of the two-step write pattern). Sets _elementor_data, _elementor_edit_mode, _elementor_template_type, and _elementor_version.
builder tool has no input parameters (empty schema) and vague description ('Create a fresh Elementor widget-tree builder...'). Unclear what calling this tool does or what it returns. Is it a factory? Does it return a builder object or a builder ID?
createPage, writeElementorMeta, and trashPage are destructive operations but lack confirmation/dry-run patterns. No tool supports --dry-run or confirmation_required. Agents could accidentally publish or delete pages without safeguards.