Loading ToolBench
A multi-server MCP ecosystem with billing and email servers using Spring AI MCP, plus an orchestrator client using Google ADK
This server exposes 3 tools with severe structural and documentation deficiencies. While schemas are present and parseable, descriptions are critically inadequate, parameter documentation is minimal, security considerations around sensitive financial and email data are not addressed, and output schemas are entirely undocumented. The tools handle WRITE operations (billing, payment, email) without error handling guidance, confirmation mechanisms, or security scope declarations. Tool naming is inconsistent: 'authorizeBilling' uses camelCase (not verb_object), 'processPayment' similarly deviates from standard naming conventions, and parameter descriptions lack essential context about formats, constraints, and validation rules.
Authorize the billing process for a customer
Process the payment for a customer
Send an email to the specified recepient with the given subject and body
Tool names do not follow verb_noun convention. 'authorizeBilling' and 'processPayment' use camelCase; standard MCP conventions expect 'authorize_billing' and 'process_payment'. This breaks LLM parsing of intent from the name alone.
Descriptions are critically short and lack WHAT/WHEN/WHY context. 'Authorize the billing process for a customer' (49 chars) does not explain when to call this vs other billing tools, what 'authorize' means in the domain, or what happens on success/failure. Baseline for A+ tools is 50-200 chars with explicit guidance.
Parameter descriptions are missing or minimal. 'billId' has description 'Customer Billing Id' (19 chars, below threshold of 20), does not explain format, constraints, or how to obtain one. 'cardNumber', 'cardExpiry', 'cardCvv' lack any description, violating the pattern:tool-description baseline of 100% parameter documentation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Sensitive financial data (cardNumber, cardCvv, cardExpiry) exposed as tool parameters. MCP pattern:secret-injection mandates server-side secret injection via environment variables or vault. Credentials in parameters leak into agent logs and prompt history. This is a critical security violation.
No output schema documented for any tool. LLMs cannot determine what fields to expect or plan downstream tool calls. Pattern:tool baseline is 100% of A+ tools have documented return types. Users cannot chain tools without guessing output structure.
No error handling guidance. Destructive WRITE operations (authorize billing, process payment, send email) have zero recovery guidance. Pattern:recovery-guide requires: 'Error responses must tell the LLM what to do next.' Missing error classification (retryable vs fatal), confirmation mechanisms for irreversible operations, and idempotency hints.
No security scope declarations. Each tool should declare required permissions (e.g., 'write:billing', 'read:email'). Pattern:scope-declaration baseline requires explicit permission gates for sensitive tools. Missing scope declarations prevent least-privilege agent configurations and audit trails.
Parameter constraints undocumented. 'cardExpiry', expected format? MM/YY, MM/YYYY, ISO date? 'cardNumber', validates Luhn check? Accepts only digits? 'recipient', must be valid email? None of these are stated. Pattern:constrained-input baseline requires explicit format, range, and enum constraints in descriptions.
No idempotency hints or confirmation pattern. Financial operations (processPayment) and email (send_email) are inherently non-idempotent, repeated calls with same input cause duplicate charges or emails. Pattern:idempotent-operation requires explicit guidance on idempotency or confirmation/dry-run steps.
No tool annotations present. Tools lack destructiveHint/readOnlyHint/idempotentHint metadata that current MCP spec (2026-07-28) recommends for flagging WRITE operations and guiding LLM planning. This metadata is optional but recommended for production financial/email tools.