Loading ToolBench
Dual-protocol server for Monarch Money integration via FastMCP (HTTP) and REST endpoints. Supports Claude Desktop, Allen, and n8n with Bearer token and optional GitHub OAuth authentication.
This server has clear tool naming and well-structured descriptions, but parameter documentation is inconsistent and output schemas are not formally documented. All 11 tools follow verb_noun naming convention (get_*, search_) and have descriptions in the 50 - 200 character range, which is appropriate. However, most tools lack structured output schema documentation, the code returns JSON but does not specify field types, nesting, or what an agent should expect. Parameter descriptions are present but sometimes generic (e.g., 'Optional: account ID to filter transactions' does not clarify the expected format or whether to use account name or system ID). No error handling patterns are evident in the source code, tools appear to return raw API responses without recovery guidance. Security is adequate (credentials injected via env vars, no secrets in parameters), but permission scoping is not declared.
List all accounts (checking, savings, credit, investment, loans, etc.) with current balances.
Get budget data (monthly amounts by category/category group, totals by month) for a date range. Defaults to last month through next month if dates are omitted.
Get income and expense cashflow summaries for a date range, optionally grouped by category.
Get all goals (savings targets, financial milestones) with progress and contribution history.
Get household members and their role in a multi-user Monarch account.
Get investment account holdings with positions, market values, and performance data.
Output schemas not formally documented. Tools return JSON but LLMs cannot infer field types, presence/absence of fields, array lengths, or nested structure. The code shows GET calls to Monarch API but does not specify what fields each tool returns. Without this, agents struggle to extract the right data downstream.
Parameter descriptions are present but generic. Example: 'Optional: account ID to filter transactions' does not clarify if this is a system ID like 'acc_12345' or a human-readable account name like 'Checking'. Agents cannot determine which to pass without trial-and-error.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
Get investment transactions (trades, dividends, contributions) for a date range.
Get the current net worth snapshot (total assets, liabilities, and net worth).
Get recurring transaction predictions and patterns.
Get transactions for a date range (ISO 8601 format), optionally filtered by account.
Search transactions by text query (amount, merchant, category, notes).
No error handling or recovery guidance visible in source code. If a tool fails (e.g., invalid date range, account not found, API rate limit), there is no indication of what went wrong or what the agent should do next. Tools should return actionable errors with retry guidance.
No pagination support visible. Tools like get_transactions and search_transactions do not declare limit or offset parameters. Large result sets could exhaust context windows. Spec requires paginated results to include total count or next_cursor.
Tool permissions not declared. No indication of what scopes or permissions each tool requires (e.g., 'read:transactions', 'read:investments'). This prevents agents from operating with least-privilege configurations.
Date parameter format not enforced. Tools accept 'ISO 8601 format (e.g., 2024-01-01)' in descriptions but no regex pattern or validation is documented. LLMs frequently pass invalid dates (2024-13-45, 'next week', '7 days ago'). Use explicit JSON Schema format: 'date-time' or 'date'.