Loading ToolBench
Server has 7 well-defined tools with consistent naming, enums for constrained inputs, and clear parameter descriptions. Strengths: verb-first naming (up_list_*, up_get_*), structured TypeScript interfaces, documented parameter constraints (enums for accountType, ownershipType, status). Weaknesses: no output schema documentation in tool definitions, parameter descriptions lack depth (missing format hints for date strings, no examples of category IDs, no guidance on pagination behavior), no error handling guidance, no confirmation patterns for account-linked operations, missing descriptions for what fields are returned.
Get details for a specific account by ID, including current balance and account information.
Get details about a specific category by ID, including its name and parent/child relationships.
Get detailed information about a specific transaction by ID, including amount, description, category, and related account.
List all accounts for the authenticated user. Returns account balances, types (SAVER, TRANSACTIONAL, HOME_LOAN), and ownership information.
List all spending categories in Up. Categories have a parent-child relationship. Use this to understand category IDs for filtering transactions.
List transactions across all accounts or for a specific account. Supports filtering by status, date range, category, and tags. Returns paginated results ordered newest first.
Output schemas not documented in tool definitions. Tools return TypeScript interfaces (AccountResource, TransactionResource, CategoryResource) visible in code, but tool definitions lack outputSchema field in the Tool[] array. LLMs cannot understand what fields will be returned without explicit schema documentation.
Parameter descriptions lack actionable format guidance. 'since' and 'until' parameters describe RFC 3339 format in text (e.g., 2024-01-01T00:00:00+10:00) but do not specify minimum/maximum date ranges, whether past dates are valid, or whether future dates are rejected. 'pageSize' has no min/max bounds documented (code shows default 30, max 100, but description omits these).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Test the Up API connection and verify authentication is working
Category parameter in up_list_transactions lacks examples and guidance. Description says 'Filter by category ID (e.g., 'restaurants-and-cafes', 'good-life')' but does not explain how to discover valid category IDs or whether they are case-sensitive. up_list_categories should be called first, but this dependency is not documented.
No error handling guidance in tool descriptions. API errors are thrown as generic 'Up API error: {status} {statusText}\n{errorText}' with no recovery hints. LLMs receive no instruction on whether to retry, ask the user, or fail gracefully. No documentation of common failure modes (auth failure, rate limits, invalid IDs).
Pagination support unclear. up_list_transactions and up_list_accounts accept pageSize but no offset/cursor parameter visible. Description does not explain: (1) whether results are paginated by default, (2) how to fetch next page, (3) whether there is a total count returned, (4) default page size if not specified.
API token exposure risk. The UpApiClient reads apiToken from constructor config, which is populated from environment variable UP_API_TOKEN. While the token is not exposed as a tool parameter (good), the makeRequest() error response includes full errorText from the API, which could contain sensitive information if the API echoes the token in error messages.
No idempotency or confirmation patterns for read-only tools (which is correct), but descriptions lack clarity on what 'READ_ONLY' means to agents. All 7 tools are marked READ_ONLY, which is accurate, but tool descriptions should state whether repeated calls with identical parameters return identical results (required for agent retry safety).