Loading ToolBench
Personal MCP server for financial data aggregation from Israeli banks with transaction scraping and database query capabilities
The Asher MCP server has significant quality gaps. 11 tools are registered, but 5 are duplicates (listTables, getTableSchema, sqlQuery, describeTable appear twice). Of the 6 unique tools, descriptions are present but minimal (ranging 15-106 chars, below the 194-char baseline). Input schemas are present for parameterized tools but lack comprehensive constraints. No parameter descriptions are visible in the schema objects provided. The server lacks pagination support for list operations, output schema documentation is not evident, and error handling is not comprehensive. Security is a concern: sqlQuery accepts arbitrary SELECT queries, which could expose sensitive data or enable data exfiltration despite claims of 'safe' execution.
Get detailed information about a table including columns and indexes
Get detailed information about a table including columns and indexes
Fetch transactions from all configured bank scrapers
Get the current date and time. Use this to understand what "today", "this month", "this year" means in user queries.
Get the schema for a specific table
Get the schema for a specific table
List all available bank scrapers
Duplicate tool registrations: listTables, getTableSchema, sqlQuery, and describeTable are defined twice (entries 1/7, 2/8, 3/9, 4/10). This wastes capability space and confuses LLM tool selection. Deduplicate immediately.
Input parameter descriptions are missing. The schema for 'getTableSchema' shows {"table": {"type": "string", "description": "Name of the table..."}} but the description is truncated in the source. Across all tools, parameter descriptions should clarify format constraints, enums, and dependencies. LLMs cannot infer meaning from parameter names alone.
sqlQuery tool description claims 'safe SELECT query on allowed tables' but provides no visibility into the allowlist, query validation, or injection protection mechanism. This is a critical security gap. The tool should document: (a) which tables are whitelisted, (b) how the query is parsed/validated, (c) what happens if a non-SELECT query is submitted. Agents cannot safely use this tool without explicit guardrails.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
List all tables in the database
List all tables in the database
Execute a safe SELECT query on allowed tables
Execute a safe SELECT query on allowed tables
No output schema documentation visible. Tools like listTables and listScrapers lack documented return types. LLMs need to know what fields to expect (e.g., does listTables return [{name, rowCount, schema}] or [{name}]?) to plan follow-up calls. This forces exploratory calls and wastes tokens.
No pagination support. listTables and listScrapers lack limit, offset, or cursor parameters. If a database has hundreds of tables or scrapers, returning all results could exceed the context window. Add page_size and cursor/offset parameters and document them.
Error handling is not evident in the source. No recovery guidance documented. E.g., if sqlQuery fails because a table name is misspelled, the tool should suggest 'Did you mean: table_a, table_b?' and instruct the LLM to call listTables first. Without recovery hints, agents hit dead ends.
fetchTransactions is marked as WRITE but lacks confirmation/dry-run support. Agents calling this tool could accidentally trigger unintended data fetches. Add a dry_run parameter or implement a confirmation-before-execute pattern for state-mutating operations.
No tool annotations present. The protocol supports tool annotations (readOnlyHint, destructiveHint, idempotentHint) to help clients optimize behavior. Tools like listTables should be annotated readOnlyHint=true; fetchTransactions should be destructiveHint=true. These are missing.