Loading ToolBench
A Model Context Protocol server template written in Go that demonstrates tools, resources, and prompts with both MCP and CLI interfaces
This is a template server with three example tools. All three tools have basic descriptions and input schemas defined in the test file (tests/integration/server_test.go), but the actual tool implementation cannot be verified in the provided source. Tool names follow reasonable verb-noun conventions (search, analyze, calculate), but descriptions are generic and lack domain-specific guidance. Parameters have types and descriptions, but lack constraints (enums, ranges, defaults). No output schema is documented. Error handling is not visible in the provided code. The template nature means tool definitions are minimal and educational rather than production-grade.
Analyze text data using various methods (sentiment, keywords, summary)
Perform basic arithmetic operations (add, subtract, multiply, divide)
Search functionality (example tool - customize for your use case)
Tool descriptions are too generic and lack actionable guidance. 'Search functionality (example tool - customize for your use case)' does not explain what the search operates on, when to use it, or what results look like. Descriptions must be 50-200 characters and LLM-optimized.
Parameter 'type' in analyze tool is ambiguous. Description says 'Type of analysis to perform (sentiment, keywords, summary)' but does not declare these as an enum constraint. LLMs will hallucinate invalid values instead of picking from the known set.
Parameter 'operation' in calculate tool lists examples 'add, subtract, multiply, divide' in the description but does not use an enum schema constraint. This forces LLMs to guess valid values instead of self-completing from a formal enum.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 27 | - | v1 |
No output schema is documented for any tool. LLMs cannot plan downstream tool calls or extract return values without knowing the response structure. All tools must document their return type.
Numeric parameters 'limit' and 'a', 'b' have no documented range or bounds. LLMs can pass absurd values (negative limits, astronomical numbers) that break behavior. Constraints like 'limit: 1-100' or 'a, b: any number' must be stated.
Tool definitions are only visible in test code (tests/integration/server_test.go), not in the actual server implementation (cmd/server or internal/tools). This suggests tools are defined for testing but the runtime implementation may differ. Production tools must have explicit, visible registration in the server codebase.
No error handling guidance is visible. Tools do not describe what errors can occur, whether they are retryable, or what the LLM should do next. Error responses must be actionable.