Mercury Banking MCP server with full Invoicing API support — accounts, transactions, recipients, customers, invoices (one-shot + recurring), webhooks.
26 tools with consistent naming (verb_noun pattern: list_, get_, create_, update_, delete_) and basic descriptions. However, descriptions are uniformly terse (10-40 chars), falling below the 50-200 char LLM-optimized baseline. Input schemas are present for most tools but lack depth: parameter descriptions are minimal, no enums for constrained values (e.g., paymentMethod, status, events), no min/max bounds on numeric fields. Output schemas are not documented. Error handling is absent, no recovery guidance or actionable error messages. Security: API key injected server-side (good), but no permission gates on destructive tools (delete_webhook). Composition is sound, tools are single-responsibility and chainable (e.g., list_accounts → get_account → list_transactions). Overall: functional but underspecified for LLM reasoning.
Add a new payment recipient
Create a new webhook
Delete a webhook
Get account details by ID
Get credit product details
Get customer details
Get invoice details
Descriptions uniformly terse (10-40 chars). LLM-optimized descriptions should be 50-200 chars, explaining WHAT the tool does, WHEN to use it, and any prerequisites. Current descriptions lack context for tool selection.
No enums for constrained parameters. paymentMethod, status, events, and other categorical fields accept free-form strings, inviting hallucinated values. Declare enums (e.g., paymentMethod: [domesticAch, wire, check]) to guide LLM selection.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Get organization details
Get transaction details
Get treasury information
Get webhook details
List all accounts
List cards for an account
List transaction categories
List available credit products
List customers
List attachments for an invoice
List invoices
List payment recipients
List account statements
List transactions for an account
List treasury statements
List treasury transactions
List webhooks
Update a payment recipient
Update a webhook
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields without knowing response structure. Document return types for all tools, especially list_* (include pagination fields, total count, next_cursor).
No error handling guidance. Tools lack recovery hints (e.g., 'User not found. Try search_users() first.'). Errors should categorize as retryable, user-fixable, or fatal, and include the invalid value and constraint violated.
Destructive tool (mercury_delete_webhook) lacks permission gates or confirmation step. Agents should not silently delete webhooks. Implement a dry-run or explicit confirmation pattern before executing irreversible operations.