Loading ToolBench
A Java-based Model Context Protocol server that provides authentication, account management, and calculator tools. Integrates with LangChain4j to enable AI agents to call tools via HTTP transport.
Server has 4 tools with explicit schemas and descriptions. However, descriptions are verbose and contain implementation details rather than LLM-optimized guidance. Parameter descriptions are minimal (1-3 words). No output schemas documented. Error handling is present but lacks recovery guidance. Tool naming is inconsistent: 'authentication' lacks verb prefix (should be 'authenticate'), while 'add' and 'multiply' are generic. The authentication and account tools have complex workflows documented in descriptions rather than enforced via tool composition. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present.
Adds two numbers
Authenticates a user using username and password. IMPORTANT: Don't retry for any failures. Possible outcomes: INVALID_USERNAME: Provided username is invalid. INVALID_PASSWORD: Provided password is invalid. INVALID_CREDENTIALS: Provided username and password are invalid. SUCCESS: Returns the body with the accesstoken in JSON format.
Fetches user details. This tool requires a valid access token. IMPORTANT: 1. The accesstoken argument MUST be the accessToken returned by the authentication tool. 2. Don't retry for any failures. Workflow: 1. Call authentication with username and password. 2. If authentication returns SUCCESS, extract accessToken. 3. Pass that exact accessToken to this tool. 4. Never invent an access token. Possible outcomes: INVALID_USERNAME: Provided username is invalid. INVALID_ACCESSTOKEN: Provided accesstoken is invalid. SUCCESS: Returns the user details in JSON format.
Multiplies two numbers
Tool naming lacks action verbs. 'authentication' should be 'authenticate'. 'add' and 'multiply' are generic and do not follow verb_noun convention (e.g., 'calculate_sum', 'calculate_product'). LLMs rely on names to infer intent before reading descriptions.
Parameter descriptions are minimal (1-3 words: 'Username', 'Password', 'first number'). Rubric baseline is 72 chars average. No format constraints, ranges, or validation hints provided. LLMs cannot infer parameter semantics from bare names.
No output schemas documented. Callers cannot predict response structure. 'authentication' returns accessToken in body; 'get_user_details' returns user object with id, firstName, lastName, username, avator. LLMs need documented return types to plan downstream calls.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2025-06-18+ | v2 |
Error handling lacks recovery guidance. Errors like 'INVALID_USERNAME' and 'INVALID_ACCESSTOKEN' are returned as plain strings. No actionable next steps provided (e.g., 'Try search_users() with a partial name'). Rubric requires: 'Error responses must tell the LLM what to do next.'
Tool descriptions are verbose and contain implementation details (e.g., 'Call authentication with username and password. If authentication returns SUCCESS, extract accessToken. Pass that exact accessToken to this tool.'). Rubric baseline is 194 chars; these exceed 400 chars. Descriptions should state WHAT, WHEN, and RETURN, not HOW the agent should use it.