Loading ToolBench
Sample Spring Boot MCP Server demonstrating tool registration and MCP protocol implementation
Both tools have minimal descriptions (under 50 chars) and lack parameter documentation. Tool 1 has no input schema; Tool 2 has a single string param with no description. No output schemas documented. Naming is generic ('do_something') rather than action-specific. No error handling guidance. This server falls well below production baselines (avg tool description 194 chars, 100% of A+ tools have param descriptions).
This is a sample tool that does something
This is a sample tool that does something with a parameter
Tool 1 (sample_do_something) has NO input schema visible in code. Tool 2's param 'param' lacks any description, LLM cannot infer what value to pass.
Descriptions are 40-50 chars, below the 10 - 1024 char baseline and far below the 194-char average for production tools. 'This is a sample tool that does something' provides no context for when/why to call it or what it returns.
Tool names 'sample_do_something' and 'sample_do_something_with_param' are generic and vague. They do not start with clear action verbs (get_, create_, search_, etc.) and do not convey what actually happens. LLM cannot infer intent from the name alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 27 | 2026-07-28+ | v2 |
No output schemas documented. LLM cannot plan downstream calls or extract structured data. Tool 1 returns a string; Tool 2 also returns a string, but what does the string contain? Is it JSON, plain text, an error message?
No error handling guidance. If SomethingClient.getSomething() fails, the LLM receives a raw exception or HTTP error with no recovery hint. Per pattern:recovery-guide, errors must tell the LLM what to do next.