Loading ToolBench
A collection of MCP servers built with Quarkus that provide tools for managing person and account data
This MCP server has 3 read-only tools with basic naming following verb_noun convention (getPersonsByNationality, getPersonById, getAccountsByPersonId). However, significant gaps exist: descriptions are minimal (10-40 chars), input schemas lack detailed parameter descriptions, output schemas are not documented, and there is no error handling guidance. The tools appear to be inferred from test files rather than explicitly registered in source code visible in the provided materials. Tool names follow action verbs but descriptions are too brief to guide LLM selection. Parameters have types but lack context descriptions (e.g., 'The nationality to filter by' is minimal; 'The person ID' does not clarify the format or expected range). No pagination, result limits, or chaining IDs documented. No security considerations (credentials, permissions, audit trails) are evident.
Get accounts for a specific person by their ID
Get a specific person by their ID
Get persons filtered by nationality
Descriptions are critically short (<40 chars).
Input parameter descriptions are absent or trivial. E.g., 'The nationality to filter by' is bare; should explain format (e.g., 'ISO 3166-1 alpha-2 code or full name'), provide examples ('USA, United Kingdom'), and guide when to use (e.g., 'Call getPersonsByNationality to filter a large population; if you know the exact ID, use getPersonById instead'). Baseline: 100% of A+ tools have parameter descriptions; this has none.
Output schemas are not documented. Callers cannot predict which fields (e.g., person_id, name, email, nationality) will be returned, preventing LLMs from planning downstream tool calls or extracting the right data. Baseline: 100% of A+ tools have documented return types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 45 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 32 | - | v1 |
No pagination or result limits documented. If getPersonsByNationality returns thousands of matches, context is blown and token cost soars. Baseline pattern: tools returning lists should accept limit/offset and state a cap (20-50 items default) in the description.
No error handling guidance. If getPersonById receives an invalid ID or non-existent ID, the response is not documented. Per pattern, errors should be actionable: 'Person not found (ID: 999). Try getPersonsByNationality to find by nationality instead.' Currently, an LLM would get a bare error and have no recovery path.
Tool registration is inferred from test files (PersonToolsTest.java, AccountToolsTest.java), not visible in explicit source registration. Per HARD SCORING RULE: if tool definitions are inferred rather than explicitly visible, cap per-tool score at 50. This limits overall confidence in production readiness.
No tool composition guidance. Callers need to know: does getPersonsByNationality return person_id? If yes, can that ID be passed directly to getAccountsByPersonId? Or must caller invoke getPersonById first? Tool chaining IDs are not documented, forcing discovery detours.
No security considerations documented. No mention of permissions (can any user/agent call these tools?), audit logging (who called what, when?), or scope declarations (read:person, read:account). Baseline: each tool should declare required permissions.