Loading ToolBench
MCP server that provides tools to search and retrieve content from electricvehicle.life blog with caching
Server has 4 tools with basic descriptions and schemas. All tools are read-only and follow a clear verb_noun naming pattern (search_*, get_*). However, descriptions are minimal (13-71 chars), schemas lack important validation constraints, parameters lack comprehensive descriptions, and error handling is generic. Output schemas are not documented. The implementation uses STDIO transport only, which is a hard cap at protocol readiness 50. Definitions are below production baseline (194 char avg description, 100% param descriptions in A+ tools).
Generate a summary and table of contents
Retrieve the complete content from electricvehicle.life
Retrieve a specific section by title/heading
Search for specific terms in electricvehicle.life content
Tool descriptions are too short (13-71 chars vs 194 char production baseline). They lack WHEN to use, WHAT dependencies exist, and WHAT the output structure looks like. Example: 'Search for specific terms in electricvehicle.life content' does not explain output format, whether results are ranked, or how to distinguish from get_section.
Parameter descriptions are incomplete or missing actionable constraints. 'context_lines' (search_content) lacks range bounds, LLMs could pass 0, -1, or 10000. 'max_length' (get_full_content) has no guidance on what happens if content is smaller. Production tools specify min/max, enum values, and format requirements in param descriptions.
Output schemas are not documented. The code returns text in a generic 'content' array, but LLMs cannot see the return structure from the tool definition, they must infer it. Production tools document: What fields? What types? Is there pagination? What are the field names and meanings?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Error handling is generic and non-actionable. Example: 'Error searching content: {error}' does not tell the LLM whether to retry, which parameter is invalid, or what the constraint violation is. Per pattern:recovery-guide, errors must guide the agent to the next step.
No pagination support. get_full_content has a max_length default of 50000 chars, but no guidance on how to retrieve content beyond that limit. Production baseline: tools returning lists should support page/offset + limit and return a total count or next_cursor.
search_content performs substring matching but does not document case sensitivity, whether regex is supported, or how results are ordered. The description 'Search for specific terms in electricvehicle.life content' is vague about behavior.
get_section has complex behavior (heading level matching, subsection inclusion) that is not documented in the tool description. LLMs cannot infer how 'include_subsections' interacts with heading hierarchy or what 'subsection' means in this context.
Tool names are verb_noun but lack specificity. 'get_section' could apply to any resource. Following production patterns, consider 'get_blog_section' or 'search_ev_content' to eliminate ambiguity when tools operate on different domains.