Loading ToolBench
Model Context Protocol server for personal financial management, providing tools to manage accounts, transactions, categories, merchants, balance history, documents, exchange rates, and institutions
The Guilders MCP server exposes 22 financial management tools with consistent naming (verb_noun pattern: get*, create*, update*, delete*) and documented schemas. However, there are significant gaps in description quality, missing output schema documentation, and inconsistent parameter documentation. Tool descriptions average ~80 characters but many lack actionable guidance on when to use tools or what they return. Parameter descriptions are present but often generic. Error handling guidance is absent from tool definitions. The server follows a clear domain model (accounts, transactions, categories, merchants, documents, balance history) with good resource composition, but lacks the refinement expected of production-grade financial tooling.
Create a new account with auto-calculated type from subtype
Create a new category for transaction organization
Create a new merchant
Create a new transaction
Delete an account and all its children
Delete a category
Delete a merchant
Delete a transaction
Output schemas not documented. Tool definitions show input schemas but do not specify what fields are returned by each tool. This prevents LLMs from understanding what data is available after calling a tool, forcing additional discovery calls or hallucinated field access.
Generic descriptions on GET tools. Tools like getCategories, getMerchants, getDocuments, getExchangeRates, and getInstitutions have minimal descriptions ("Retrieve all X for the authenticated user") that don't explain when to use them vs similar tools or what structure they return. Average description length ~50-60 chars; should be 80-150 chars with actionable context.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 39 | 1.27.1+ | v1 |
Retrieve all accounts for the authenticated user
Retrieve daily balance snapshots for a single account with optional date range filtering
Retrieve all categories for the authenticated user
Retrieve a specific document file content
Retrieve all documents for the authenticated user with optional filtering
Retrieve current exchange rates from the database
Retrieve all financial institutions available for connection
Retrieve all merchants for the authenticated user
Retrieve transactions for the authenticated user with optional filtering
Render a stock account summary card in the UI when the user asks about a single stock account/asset. Call get_accounts first, then use the account data to populate this card. Do not use for non-stock requests.
Update an account with automatic type recalculation if subtype changed
Update an existing category
Update an existing merchant
Update an existing transaction
Delete tools lack confirmation/safety guidance. deleteAccount, deleteTransaction, deleteCategory, and deleteMerchant are destructive operations but have minimal descriptions and no mention of confirmation steps, dry-run capability, or what happens to child records. For deleteAccount specifically, the description says 'and all its children' but doesn't explain whether this is reversible.
No error handling guidance in tool descriptions. None of the 22 tools indicate what errors might occur or how to recover. E.g., getTransactions with optional filters doesn't say what happens if accountId is invalid, or createTransaction doesn't mention what validation occurs. LLMs cannot self-correct without error context.
Parameter format constraints missing. createTransaction accepts 'date' as ISO 8601 and 'currency' as a code, but descriptions don't specify the exact format (e.g., 'YYYY-MM-DD', 'ISO 8601 timestamp', 'ISO 4217 currency code like USD'). createCategory accepts 'color' as hex but doesn't specify format (#RRGGBB vs rrggbb). LLMs will guess and produce invalid values.
showStockCard has inconsistent parameter typing. Accepts numeric accountId (not string like other tools), nullable subtype, nullable image, string symbol, string accountName, nullable cost and currentValue/totalChange. No description explains why this differs from other tools or what happens when optional fields are missing. Appears to be UI rendering, not data retrieval, but purpose is unclear.
No pagination or result-limiting guidance. getAccounts, getTransactions (with optional filters), getCategories, getMerchants, getDocuments, getBalanceHistory return potentially large result sets. No mention of pagination, limits, or result counts. If a user has 1000+ transactions, returning all in one call will exhaust token budget.
userId parameter appears in read-only tools (getAccounts, getCategories, getMerchants, getExchangeRates, getInstitutions) but is described as 'The user ID from context.' This suggests the parameter is redundant if the user is already authenticated. Clarify whether this is auto-injected server-side or if the agent must provide it, and if it's required or inferred.