Loading ToolBench
MCP server for the Aspire financial API, providing tools to query accounts, balances, transactions, cards, users, and transfer status
Server defines 11 read-only tools with complete input schemas and descriptions. Naming follows verb_noun convention (aspire_*) and is consistent. Descriptions are adequate (100-200 chars typical) and explain WHAT each tool does. However, parameter descriptions lack depth, many are single-phrase (e.g., 'Aspire account UUID', 'Card UUID') without guidance on format, constraints, or when to use. Output schemas are not documented in the tool definitions. Error handling is absent from descriptions. No tool annotations (readOnlyHint, idempotentHint) despite all being read-only. Composition is sound: tools are single-purpose and chainable (e.g., aspire_accounts → aspire_balance). No security issues detected (read-only, no secrets in params). Baseline: avg tool description ~150 chars (within 10 - 1024 range), but param descriptions average ~30 chars (below 72-char baseline for A+ tools).
List all Aspire accounts with their available balances, currency, type and status. Balances are returned in minor units (cents) plus a formatted major-unit value. Use this first to discover account IDs.
Check the available balance of one Aspire account by its account ID.
Check the status of a bulk transfer by bulk transfer ID.
View one card's metadata by card ID. Does not return sensitive card details.
List all cards on the Aspire account. Does not return sensitive card numbers.
Find every transaction involving a counterparty (substring match on the counterparty name) and total it by year, currency and direction. If nothing matches, returns similar names as suggestions. Use this for questions like 'how much did we pay X last year'.
Parameter descriptions are minimal (avg 30 chars vs 72-char baseline). E.g., 'Aspire account UUID', 'Card UUID', 'Transfer UUID' lack format guidance, constraints, or when-to-use context. LLMs cannot infer whether to pass a display name or system ID.
No output schemas documented. Tool definitions show input schemas but omit return types. LLMs cannot plan downstream calls or extract required fields (e.g., does aspire_accounts return account_id for use in aspire_balance?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Check an existing FX quote by quote ID. Does not create quotes.
List the reporting fields configured on the Aspire account.
List transactions over a date range, following pagination automatically. start_date is required. Amounts are in minor units; negative means debit (money out). Optional filters narrow by account, currency, direction, or channel.
Check the status of a single transfer by transfer ID.
List users on the Aspire account.
No tool annotations despite all tools being read-only. Missing readOnlyHint and idempotentHint annotations prevent clients from optimizing caching and retry logic.
No error handling guidance in tool descriptions. If a transfer_id or quote_id is invalid, what should the LLM do? Descriptions lack recovery hints (e.g., 'If not found, try aspire_transactions to discover valid IDs').
aspire_transactions accepts 'type' parameter (debit/credit) but description does not clarify whether 'debit' means money out or in. Ambiguous parameter semantics force LLMs to guess.