Loading ToolBench
MCP server demo for personal finance workflows backed by Supabase
Wealth Finder demonstrates solid tool design with clear naming, comprehensive descriptions, and proper schema definitions. All 10 tools follow verb_noun conventions (get_*, set_*, file_*). Descriptions are detailed and contextual (avg ~180 chars), exceeding the 10-1024 char baseline. Input schemas use Zod with type definitions and parameter descriptions. However, output schemas are not formally documented, responses are returned as structuredContent without explicit schema declarations. Error handling is minimal; no recovery guidance or actionable error messages visible. Two-stage confirmation pattern (preview/confirm) on write operations is excellent. Tool composition is clean with no overlapping responsibilities.
Files a service complaint with a provider (e.g. Rogers Communications) about a billing issue. Two-stage flow: first call with confirm: false (or omit confirm) to see a draft of the complaint — nothing is submitted yet. Then call again with confirm: true to submit, which inserts a row into the complaints table and returns a confirmation_number (e.g. "WF-1740000000-4821"). Required: provider (e.g. "Rogers Communications"), bill_id, and reason. Optional: disputed_line_items and requested_resolution.
Returns all financial accounts for the current user, including balances, account types, currency, credit limits, interest rates, and metadata. Call this tool first to orient the conversation — it gives a complete snapshot of the user's financial position across all 7 accounts.
Returns the full details of a specific bill, including all line items that make up the total charge. Requires a bill_id (e.g. "bill_rogers_phone_2026_02"). Call get_bills_due first to find the bill_id, then call this tool to see the breakdown. Use this tool when the user wants to know exactly what is on a specific bill — especially useful for investigating anomalous charges. Only call this tool when the user explicitly asks for bill line items or a full breakdown. Do not call it proactively when summarising bills — wait for the user to request the detail.
Returns all recurring bills for a given month (format: YYYY-MM, e.g. "2026-02"), including provider, amount, autopay status, and anomaly flags. A bill is flagged as an anomaly when its current_amount is significantly higher than the typical_amount. Use this tool when the user asks about upcoming bills, monthly expenses, or wants to know if anything looks unusual on their bill statements.
Output schemas not formally documented. Tools return structuredContent but no schema definitions are provided to the LLM. This forces the LLM to infer response structure from examples, increasing hallucination risk.
No error handling or recovery guidance. Tools lack actionable error messages. If a database query fails or a parameter is invalid, the LLM receives no guidance on what to do next (retry, ask user, try alternative tool).
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2025-06-18+ | v2 |
Returns the current date from the server clock. Call this at the start of any conversation before referencing months, years, or relative time periods like "this month", "last month", or "recently".
Returns the total interest paid on the line of credit for a given year (format: YYYY, e.g. "2025" or "2026"). Year is optional and defaults to the current year. Also provides a payoff projection showing how long it would take to eliminate the LOC balance at different monthly payment levels. Use this tool when the user asks about interest costs, debt payoff timelines, or wants to understand the true cost of carrying their line of credit balance.
Returns spending totals grouped by category for a given month (format: YYYY-MM, e.g. "2026-02"). Use compare_to_month (optional) to compare against a different month, or compare_previous_month for prior-month comparison. Set limit (optional, default 10) to control how many categories are returned. Only debit transactions are included. Use this tool when the user asks about their spending, top categories, or wants to understand where their money went in a specific period.
Returns recurring subscriptions with dynamic usage activity flags computed from transaction history: "active" (matching transaction within 30 days), "possibly_unused" (31–90 days), or "likely_unused" (90+ days or no matches). Each subscription includes a usage_rationale describing the evidence. Also returns total monthly subscription cost and a breakdown by usage status.
Returns a filtered list of transactions across all accounts. All filters are optional. Filter by account_id (e.g. "acc_chq_001"), category (e.g. "dining"), category_group (e.g. "FOOD"), merchant (partial text match), date_from and date_to (YYYY-MM-DD), direction ("debit" or "credit"), and limit (default 50, max 200). Results are ordered by date descending. Use this tool when the user asks to see specific transactions, search for a merchant, or verify a charge.
Sets a monthly spending cap for a category. Two-stage flow: first call with confirm: false (or omit confirm) to see a preview of the alert — nothing is saved yet. Then call again with confirm: true to save to the database. Required: category (e.g. "dining"), category_group (e.g. "FOOD"), and monthly_limit (in CAD). Optional: alert_threshold_pct (default 80) to control when the alert triggers.
Parameter validation rules not documented. Numeric limits (e.g., limit max 200) are mentioned in descriptions but not enforced via schema constraints (min/max). LLMs may pass invalid values.
No pagination metadata returned. Tools like get_transactions and get_spending_by_category accept limit but do not return total_count or next_cursor, making it impossible for the LLM to know if results are truncated.
Confirmation pattern lacks explicit error states. set_spending_alert and file_service_complaint use confirm flag but do not document what happens if the preview step fails or if the confirm step is called without a prior preview.