Loading ToolBench
MCP server for scraping Israeli banks and credit cards data, providing financial analysis and transaction insights
This Israeli bank MCP server demonstrates strong tool definition quality with comprehensive descriptions and well-structured schemas across 16 financial analysis tools. Nearly all tools have clear, context-rich descriptions (100-350 chars) that explain WHEN to use them and include helpful prerequisites. Input schemas are consistently present with proper JSON Schema typing. However, there are notable gaps: output schemas are not documented in the provided source, error handling guidance is absent, and several parameter relationships are undocumented. The server follows the verb_noun naming convention consistently (get_*, analyze_*, search_*) and tool names clearly convey intent. Parameter descriptions are generally thorough, with appropriate constraints (enums, date formats, numeric ranges). Security is handled well (no credentials in parameters). The main deficiency is the lack of explicit return type documentation, which would help agents understand chaining possibilities and avoid unnecessary lookup calls. Overall, this is a well-crafted tool suite that would serve financial analysis workflows effectively, but falls short of A-grade excellence due to incomplete schema documentation.
Analyze spending patterns by day of week. Identify if you spend more on weekends or specific days. Perfect for understanding behavioral spending patterns and optimizing budget by day type.
Deep-dive analysis for specific merchants! Shows spending patterns, average transaction amounts, frequency, and flags unusual charges (potential errors/fraud). Perfect for questions like "How much do I usually spend at the supermarket?" or "Alert me if any coffee shop charge is 50% higher than normal". The anomaly detection helps catch billing errors. MERCHANT SHOULD NEVER BE ONE OF THE ACCOUNT NAMES, OR A CATEGORY - ONLY A MERCHANT NAME.
Tracks how an account balance changes over time - essential for balance projections and understanding cash flow patterns. Use this to answer "Will I make it to payday?" or "What's my account trend?" by analyzing historical balance movements. MUST have account ID from get_accounts first.
ESSENTIAL FIRST STEP for any account-specific query! Lists all connected bank accounts and credit cards with their current balances and unique IDs. Always use this when users mention account names like "my Visa", "Leumi account", or "Max card" to get the correct account ID. Also shows total net worth across all accounts.
Output schemas not documented. While input schemas are well-defined, return types are not specified in the tool definitions. This prevents agents from understanding what fields will be returned and which can be used for chaining into subsequent tool calls (e.g., does get_transactions return merchant_id for use in analyze_merchant_spending?).
Error handling guidance absent. None of the tool descriptions document what happens when a call fails (e.g., invalid date range, missing account, stale data). No guidance on retryability, user-fixable errors, or recovery steps. This leaves agents without actionable next steps if a call fails.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 45 | - | v1 |
ALWAYS USE THIS FIRST before any category filtering! Retrieves all unique transaction categories from your actual data (often in Hebrew like "מזון", "בילויים", etc.). Essential for category comparison queries like "food vs entertainment spending" or when searching transactions by category. The categories returned are the ONLY valid values you can use in other tools that accept category filters.
Compare spending in specific categories between two time periods. Perfect for answering "Did I spend more on food this month vs last month?" or analyzing budget performance across categories.
Your go-to tool for burn rate analysis and high-level financial overviews! Returns aggregated income, expenses, and trends without individual transaction details. Perfect for: comparing spending between months, calculating savings rates, understanding overall financial health, or when users ask "How much did I spend this month?" or "What's my burn rate?". Automatically optimized for large date ranges.
YOUR FIRST STOP for any metadata questions! Instantly returns: earliest/latest transaction dates, total transaction count, date range of available data, database statistics, and system configuration. Use this instead of get_transactions when users ask "How far back does my data go?" or "What's the oldest transaction?" - it's much faster and more efficient.
Provides a comprehensive breakdown of credit card usage for any month, showing total charges, transaction count, and average transaction size per card. Perfect for monthly credit card bill reconciliation or understanding which cards are used most. Can also break down spending by category when requested.
Your subscription detective! Identifies recurring charges like Netflix, Spotify, gym memberships, and other regular payments. Analyzes transaction patterns to find charges that repeat monthly with similar amounts. Essential for answering "What subscriptions am I paying for?" or calculating total monthly fixed costs. Only shows charges that appear consistently.
Check when your financial data was last updated and if any scraping is currently in progress. Always use this at the start of analysis to ensure data freshness. If data is older than 24 hours, suggest refreshing before proceeding with analysis.
Ranks all merchants by total spending to identify where your money goes. Answers "Who am I spending the most money with?" Perfect for finding cost-cutting opportunities or understanding spending priorities. Can filter to show only significant merchants above a minimum threshold.
Retrieves individual transactions with full details like date, amount, merchant, and category. Perfect for: reviewing recent purchases, finding specific transactions, analyzing spending patterns by day/week, or getting raw data for custom analysis. IMPORTANT: Always call get_accounts FIRST if filtering by account. For large date ranges (>90 days), only the most recent 500 transactions are returned. Use get_financial_summary for longer-term overviews.
Triggers a fresh scrape of all connected bank and credit card accounts to get the latest data. Use when user mentions recent transactions not appearing, or when get_scrape_status shows data is stale (>24 hours old). This ensures all subsequent analysis uses the most current information.
Refreshes data from a specific financial provider when you need updated information from just one source. More efficient than refresh_all_data when dealing with single account issues.
Flexible transaction search with multiple filters. Search by text, amount range, date range, category, and merchant. Perfect for finding specific transactions or groups of related expenses.
Parameter relationships undocumented. Several tools have implicit dependencies that could cause confusion: get_account_balance_history requires accountId from get_accounts, but this is mentioned only as a note in the description, not formalized as a 'required after' or 'requires' constraint. get_category_comparison requires both period1Start/End and period2Start/End, but the description doesn't clarify whether they must be non-overlapping or how they're compared.
Tool descriptions include imperative guidance ('ALWAYS USE THIS FIRST', 'MUST have account ID') that, while helpful, suggests agents may not be reliably following ordering constraints. A stateless agent should work correctly regardless of tool call order, or the constraints should be enforced server-side rather than via description text.
No pagination support documented for tools returning potentially large result sets (get_transactions, get_spending_by_merchant, search_transactions). While get_spending_by_merchant has a 'limit' parameter, there's no mention of offset, cursor, total_count, or how results are ordered. Large untruncated result sets can exhaust context windows.