Loading ToolBench
MCP server that indexes WordPress hooks, blocks, APIs, and official documentation — exposing them as queryable tools to AI assistants
This server defines 13 tools with reasonable naming and mostly complete descriptions, but exhibits significant gaps in schema documentation, parameter descriptions, and error handling guidance. Tool names follow verb_noun conventions (search_*, get_*, list_*, add_*, remove_, index_*) which is good for LLM clarity. Descriptions are present for all tools and average 120-150 characters, which is adequate. However, critical issues emerge: (1) parameter descriptions are sparse or absent in several tools; (2) no documented output schemas despite returning structured data; (3) no error handling guidance; (4) destructive operations (remove_source, index_sources with force=true) lack confirmation patterns; (5) some tools accept vague parameters like 'source' without clear format constraints. The server targets WordPress developers with read-heavy operations (10 of 13 tools are READ_ONLY), which reduces risk, but the WRITE and DESTRUCTIVE tools need stronger guardrails.
Add a new documentation or code source to index (GitHub, local folder, etc.)
Get detailed information about a specific configured source
Get indexing statistics (total hooks, blocks, APIs, docs, theme.json properties indexed)
Get detailed information about a specific theme.json property by path
Index all enabled sources or a specific source to extract hooks, blocks, APIs, docs, and theme.json properties
List all configured sources with their configuration and indexing status
Remove a source and all its indexed data (hooks, blocks, APIs, docs, theme.json)
Search for WordPress API usages (function calls, methods, namespaces)
Output schemas not documented. Tools return structured results (docs with title/slug/category, hooks with metadata, stats objects) but no return schema is provided. LLMs cannot plan downstream operations or extract the right fields without knowing what fields exist in responses.
Destructive tool (remove_source) lacks confirmation/dry-run pattern. Removing a source and all indexed data is irreversible, but the tool description does not mention a confirmation step or offer a dry-run mode. Agents can accidentally delete indexes without user approval.
Parameter format constraints missing. add_source accepts 'repo_url' and 'local_path' but does not specify regex patterns, URI schemes, or path validation rules. An LLM cannot determine valid input without these constraints and may pass malformed URLs or paths.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Search for registered WordPress blocks by name, title, category, or attributes
Search WordPress documentation by title, slug, category, description, or content
Search for WordPress hooks (actions and filters) by name, type, docblock, or context
Search theme.json configuration properties by path, context, description, or value origin
Validate whether a hook name exists and get its metadata
Vague parameter 'source' in index_sources. The 'source' parameter is described as 'Optional: specific source name to index (if omitted, indexes all enabled sources)'. It is unclear whether this accepts a source name (string) or a source object, and no examples or format constraints are provided. This ambiguity invites incorrect LLM invocations.
No error recovery guidance. None of the tools document what happens on failure or what the LLM should do next. For example, search_docs could fail due to database corruption, network issues (if fetching sources), or invalid queries. The tool descriptions do not hint at retry strategies or alternative tools.
Pagination not documented for search tools. search_hooks, search_blocks, search_apis, search_docs, and search_theme_json_properties all accept 'limit' but do not mention offset, cursor, or total_count in results. If a search returns 1000+ matches, the agent cannot know whether to request more or if results are complete.
token_env_var parameter in add_source is confusing. The parameter is described as 'Environment variable containing GitHub token (for github-private)' but it is unclear whether the tool reads the env var at execution time (runtime) or expects the agent to pre-set it. If the agent must set it, this tool cannot be used dynamically. If the tool reads it, the description should say 'Name of an environment variable that will be read at execution time'.
No indication of which parameters are mutually exclusive or required together. In add_source, repo_url is required for github-public and github-private but optional for local-folder. However, local_path is required only for local-folder. These dependencies are not documented, forcing the LLM to guess correct parameter combinations.
Response field naming conventions not documented. If search_docs returns a list of document objects with fields like 'doc_id', 'title', 'slug', 'category', and 'content', but add_source requires 'local_path', the naming is inconsistent (snake_case is used, but no documentation of which fields are returned by each tool). This makes it harder for LLMs to chain tool calls.