Loading ToolBench
An MCP server that provides TypeScript documentation search and deep web search tools for a TypeScript learning assistant with voice capabilities
TySVA defines 2 tools with minimal quality standards. Both tools have basic descriptions (110-130 chars, within acceptable range) and simple input schemas with single string parameters. However, critical gaps emerge: (1) neither tool has parameter descriptions, the 'query' parameter in both tools lacks explanation of what constitutes a valid query, format constraints, or length limits; (2) output schemas are completely undocumented, callers cannot know what fields to expect or how to chain results; (3) no error handling guidance, if a search fails or returns no results, the LLM has no recovery path; (4) tool names lack action verbs, 'deepsearch_tool' and 'documentation_search_tool' are noun-heavy and do not clearly signal 'search' as the primary action (should be 'search_deep_web' and 'search_typescript_docs'); (5) descriptions lack dependency hints or context for when to select one tool over the other, an agent cannot distinguish when to use the web search vs documentation search without trial; (6) no pagination support, if either tool returns large result sets, context window exhaustion is unmanaged. These gaps cumulate to a F/D-grade implementation. The server is functional but falls well short of production quality.
Useful to search for precise information in the depths of the web when you need to answer advanced and/or complicated questions by the user about Typescript (especially debugging and errors).
Useful to search for specific information within a database containing TypeScript documentation.
Tool names do not follow verb_noun convention. 'deepsearch_tool' and 'documentation_search_tool' are suffixed with '_tool' (unnecessary artifact) and do not start with clear action verbs. LLMs struggle to infer intent from noun-heavy names.
Input parameter 'query' (both tools) has no description. LLMs cannot determine valid input format, length constraints, or example queries.
Output schemas completely undocumented. Code shows deepsearch_tool returns formatted HTML with <details> and markdown links, documentation_search_tool returns response.response, but tool definition does not specify this structure. LLMs cannot plan downstream operations or extract fields reliably.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
No error handling guidance. If LinkupClient or vector query fails, what does the LLM see? No recovery instructions, no classification (retryable vs fatal), no suggestion for fallback tools.
No pagination support. documentation_search_tool queries a vector database; deepsearch_tool calls Linkup API. Neither implements page/limit parameters or result counts. Large result sets will exhaust context window.
Tool descriptions lack decision context. Both are search tools; descriptions do not explain when to use web search vs documentation search. LLM cannot disambiguate without trial-and-error.
No constraints on query parameter. What is the max length? Are there forbidden characters? What happens if query is empty? Rubric requires format, range, and constraint documentation.