Loading ToolBench
MCP server for interacting with Mercury banking API, providing tools for managing bank accounts, transactions, statements, and payment recipients.
Mercury MCP has 11 tools with generally adequate naming and schema coverage, but suffers from uneven description quality and missing output schema documentation. 8 of 11 tools have good verb_noun naming patterns (get_, send_, request_, add_). All tools have input schemas defined with Zod. Descriptions range from 46-188 chars, most above the 20-char minimum but several lack context about when to use vs similar tools (e.g., send_money vs request_send_money distinction is clear but output schema is not documented for any tool). Parameter descriptions are generally present but sparse (3-5 words average). No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification present in the data. Error handling uses basic try-catch with generic 'Error:' prefix but no recovery guidance for common failures (e.g., IP whitelist for send_money).
Add a new payment recipient to Mercury. You must provide the recipient's name, email(s), and default payment method, along with the appropriate routing information for the chosen payment method.
Retrieve information about a specific bank account.
Retrieve information about your bank accounts (not including treasury accounts).
Retrieve statement information for a depository account in a given time period (Note: For now, treasury and credit accounts are not supported on this endpoint).
Retrieve detailed information about a specific transaction for a specific account, including counterparty information, transaction status, and any attachments.
No output schemas documented for any tool. LLMs cannot infer what fields to expect in responses, forcing them to guess at field names for downstream tool calls. This breaks tool chaining (e.g., get_transactions returns transaction IDs, but there's no visible schema stating this).
Missing tool annotations despite clear risk stratification. send_money and request_send_money are marked IRREVERSIBLE and REVERSIBLE respectively, but inputSchema lacks destructiveHint/idempotentHint annotations. Tool definitions don't include readOnlyHint for GET tools. These annotations help LLMs reason about safety and retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 71 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Retrieve information about cards associated with a specific account. Note that status and physical card status are two separate concepts. Either one being set to something other than "active" could cause a transaction to be declined.
Retrieve information about all of your payment recipients in Mercury, including their banking details, routing information, payment methods, and status.
Retrieve incoming and outgoing money transactions for a specific bank account.
Retrieve treasury account information from Mercury.
Create an ACH payment that requires admin approval from the Mercury web interface. Unlike the direct send_money tool, this endpoint does not require IP whitelisting when using a Custom token, so ask the user to clarify if they have whitelisted their IP.
Create a new transaction for ACH payments. Note: This tool requires additional permissions and IP whitelisting with Mercury, so ask the user to clarify if they have whitelisted their IP first. If they have not, use the request_send_money tool instead. Only use for valid purposes like paying invoices or automating bill payments.
Sparse parameter descriptions. Most parameters have 1-2 word descriptions (e.g., 'Your 36-character account UUID' for id in get_bank_account_by_id). Parameter descriptions should explain format, constraints, and intent. add_payment_recipient has 20+ params with minimal description consistency.
Generic error handling with no recovery guidance. All errors caught in handlers return 'Error: <message>' without actionable next steps. Example: send_money's note says 'ask the user to clarify if they have whitelisted their IP' but the tool throws HTTP 403 with no guidance on retry or alternatives.
Weak differentiation between send_money and request_send_money. Both descriptions exist but descriptions don't clearly state: which one the LLM should use first, when IP whitelist is required, and what the approval workflow difference means in terms of wait time and reversibility.
Result limits not documented. get_transactions accepts limit param (default 500) and get_payment_recipients has no documented limit, but tool descriptions don't state max results or pagination strategy. For agents iterating over large result sets, this creates risk of context window exhaustion.
add_payment_recipient schema is complex (20+ optional params with interdependencies) but lacks documentation of which params are required together. E.g., if default_payment_method='ACH', then ach_account_number AND ach_routing_number AND ach_bank_name must all be present, but this is not stated in descriptions.