Loading ToolBench
Multi-AI server with MCP integration supporting Gemini, Ollama Cloud, and WordPress MCP Tools. Provides chat interface, AI management, backup services, and folder organization.
This server has 13 tools with highly inconsistent quality. Exa tools (3) have complete schemas and reasonable descriptions (baseline 194 chars met). WordPress tools (7) have minimal descriptions (10-30 chars, well below 194 baseline) and lack output schema documentation. Vision/image tools (2) have sparse documentation. Critical gaps: no output schemas for ANY tool, no error handling guidance, no parameter validation rules, missing type annotations in some parameters, and no tool annotations (readOnlyHint/destructiveHint). The naming is generally verb-first (good: exa_search, wp_create_post, wp_update_post) but several WordPress tools lack specificity (wp_get_posts is ambiguous about what 'get' returns). Average across 13 tools: 52/100.
Find web pages similar to a given URL using Exa AI's semantic similarity.
Get full content, highlights, or summaries for specific Exa search result IDs.
Search the web using Exa AI's neural semantic search. Returns high-quality, relevant results with full content.
Generate an image using AI and save to Media Library
Analyze an image using AI vision
Count posts by status
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract return values reliably. The server registers input schemas but provides no descriptions of what fields/types are returned.
WordPress tools have dangerously short descriptions (10-30 chars). 'List installed WordPress plugins with their versions' (55 chars) and 'Retrieve WordPress posts. Returns 10 by default' (48 chars) lack context for LLM selection. Baseline is 194 chars; these fall well short. No guidance on when to use wp_get_posts vs wp_get_post, or what fields are populated.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Create a new WordPress post or page
Get a specific post by ID with all its data
Retrieve WordPress posts. Returns 10 by default
Get WordPress users. Returns 10 by default
List installed WordPress plugins with their versions
Update an existing WordPress post
Download image from URL and add to WordPress Media Library
No error handling guidance. When wp_create_post fails (invalid post_type, permission denied, or content too long), the tool returns an error but provides no recovery path. LLMs cannot distinguish retryable errors from user-fixable ones.
Write tools (wp_create_post, wp_update_post, wp_upload_media, mwai_image) lack destructiveHint or idempotentHint annotations. Protocol spec 2026-07-28 requires tool annotations to signal side effects. LLMs need this to plan confirmations and understand retry semantics.
Parameter descriptions lack validation rules. 'limit' parameter on wp_get_posts, wp_get_users: no range specified (min/max). 'post_status' and 'post_type': no enum values documented. LLMs cannot validate input and may pass invalid values like post_status='uncertain' or post_type='blog'.
Exa tools (exa_search, exa_find_similar, exa_get_contents) have no guidance on dependencies. exa_get_contents requires IDs from exa_search output, but the relationship is not documented. Description should state 'Call exa_search() first to obtain result IDs, then pass them here.'
No pagination metadata or limits declared. wp_get_posts returns '10 by default' but no maximum; wp_get_users same. No mention of total_count, next_cursor, or offset. LLMs cannot plan multi-page queries or understand when results are truncated.
WordPress tools accept opaque 'ID' integer parameters (wp_get_post, wp_update_post) with no guidance on how to obtain them. Should accept post_name or slug as well to match chat data model (users say 'my first post', not 'post 42'). Current design forces unnecessary lookup calls.
Exa API key exposed as environment variable EXA_API_KEY in exa-tools.js. Per pattern:secret-injection, credentials should never appear in parameter definitions. Current design is safe (server-side injection via .env), but worth noting that if tool ever exposed EXA_API_KEY as a parameter, it would leak into LLM traces.