Loading ToolBench
This MCP server wraps the Up Bank API with 13 tools. Strengths: all tools have names starting with action verbs (get*, patch*, post*, delete*), all have brief descriptions, and input schemas are explicitly defined using Zod with type information. Weaknesses: descriptions are extremely minimal (10-25 chars, well below the 50-200 char optimum for LLM decision-making), parameter descriptions are often generic or missing context, output schemas are not documented in the tool definitions, and error handling guidance is absent. The server uses auto-generated tool schemas from an OpenAPI spec (via orval), which accounts for consistency but also for the lack of LLM-optimized prose. Most tools are READ_ONLY (11/13), but write operations lack confirmation/dry-run patterns. Based on baselines: average param description should be ~72 chars but most here are 40-60 chars with minimal context.
Remove tags from transaction
List accounts
List transactions by account
Retrieve account
List attachments
Retrieve attachment
List categories
Tool descriptions are extremely brief (10-25 chars, e.g. 'List accounts', 'Retrieve account'). Current descriptions lack context on WHEN to use, WHAT to do with results, and DEPENDENCIES.
Parameter descriptions are minimal or missing. Example: 'filter[status]' in getTransactions has no description enum values listed. Example: 'filter[parent]' in getCategories says 'The unique identifier of a parent category...' but does not explain the use case or what happens if invalid.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Retrieve category
List tags
List transactions
Retrieve transaction
Categorize transaction
Add tags to transaction
Output schemas are not documented. Tool definitions show only input schemas (queryParams, pathParams, bodyParams) but do not document response structures. LLMs need to know what fields to expect so they can plan downstream tool calls.' The Zod response schemas exist in tool-schemas.zod.ts but are not exposed in tool registration.
Tool names for write operations are overly verbose and unclear. 'patchTransactionsTransactionIdRelationshipsCategory' is 52 chars; 'postTransactionsTransactionIdRelationshipsTags' is 47 chars. These names are 2-3x longer and obscure the action. Recommend: 'categorizeTransaction', 'addTransactionTags', 'removeTransactionTags'.
Write operations (patch, post, delete) lack dry-run and confirmation patterns. Agents make mistakes, a confirm_before_execute pattern prevents catastrophic errors.' The 3 write tools have no such protection.
bodyParams for write operations are documented as 'Update transaction category request', 'Update transaction tags request' but the actual schema structure is not shown. The tool definition shows type='object' with a generic description.
No error handling guidance. Tool definitions do not document failure modes, recovery steps, or retry-ability.
No pagination guidance for list tools. getAccounts, getTransactions, getTags accept page[size] but do not document page size constraints, default limit, or total count return. Without pagination, large results blow the context window.'
Parameter enum values not fully documented. Example: getAccounts has filter[status] enum but the enum values are not listed in the description. LLMs must infer valid options from the schema, but relying on schema parsing is fragile.