Loading ToolBench
MCP-compliant financial technology platform with banking, payments, and authentication integrations
The server provides 30 tools with basic descriptions and input schemas. However, there are significant and pervasive gaps in definition quality. Most tool descriptions are 1-2 sentences (averaging ~60 chars) and lack actionable context for LLM selection. Input schemas are present but minimal, most parameters have only a type and brief description; parameter constraints (enums, ranges, formats) are almost entirely absent. No output schemas are documented. Error handling is not evident in the tool definitions. Several tools expose security concerns (login credentials as parameters, sensitive payment/banking operations without rate limits). Tool naming is generally clear (verb_noun pattern mostly followed), but parameter naming lacks consistency (inconsistent use of _id suffixes, some parameters underspecified like 'status' in update_component_health without enum values). The server attempts to organize tools by domain (banking, payments, auth, health) which is good, but the definitions themselves do not support production-grade agent reasoning.
Cancel a payment.
Create a new API key for the current user.
Create a Plaid Link token for account linking. This token is used to initialize the Plaid Link flow in the frontend.
Create a new payment.
Create a new payment method.
Delete an API key.
Delete a payment method.
Credentials exposed as tool parameters: login_for_access_token accepts username and password directly; these must never be parameters. Use server-side authentication flow instead.
Missing output schemas: None of the 30 tools document their return structure. LLMs cannot predict downstream fields or compose tools without knowing what data is available after each call.
No enum constraints on string parameters: Many parameters accept free-form strings without defined valid values (e.g., 'status' in update_component_health, 'provider' in create_payment, 'type' in create_payment_method). LLMs hallucinate invalid values.
Destructive operations lack confirmation mechanisms: delete_payment_method, delete_api_key, and refund_payment are irreversible but have no dry-run or explicit confirmation step. Agents may invoke accidentally.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Exchange a public token for an access token and item ID. This endpoint should be called after a user successfully links their account through the Plaid Link flow. It stores the access token securely in the database.
Get a specific Plaid Account by ID.
Get transactions for a specific account.
Get the health status of a specific component.
Get the overall health status of the system.
Get all accounts for a specific Plaid Item.
Get payment by ID.
Get payment method by ID.
Get user payment methods.
Get refunds for a payment.
Get user payments.
Get a specific Plaid Item by ID.
Get all Plaid Items (linked bank accounts) for the current user.
List all API keys for the current user.
OAuth2 compatible token login, get an access token for future requests.
Refresh access token using a refresh token.
Refund a payment.
Register a new user account. This endpoint is public and does not require authentication. The first user to register will be created as an admin.
Set a payment method as default.
Sync accounts for a specific Plaid Item. This updates the account information and balances from Plaid.
Sync transactions for a specific Plaid Item.
Sync payment status with provider.
Update the health status of a component.
Insufficient parameter descriptions: Most parameters have only 1-2 word descriptions (e.g., 'Plaid Item ID', 'Payment ID'). No guidance on format, constraints, or valid ranges. Parameter 'days' in sync_item_transactions states '1-90' in description but no schema validation.
Tool descriptions lack context for LLM selection: Most descriptions are 1-2 sentences (avg ~60 chars vs. 194 char baseline). They state WHAT but not WHEN to use or any prerequisites. E.g., 'Sync payment status with provider', when should this be called vs. get_payment?
No error recovery guidance: Tool definitions provide no recovery hints. If exchange_public_token fails, what should the LLM do next? There are no actionable error messages defined.
No rate limiting or risk declaration: create_payment and refund_payment modify financial state but have no rate limits, idempotency keys, or risk annotations. Runaway agents could generate duplicate charges.
Missing pagination info: get_payments and get_payment_methods accept skip/limit but response structure is undocumented. No total count, has_more flag, or guidance on default limits.
Inconsistent ID parameter naming: Some params are 'item_id', 'account_id', 'payment_id'; others are 'method_id', 'api_key_id'. Inconsistency makes it harder for LLMs to infer which tool outputs match which inputs.
No human-readable alternative identifiers: All tools require opaque IDs (item_id, account_id, payment_id, method_id). No option to use email, username, or user-facing names. Forces extra lookup calls.