Reconcile a bank account against your books and see which items do not match.
Scored across 2 tools
The tools are mostly distinct: one performs a full bank-to-books reconciliation, while the other diagnoses why a reconciliation does not balance. However, the diagnostic tool explicitly runs the same matching and computes the same adjusted balances, so an agent could confuse the two when a user asks broadly to 'find the difference.'
Both names use snake_case, start with a clear verb, and describe the action and object. The pattern is consistent across the two tools.
Two tools is thin for the domain, though each covers a meaningful workflow. The server lacks a companion tool for single-statement conversion or related reconciliation tasks, making the surface feel borderline limited.
The core lifecycle is covered: perform the reconciliation, list and classify unmatched items, compute adjusted balances, and diagnose imbalances. Minor gaps remain, such as no support for reconciling a single statement without books and no way to detect items missing from both files.
Use this when the user attaches the bank file and the books file, gives the bank statement ending balance and the book balance, and asks why the bank reconciliation does not balance: "why is my bank reconciliation off", "reconciliation difference", "find the difference between bank and books". Runs the same matching, computes adjusted bank vs adjusted book balance, and finds the smallest set of listed items (up to 4) whose amounts account for the difference, plus checks for a reversed sign, a transposition (difference divisible by 9) and a row with that same amount. Returns the same Excel and PDF downloads. Does not change any file and cannot find items that are missing from both files. Supports up to 20,000 rows per file; CSV and text tables have a 2,000,000-cell limit (including empty cells). Each call saves new Excel and PDF files on the plugin server for 1 hour (private download links), then deletes them.
| Name | Required | Description | Default |
|---|---|---|---|
| bank_file | Yes | The bank side: the bank's CSV or Excel (.xlsx) transaction export, or a text PDF bank statement, e.g. bank-september.csv. | |
| books_file | Yes | The book side: the cash/bank account register or general ledger export from accounting software or a spreadsheet (CSV or .xlsx), e.g. books-september.xlsx. | |
| books_sign | No | Sign of the books file amounts: auto (default) flips only when the amounts clearly match the bank with the opposite sign; as_written keeps them; flip reverses them. Example: auto. | |
| date_order | No | Order of numeric dates in both files: MDY (US, 09/02/2026) or DMY (02/09/2026). Detected per file when a day is above 12; US is assumed otherwise. | |
| period_end | No | Statement / period end date YYYY-MM-DD, e.g. 2026-09-30. Default: the statement end on a PDF, else the month end of the last book entry (capped by the bank file). | |
| bank_columns | No | Optional column names for the bank file when auto-detection picks the wrong column, e.g. {"date":"Post Date","amount":"Amount"}. | |
| books_columns | No | Optional column names for the books file, e.g. {"date":"Date","debit":"Debit","credit":"Credit","check_no":"Num"}. | |
| max_group_size | No | Most rows combined when one deposit equals several book entries (or the reverse), e.g. 4 (default). | |
| check_clear_days | No | Days a check may take to clear and still match by amount, e.g. 60 (default). Matches by check number allow the same span. | |
| date_window_days | No | Days a bank posting may differ from the book date and still match the same amount, e.g. 5 (default). | |
| bank_ending_balance | Yes | Ending balance on the bank statement at period end, in dollars, e.g. 48210.55. | |
| book_ending_balance | Yes | Cash account balance in the books at period end, in dollars, e.g. 51022.10. |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| note | Yes | |
| files | Yes | |
| counts | Yes | |
| status | Yes | PASS only when both ending balances are known and the difference is $0.00; BALANCES_NEEDED = activity explained, balances needed. |
| warnings | Yes | |
| downloads | Yes | |
| period_end | Yes | |
| explanation | Yes | |
| top_bank_only | Yes | |
| top_book_only | Yes | |
| reconciliation | Yes | |
| bank_only_by_class | Yes | |
| book_only_by_class | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: the run is non-destructive to the source files ('Does not change any file'), it writes new Excel and PDF artifacts to the plugin server with private links that expire after one hour, and it discloses scale limits (20,000 rows per file; 2,000,000 cells for CSV/text). This also explains why readOnlyHint=false despite no mutation of user data, so there is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the 'Use this when...' trigger and example utterances, then flows into behavior, limits, and side effects. It is one dense run-on paragraph and a few clauses could be split, but nearly every sentence carries information an agent would otherwise have to guess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter, nested-object tool with an output schema, the description covers the missing pieces: what the analysis does, what artifacts come back ('the same Excel and PDF downloads'), retention and privacy of those downloads, and explicit failure boundaries. An agent can decide to call it and predict the effects without opening the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter, including the sign, date-order, and column-mapping objects, is already documented in the schema. The description adds only a little interpretive detail (the up-to-4 item set maps loosely to max_group_size, and 'divisible by 9' explains the transposition check), so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource (explain why the bank reconciliation is off) and spells out the mechanics: rerun the matching, compute adjusted bank vs adjusted book balances, and isolate the smallest set of items (up to 4) that explains the difference. It implicitly ties itself to the sibling reconcile_bank_to_books ('Runs the same matching') but never states plainly that the sibling performs the reconciliation while this one only diagnoses the gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete trigger condition (user attaches bank and books files, supplies both ending balances, and asks why the reconciliation does not balance) along with literal user phrasings. It also states what the tool cannot do (find items missing from both files) and its row/cell limits, but does not say when to reach for reconcile_bank_to_books instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user attaches a bank export or statement AND their books (cash account register or general ledger export from accounting software or a spreadsheet) and wants a bank reconciliation: "reconcile my bank statement", "reconcile bank statement against my books", "list what doesn't match", "find outstanding checks and deposits in transit", "match bank transactions to the ledger". Matches rows by check number, amount and date (with a date window), and sums (one deposit = several invoices); lists all unmatched rows on both sides with a classification (outstanding check, deposit in transit, bank fee, interest, NSF, likely duplicate, likely amount typo); builds adjusted bank vs adjusted book balance (PASS only at $0.00); returns an Excel workbook and a PDF reconciliation statement. Does not connect to bank accounts or accounting software, does not post entries, and is not for a single statement without books (use a statement converter for that). Supports up to 20,000 rows per file; CSV and text tables have a 2,000,000-cell limit (including empty cells). Each call saves new Excel and PDF files on the plugin server for 1 hour (private download links), then deletes them.
| Name | Required | Description | Default |
|---|---|---|---|
| bank_file | Yes | The bank side: the bank's CSV or Excel (.xlsx) transaction export, or a text PDF bank statement, e.g. bank-september.csv. | |
| books_file | Yes | The book side: the cash/bank account register or general ledger export from accounting software or a spreadsheet (CSV or .xlsx), e.g. books-september.xlsx. | |
| books_sign | No | Sign of the books file amounts: auto (default) flips only when the amounts clearly match the bank with the opposite sign; as_written keeps them; flip reverses them. Example: auto. | |
| date_order | No | Order of numeric dates in both files: MDY (US, 09/02/2026) or DMY (02/09/2026). Detected per file when a day is above 12; US is assumed otherwise. | |
| period_end | No | Statement / period end date YYYY-MM-DD, e.g. 2026-09-30. Default: the statement end on a PDF, else the month end of the last book entry (capped by the bank file). | |
| bank_columns | No | Optional column names for the bank file when auto-detection picks the wrong column, e.g. {"date":"Post Date","amount":"Amount"}. | |
| books_columns | No | Optional column names for the books file, e.g. {"date":"Date","debit":"Debit","credit":"Credit","check_no":"Num"}. | |
| max_group_size | No | Most rows combined when one deposit equals several book entries (or the reverse), e.g. 4 (default). | |
| check_clear_days | No | Days a check may take to clear and still match by amount, e.g. 60 (default). Matches by check number allow the same span. | |
| date_window_days | No | Days a bank posting may differ from the book date and still match the same amount, e.g. 5 (default). | |
| bank_ending_balance | No | Ending balance on the bank statement at period end, in dollars, e.g. 48210.55. With book_ending_balance this gives the full adjusted-balance reconciliation. | |
| book_ending_balance | No | Cash account balance in the books at period end, in dollars, e.g. 51022.10. |
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| note | Yes | |
| files | Yes | |
| counts | Yes | |
| status | Yes | PASS only when both ending balances are known and the difference is $0.00; BALANCES_NEEDED = activity explained, balances needed. |
| warnings | Yes | |
| downloads | Yes | |
| period_end | Yes | |
| explanation | Yes | |
| top_bank_only | Yes | |
| top_book_only | Yes | |
| reconciliation | Yes | |
| bank_only_by_class | Yes | |
| book_only_by_class | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), it discloses that each call writes new Excel and PDF files held privately for one hour and then deleted — which explains the non-idempotent hint and the artifact lifecycle. It also gives hard limits (20,000 rows per file, 2,000,000-cell cap for CSV/text), the PASS gate at $0.00, and that it neither connects to bank/accounting systems nor posts entries. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the trigger condition and matching logic, and every later sentence carries real information (limits, file lifecycle, exclusion). The dense run of quoted example utterances and semicolon-chained clauses makes it slightly bloated for a single paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter, nested-object tool with an output schema, this covers the essentials: inputs required, matching behavior, limits, artifacts produced, and what it will not do. Return values are summarized and then detailed by the output schema, so nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the description rises above it by explaining the matching semantics behind the tuning parameters — the date window for same-amount matches, the check-clear span, and grouping for one-deposit-to-many-entries. It never explicitly ties names like date_window_days or books_sign to their behavior, so it stops short of a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb+resource ('bank reconciliation') and then enumerates the exact mechanics: matching by check number, amount and date window, summing one deposit to several invoices, classifying unmatched rows, and building adjusted bank vs adjusted book balances. An agent can tell this apart from the sibling explain_reconciliation_difference without inspecting any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the triggering condition explicitly (a bank export AND books attached), gives sample user phrasings, and names the exclusion case plus the alternative ('not for a single statement without books — use a statement converter'). Both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
explain_reconciliation_differencereconcile_bank_to_booksReconcile business documents, inspect exact differences and evidence, and export reports.
Import a bank CSV, categorise it, summarise it per currency and reconcile it against your expenses.
Import a bank CSV, categorise it, summarise it per currency and reconcile it against your expenses.
Import a bank CSV, categorise it, summarise it per currency and reconcile it against your expenses.
Add one secure layer between your agents and this server.