Loading ToolBench
A Model Context Protocol (MCP) server host implementation that integrates MCP tools with the Cloudwego Eino framework. Provides tool discovery, management, and invocation across multiple MCP servers (stdio, SSE, HTTP transports).
This MCP server implementation has critical gaps in tool definition quality. While the codebase shows a working transport layer (HTTP/SSE/STDIO) and tool registration mechanism via the Eino framework, the actual tool definitions are severely underdeveloped. Only 2 of 5 tools have explicit input schemas visible in the provided code. Descriptions are minimal and provide little actionable context for LLM selection. Parameter documentation is sparse. No evidence of error handling guidance, output schema documentation, or consideration of composition patterns. The google_search and fetch_url tools are production utilities but lack the rigor required for reliable agent use.
Fetch and extract content from a URL
Search the web using Google Search (local implementation)
sum two numbers
sum two numbers
test tool for MCP server
Tool names lack clear action verbs. 'test', 'sum1', 'sum2' are vague and generic. According to naming patterns, tool names should start with verbs like 'get_', 'create_', 'search_', 'calculate_' to guide LLM selection. 'test' does not convey what it tests or when to use it. 'sum1' vs 'sum2' are indistinguishable, why two sum tools?
Descriptions are too short and lack context. 'test tool for MCP server' (26 chars), 'sum two numbers' (15 chars) fall below the baseline of 194 chars average for production tools. Descriptions should explain WHAT the tool does, WHEN to use it, and any prerequisites. Current descriptions provide no actionable guidance for LLM selection.
Output schemas are completely undocumented. No evidence in the source that any tool declares what it returns. LLMs cannot plan downstream tool calls or extract relevant data without knowing the response structure. This violates the requirement that 100% of A+ tools have documented return types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 20 | - | v1 |
Parameter descriptions are minimal or missing context. 'Search query string' for google_search is bare; no guidance on query syntax, expected format, or length limits. 'URL to fetch' for fetch_url lacks information on supported protocols, timeout behavior, or response content types. The rubric requires that all parameter descriptions explain what the parameter controls and any constraints.
No error handling guidance or recovery paths documented. Tools that call external services (google_search, fetch_url) should explicitly describe timeout behavior, rate limits, and what errors the LLM should expect. The rubric requires error responses to tell the agent what to do next, but no such guidance is present.
No tool composition documentation. The sum1 and sum2 tools perform identical operations. According to the Composition pattern, each tool should do exactly one thing, and duplicate tools signal poor design. If both are needed for different contexts, the distinction must be documented; otherwise, one should be removed.