Loading ToolBench
A lightweight MCP (Model Context Protocol) server implementation in Java with support for tools, resources, and prompts
aj-mcp exhibits a foundational MCP structure but lacks critical production-grade polish. Of 7 tools, all have basic schemas and brief descriptions, but naming conventions are weak (echoString, echoInteger use camelCase rather than verb_noun), descriptions are minimal (10-40 chars, well below the 50-200 char LLM-optimized baseline), and parameter descriptions are absent or trivial. The tools appear to be test fixtures rather than production services, longOperation, error, image, getAll are parameterless utilities with vague purposes. No output schemas are documented. Error handling exists (error tool) but lacks recovery guidance. Overall definition quality is 35/100 (D tier): definitions are minimal scaffolding, not LLM-optimized agent interfaces.
Echo a boolean input parameter
Echo an integer input parameter
Echo a string input parameter
A tool that returns a business error
A tool that returns both an image and text
A tool that returns an image
A parameterless tool that performs a long operation
Tool names violate verb_noun convention. camelCase names (echoString, echoInteger, getAll, longOperation) are not action-verb patterns. Production tools use snake_case verb_noun (e.g. echo_string, get_all). LLMs struggle to parse intent from camelCase names.
Descriptions are below LLM-optimized baseline (10-40 chars; target 50-200). Examples: 'Echo a string input parameter' (31 chars), 'A tool that returns an image' (30 chars), 'A parameterless tool that performs a long operation' (52 chars, boundary). Too brief for LLM reasoning on when to call each tool. Expand with context and purpose.
No output schemas documented for any tool. LLMs cannot predict response structure or plan downstream calls. Production tools must document return types (e.g. 'Returns: { result: string }'). All 7 tools lack this.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 19 | - | v1 |
Input parameter descriptions are absent or one-word. Example: echoString has input param 'The string to echo' (18 chars), minimal. Parameters should clarify format, constraints, and valid ranges. No parameter has min/max bounds, enums, or format specs.
Tools appear to be test fixtures, not production services. Names (echoString, longOperation, error, image, getAll) do not reflect real-world use cases. No business context or domain clarity. An LLM cannot infer when to invoke these tools in a real application scenario.
error tool has no description of what error it returns or how to handle it. Recovery guidance is absent. Production error handling must categorize failures and suggest retry strategy per RFC pattern:recovery-guide.