Exposes safe, purpose-built abilities so CLIs and AI agents can work with WordPress through the Abilities API.
NiranzWP demonstrates solid tool design with 13 well-structured WordPress-specific tools. All tools have descriptions (194 - 350 chars, within baseline 34 - 392 range) and explicit JSON schemas with typed parameters. Naming follows verb_noun convention (site-info, list-plugins, block-read, block-write). However, several parameter descriptions lack actionable detail (e.g., 'target' in block-write omits path format examples), and output schemas are minimal (type: object only, no field documentation). Error handling is implicit rather than explicit, no recovery guidance in descriptions. Security annotations present (readonly/destructive flags) but no permission scope declarations. Block manipulation tools (block-write, block-update, block-move) are sophisticated with dry-run defaults and SHA256 conflict detection, showing strong safety patterns. Overall: good baseline quality, but parameter descriptions and output documentation need expansion to reach A-grade.
Reports total autoloaded option size and the largest entries. Autoloaded options are read on every request, so bloat here slows the whole site.
Finds blocks in a post by type, by an attribute they carry, or by the text they show, and reports the path of each - which is how block-update, block-move and block-write name a block. Searches the whole tree, however deep.
Moves one block to sit before, after, or inside another. Refuses to move a block into itself, which would take the branch out of the post. Paths are re-read after the block is lifted out, so the destination means where it was before the move.
Returns a post's content as a parsed block tree with names and attributes, rather than raw markup.
Returns one block type's attribute schema, supports, parent and ancestor constraints, so its attributes can be set correctly the first time.
Output schemas are minimal (type: object only) with no documented field structure. LLMs cannot infer what fields to expect or plan downstream tool calls. E.g., site-info, list-plugins, autoload-report lack field documentation.
Parameter descriptions lack actionable format/constraint details. E.g., 'target' in block-write says 'path block-read reports' but doesn't explain path format (is '2.1' valid? what's the max depth?). 'command' in run-wp-cli lacks examples of valid syntax.
No explicit error handling guidance in tool descriptions. Destructive tools (block-write, block-update, run-wp-cli) do not document what errors are retryable vs fatal, or how to recover from conflicts/failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Lists the block types registered on this site, so content is composed only from blocks that actually exist here.
Changes the attributes of one block, named by its path. Merges into what the block already has unless replace is true, checks the result against this site's registry, and reports the before and after unless dry_run is false.
Adds, replaces or removes blocks in a post. Appends or prepends at the top level, or acts on one block named by its path - after, before, replace-block, delete - and replace discards the whole body. Validates every block name and attribute against this site's registry first, snapshots the post, and previews unless dry_run is false.
Lists installed plugins with version and active state. Optionally only the active ones.
Purges LiteSpeed, W3 Total Cache and the WP object cache. Give post_ids or urls to purge only those; scope "all" empties everything, which on a large site means rebuilding every page from the database at once. Does not reach an external CDN such as Cloudflare.
Runs a WP-CLI command against this installation and returns stdout, stderr and the exit code. Reports what it would run unless dry_run is false. Requires the wp binary and shell execution on the host.
Returns the site name, URL, WordPress and PHP versions, active theme and locale.
Reports whether WP-CLI can run on this host: shell availability, the resolved wp binary and its version.
Permission scope declarations missing. Tools declare readonly/destructive annotations but not what capability or role is required (e.g., 'manage_options', 'edit_posts'). Audit trail requirements not documented.
block-find's 'value' parameter has no type constraint (description only). LLMs cannot determine if it expects string, number, boolean, or array. Should be typed or enum-constrained.