Loading ToolBench
A multi-server MCP application providing blog management, email handling, and RAG-based file/knowledge retrieval from an Obsidian vault.
This MCP server exhibits significant definition quality gaps across all tools. While tool names generally follow verb_noun conventions (list_posts, get_post, create_post, etc.), the descriptions are often too brief (many under 50 chars) and lack the actionable detail needed for LLM-driven selection. Parameter descriptions are sparse or missing entirely. Schemas are present for most tools but lack depth in documentation of constraints, formats, and ranges. No error handling guidance is visible in the tool definitions. The server registers 10 tools via fastmcp framework, but the definitions would not pass production code review.
Create a new blog post.
Delete blog post(s) by ID.
Utilize the vector database to retrieve relevant chunks to answer a query.
Returns the ID of the most recently created BlogPost
Get a specific blog post by ID.
Check all blog post titles for a specific keyword
List all blog posts.
Descriptions are uniformly too brief (most under 50 chars). Baseline for A-grade tools is 194 chars. Examples: 'List all blog posts.' (20 chars), 'Returns the ID of the most recently created BlogPost' (51 chars), 'Check all blog post titles for a specific keyword' (49 chars). These descriptions lack context about WHEN to use the tool, what it returns structurally, and dependencies.
Parameter descriptions are missing or minimal. For example: update_post has params 'id' (description: 'BlogPost to be updated', ambiguous), 'title' (no description of format/length), 'content' (no description of format, markdown requirements), 'tags' (no description of valid tag format or limits). LLMs cannot infer valid ranges or formats from names alone.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 49 | - | v1 |
List the latest emails in your inbox.
Send an email to a specified recipient.
Update a specific BlogPost.
No error handling guidance visible in tool definitions. Destructive operations (delete_posts) have no mention of confirmation, dry-run, or recovery steps. create_post has no guidance on conflicts (duplicate titles) or validation failures. send_email has no error recovery path (e.g., 'if mail server is down, try again in 60 seconds').
No output schema documentation. Tool descriptions do not specify what fields are returned. For example, list_posts returns a list of posts, but the response format is not documented, does it include timestamps? Tags as array or comma-separated string? Total count for pagination?
No pagination guidance. list_posts and read_emails lack limit, offset/page_number, and total_count parameters and descriptions. Tools returning lists should follow the paginated-result pattern to avoid context window exhaustion and support reasonable limits (20-50 items default).
Naming ambiguity: list_keyword_post_ids, LLM may confuse this with a general search tool. Does it search titles only or also content? Does it return post summaries or only IDs? The name does not clearly convey 'search by keyword in post titles'. Better name: search_posts_by_keyword or find_posts_with_keyword.
Parameter naming inconsistency: get_post uses 'post_id' (integer), but update_post and delete_posts use 'id' for the same resource. This forces LLMs to reason about field mapping instead of consistent naming across tools operating on the same resource.
No enum constraints. For example, send_email does not specify email format validation or mention of required fields (to, subject both required? body optional?). create_post does not constrain title length or content format. LLMs will guess, leading to invalid inputs.
No idempotency guarantees documented. Tools like create_post do not state whether duplicate calls with the same title/content will return the same post or create duplicates. Agents retry on ambiguous failures, without idempotency guarantees, side effects occur.
Destructive tool (delete_posts) lacks confirmation or dry-run pattern. No mention of confirmation, reversibility, or audit trail. A production system should require explicit confirmation for destructive operations to prevent accidental mass deletion.