Loading ToolBench
MCP server for managing and retrieving customer account information and balances
This server has two READ_ONLY tools with basic parameter schemas and minimal descriptions. Tool names use action verbs (customer_accounts, account_balance) which is positive, but descriptions are extremely brief (under 70 chars each), lack context for when to use them, and do not explain dependencies or output structure. Parameter descriptions are present but generic ('The customer ID' with no format guidance). No output schemas are documented, LLMs cannot anticipate what fields will be returned. Error handling is absent; the server does not guide recovery from failures. No input validation rules are visible. The composition is reasonable (two separate concerns), but the lack of documentation and output schema definition significantly hampers LLM usability.
Returns account balance from external API.
Returns list of accounts for a customer.
No output schemas documented. LLMs cannot predict what fields are returned by customer_accounts or account_balance. For customer_accounts, the response format (array of objects with account_id and account_type) is inferred only from code, not declared. For account_balance, the structure {"balance": <value>} is not documented in the tool definition.
Descriptions are under 20 characters and lack context. 'Returns list of accounts for a customer.' (49 chars) does not explain when to call this vs account_balance, what the output structure is, or any prerequisites. 'Returns account balance from external API.' (43 chars) does not clarify whether it requires customer_id or account_id first, or what happens on API timeout.
No error handling or recovery guidance. If get_customer_accounts fails (e.g. customer_id not found in DB), the code silently returns an empty list. If get_account_balance_api times out or receives a non-200 status, resp.raise_for_status() throws an unhandled exception. LLMs get no guidance on retrying, alternative actions, or user-fixable issues.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 32 | - | v1 |
No input validation. customer_id parameter accepts any string; the code does not check for null, empty string, or SQL injection risk (though parameterized query mitigates the latter). account_id has no format constraints documented. LLMs can pass arbitrary values.
Parameter descriptions are generic and lack format guidance. 'The customer ID' does not explain if it is alphanumeric, how long it should be (e.g. 'cust1', 'cust2'), or what happens if it is malformed. This forces LLMs to guess valid formats.
account_balance requires both customer_id AND account_id but does not document this dependency or explain which lookup to call first. An LLM might call account_balance before customer_accounts, then fail because it does not have an account_id.
No pagination or result limits. customer_accounts returns all accounts for a customer without limit. If a customer has thousands of accounts, the response could exhaust context. No limit or pagination guidance in the description.