Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@reconcile-mcp Reconcile my expected payments against observed bank entries."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server that matches expected payments
(from pain.001 credit transfers) against observed booked entries (from a
camt.053 statement) and returns an explainable reconciliation — exact
matches, short/over payments, split settlements (one-to-many), batch credits
(many-to-one), and the residual unmatched items on each side, every match
carrying a score and the reasons it was made.
Latest release: v0.0.1 — 7 MCP tools over stdio, pure-Python matching engine, deterministic sandbox test-mode, for Python 3.10+. Part of the ISO 20022 MCP suite: you own both sides of the match.
Reconciliation is the treasury team's daily pain: did the money we expected
actually arrive, and which invoice does each credit belong to? It is rarely
one-to-one — customers underpay, settle an invoice in instalments, or a payout
aggregator sends one lump covering a dozen receivables. reconcile-mcp does
this matching as an agent tool, and — critically for finance — shows its
work: every pairing comes with a numeric score and a plain list of the
signals (reference, amount, date, counterparty) that drove it.
Related MCP server: camt053-mcp
reconcile-mcp is the reconciliation workflow of eight coordinated,
vendor-neutral MCP servers that together cover the ISO 20022 bank-statement
workflow and the November 2026 structured-address cutover, plus a high-level orchestration layer — readiness scoring, clearing-profile linting, and audit evidence — statement depth,
whole-catalogue routing, reconciliation, multi-format ingestion, and address
remediation. Dependency ranges are kept aligned across the suite,
so the servers co-install cleanly in a single Python environment: start with
one, add the rest as your workflow grows.
Server | Scope | Surface | Install | Use it when |
ISO 20022 | 22 MCP tools · 4 prompts · 3 resources |
| You work with bank-to-customer statements end to end — the suite's flagship | |
Unified gateway: | 7 meta-tools |
| You want one entry point to every message family | |
Matches expected | 7 MCP tools |
| You need explainable statement/payment reconciliation — this package | |
Multi-format statement ingestion: ISO 20022 CAMT.053 and pain.001, SWIFT MT940, OFX/QFX, CSV | 5 MCP tools · 1 prompt · 1 resource |
| Your statements arrive in mixed or legacy formats | |
ISO 20022 postal-address classification, assessment & remediation for the November 2026 structured-address cutover ( | 9 MCP tools |
| You need debtor/creditor addresses cliff-ready ahead of 14 Nov 2026 | |
Orchestration gateway: detect → structurally validate → clearing-profile lint → readiness score, plus automated remediation and | 4 MCP tools |
| You want one high-level readiness / orchestration entry point over the suite | |
Manages, validates and serves bank-specific clearing profiles / rule packs (CBPR+, SEPA_Instant, FedNow, Generic); premium rule-pack entitlement gating | 4 MCP tools |
| You lint payments against your own institution's market practice | |
Compiles readiness findings, remediation diffs and simulated responses into a sealed, Ed25519-signable audit evidence pack | 6 MCP tools |
| You need tamper-evident audit / certification artifacts |
In one line each: camt053-mcp is the bank-statement flagship (deepest
camt.05x surface, stdio + authenticated streamable HTTP);
iso20022-mcp is the generic message toolkit (a handful of verbs over
the whole catalogue); reconcile-mcp is the reconciliation workflow
(did the money we expected actually arrive?);
bankstatementparser-mcp is the ingestion layer (many formats in, one
transaction shape out); and structured-address-fix-mcp is the
postal-address specialist (debtor/creditor addresses cliff-ready for the
Nov 2026 cutover).
The suite also includes per-family servers — pain001-mcp
(credit transfer initiation), pacs008-mcp (FI-to-FI credit
transfers), and acmt001-mcp (account management) — whose
parsed output feeds straight into this server's normalize_* adapters.
pip install reconcile-mcp
# or run without installing:
uvx reconcile-mcpMCP client config (e.g. Claude Desktop claude_desktop_config.json):
{
"mcpServers": {
"reconcile": {
"command": "reconcile-mcp"
}
}
}The server ships a sandbox test-mode: deterministic scenarios so you can run the whole flow with no setup and no real cash data. One call gets you a full, explainable result:
run_sandbox_scenario(name="month_end")returns a realistic mixed close — one clean match, one short payment, one split settlement, and an unexpected credit correctly left unmatched:
{
"summary": {
"expected_count": 3, "observed_count": 5,
"matched_expected": 3, "unmatched_observed": 1,
"matches_by_type": {"exact": 1, "amount_mismatch": 1, "one_to_many": 1},
"fully_reconciled": false
},
"matches": [
{"type": "amount_mismatch", "expected": ["INV-6002"], "observed": ["ENT-52"],
"amount_delta": "-99.99", "confidence": "high",
"reasons": ["reference exact", "amount close (delta -99.99)", "date +/-0d", "counterparty exact"]},
{"type": "exact", "expected": ["INV-6001"], "observed": ["ENT-51"], "amount_delta": "0.00"},
{"type": "one_to_many", "expected": ["INV-6003"], "observed": ["ENT-53", "ENT-54"],
"reasons": ["amount sum of 2 entries"]}
],
"unmatched_observed": ["ENT-55"]
}List every scenario with list_sandbox_scenarios; load one to inspect or edit
its inputs with load_sandbox_scenario.
Records are small canonical objects — id and amount required, everything
else optional and used to sharpen matching:
{
"id": "INV-1001", // your reference / end-to-end id
"amount": 1200.00,
"currency": "EUR", // ISO 4217
"date": "2026-03-02", // ISO-8601
"counterparty": "Acme Ltd",
"reference": "INV-1001" // remittance / structured reference
}Already using the rest of the suite? Feed parsed output straight in — the adapters map it for you:
normalize_pain001(document) → the expected side, from
pain001-mcp.
normalize_camt053(document) → the observed side, from
camt053-mcp.
Then call reconcile(expected, observed).
reconcile — Match expected payments against observed entries; full explainable report.
explain_match — Score a single expected/observed pair with a per-signal breakdown (tuning aid).
normalize_pain001 — Adapt parsed pain.001 output into canonical expected records.
normalize_camt053 — Adapt parsed camt.053 output into canonical observed records.
list_sandbox_scenarios — List the built-in test-mode scenarios and magic references.
load_sandbox_scenario — Return one scenario's expected/observed inputs to inspect or edit.
run_sandbox_scenario — Load a scenario and reconcile it in one call — the fastest first run.
Each candidate pair is scored on four weighted signals, then classified:
Reference (0.45) — exact / partial equality of references and end-to-end ids, normalised to bare alphanumerics.
Amount (0.35) — exact within tolerance, or a linearly-decaying closeness with the delta reported.
Date (0.10) — proximity within a configurable window; neutral if unknown.
Counterparty (0.10) — token-set overlap of names; neutral if unknown.
Assignment is greedy, highest-score-first and fully deterministic (a total tiebreak order), so the same inputs always produce the same result. Residuals are then tested for one-to-many (a bounded subset-sum: one expected settled by several entries) and many-to-one (one entry covering several expected).
Tune any of it via the options argument: abs_tol / rel_tol,
date_window_days, high_threshold, review_threshold, currency_strict,
enable_one_to_many, max_combination.
git clone https://github.com/sebastienrousseau/reconcile-mcp
cd reconcile-mcp
python -m venv .venv && . .venv/bin/activate
pip install -e . && pip install pytest pytest-cov ruff black mypy
pytest # 100% branch coverage gate
ruff check reconcile_mcp tests && black --check reconcile_mcp tests && mypy reconcile_mcpLicensed under the Apache License, Version 2.0.
mcp-name: io.github.sebastienrousseau/reconcile-mcp
Score a single expected/observed pair and break down every signal (reference, amount, date, name). A tuning aid -- it explains the score even for pairs below the review threshold.
| Name | Required | Description | Default |
|---|---|---|---|
| options | No | Optional tuning object: 'abs_tol'/'rel_tol' (amount tolerance), 'date_window_days', 'high_threshold', 'review_threshold', 'currency_strict', 'enable_one_to_many', 'max_combination'. | |
| expected | Yes | One expected record. | |
| observed | Yes | One observed record. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds that it explains scores even for low-confidence pairs, which is extra context beyond 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?
Two concise sentences: first states purpose, second adds context. No filler, front-loaded with key information.
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?
The tool has an output schema (not shown) and complex input with nested objects. The description adequately explains the tool's purpose and tuning role, though it could briefly mention the output format.
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?
The description clarifies the role of each parameter (expected/observed as one record each) and lists the tunable fields in options, adding value beyond the schema's basic types.
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 uses a specific verb 'Score' and identifies the resource as 'a single expected/observed pair', clearly distinguishing it from sibling tools like 'reconcile' which likely handles batches.
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?
Implied use as a 'tuning aid' but lacks explicit guidance on when to prefer it over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the built-in sandbox scenarios (test-mode fixtures). Each demonstrates one reconciliation outcome so you can try the flow with zero real data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds that scenarios demonstrate reconciliation outcomes, which is consistent but does not disclose additional behavioral traits beyond 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?
Two sentences with no wasted words. Front-loaded with the action 'List' and immediate context. Every sentence adds value.
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?
Tool has zero parameters, output schema exists, and context signals show high coverage. Description sufficiently explains what it does and why it is useful, leaving no gaps.
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?
No parameters exist, and schema coverage is 100%. Baseline 4 applies as description does not need to add param info but explains the output's purpose.
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?
Description specifies 'List the built-in sandbox scenarios' with a clear verb and resource. It distinguishes from sibling tools like load_sandbox_scenario and run_sandbox_scenario by stating these are test-mode fixtures for trying flows with zero real data.
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?
Description implies usage when wanting to try reconciliation with test data, providing context. It does not explicitly exclude alternatives but the sibling names suggest distinct purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the expected/observed inputs for one named sandbox scenario, so you can inspect or edit the fixture before reconciling.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Scenario name, e.g. 'clean_match'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description aligns with annotations (readOnlyHint, idempotentHint, destructiveHint false) and adds context: tool is for inspection before reconciliation, which is beyond what annotations provide.
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?
Single sentence with no redundant words. Front-loaded with verb and resource, efficiently conveying purpose and usage context.
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?
Given the presence of an output schema, description adequately explains return value ('expected/observed inputs') and places tool in workflow ('before reconciling'). No gaps.
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% for the single parameter 'name', but description adds a concrete example ('clean_match') and context about being 'one named' scenario, enhancing understanding beyond schema.
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?
Description explicitly states 'Return the expected/observed inputs for one named sandbox scenario', providing a specific verb and resource. It distinguishes from siblings like list_sandbox_scenarios (list all) and run_sandbox_scenario (run).
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?
Describes purpose as 'inspect or edit the fixture before reconciling', clearly indicating when to use. Does not explicitly mention when not to use or alternatives, but context from siblings clarifies scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two amounts in different currencies, converting one via a supplied FX rate and matching if the percentage difference is within tolerance. Uses exact decimal arithmetic.
| Name | Required | Description | Default |
|---|---|---|---|
| fx_rate | Yes | Units of currency_a per one unit of currency_b (e.g. an EUR/USD quote of 1.08 is USD per EUR). | |
| amount_a | Yes | Amount denominated in currency_a. | |
| amount_b | Yes | Amount denominated in currency_b. | |
| currency_a | Yes | ISO 4217 code of amount_a. | |
| currency_b | Yes | ISO 4217 code of amount_b. | |
| tolerance_pct | No | Max percentage difference still counted as a match. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavioral detail by disclosing exact decimal arithmetic, the conversion direction, and that matching is percentage-difference based—useful context beyond 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?
Two concise sentences front-load the core purpose and then add the important precision detail. Every sentence earns its place with no repetition of schema or annotation information.
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?
Given the detailed input schema, an output schema, and annotations covering safety and side-effect behavior, the description is complete for an agent to select and correctly invoke the tool. The matching logic and decimal arithmetic caveat are the only missing pieces, and both are supplied.
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?
The schema already provides 100% parameter coverage with clear descriptions. The description adds value by explaining how the parameters interact algorithmically: one amount is converted via fx_rate and compared by percentage difference, which is not fully captured in individual parameter docs.
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 uses a specific verb ('Compare') and identifies the exact resource and operation: two amounts in different currencies, converted via an FX rate and matched within tolerance. This clearly distinguishes the tool from siblings like match_names_probabilistic or reconcile_many_to_many.
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?
The description implies the use case: matching currency amounts with FX conversion and tolerance. However, it does not explicitly state when to prefer this tool over related siblings such as reconcile, reconcile_many_to_many, or explain_match, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score two counterparty names with Jaro-Winkler similarity and report whether they match at a given threshold. Tolerant of legal-suffix drift, e.g. 'ACME Corp' vs 'ACME Corporation Inc'.
| Name | Required | Description | Default |
|---|---|---|---|
| name_a | Yes | First counterparty name. | |
| name_b | Yes | Second counterparty name. | |
| threshold | No | Similarity in [0, 1] at or above which the pair is a match. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnly/idempotent/destructive annotations already covering safety, the description adds meaningful behavior: Jaro-Winkler similarity, threshold semantics, and tolerance for legal-suffix drift with a concrete example. 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?
Two sentences with the main verb and resource front-loaded. The legal-suffix example is compact and illustrates the tool's value without wasting space.
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 three-parameter primitive with full schema coverage, rich annotations, and an output schema, the description covers algorithm, input semantics, and intended tolerance. No material gap prevents correct invocation.
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 descriptions already cover all three parameters (100% coverage), so the baseline applies. The description adds only contextual color about counterparty names and 'given threshold,' but no new semantics for parameter format or defaults.
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?
Clearly identifies a specific verb (score/report) and resource (two counterparty names), and names the algorithm (Jaro-Winkler) plus threshold-based output. This separates it from amount-matching and reconciliation siblings.
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?
The description implies this is for fuzzy name matching, especially with legal-suffix variation, but it never names alternative tools or states conditions for choosing between them. Siblings like match_amounts_with_fx_drift and explain_match are left to the agent to distinguish.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert parsed camt.053 statement entries into canonical observed records ready to reconcile. Accepts a list of entries or a dict wrapping them under 'entries'/'transactions'/'statements'.
| Name | Required | Description | Default |
|---|---|---|---|
| document | Yes | Parsed camt.053 document or entry list. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description is not burdened with those. It adds value by explaining the output (canonical observed records ready to reconcile) and input flexibility (list or dict with specific keys), which goes beyond 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?
The description is two sentences long, each serving a distinct purpose: first sentence states the core function and output, second sentence details input flexibility. No redundant words, and key information is front-loaded.
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?
Given the tool's complexity (flexible input, conversion to canonical records) and the presence of an output schema and comprehensive annotations, the description covers the essential aspects. It could be slightly improved by mentioning expected input format constraints or error handling, but is largely complete.
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?
The schema description for the only parameter 'document' is generic, but the tool's description adds crucial details: it accepts a list of entries or a dict wrapping them under 'entries', 'transactions', or 'statements'. This significantly enriches the meaning beyond the schema.
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 clearly states the tool converts parsed camt.053 statement entries into canonical observed records ready for reconciliation. It specifies the resource (camt.053 entries) and the action (convert), and the name itself distinguishes it from sibling normalize_pain001 (different standard).
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?
The description does not explicitly state when to use this tool versus alternatives like normalize_pain001 or reconcile. It implies usage after parsing camt.053 and before reconciliation, but provides no guidance on when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert parsed pain.001 payment instructions into canonical expected records ready to reconcile. Accepts a list of transactions or a dict wrapping them under 'transactions'/'payments'/'records'.
| Name | Required | Description | Default |
|---|---|---|---|
| document | Yes | Parsed pain.001 document or transaction list. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, indicating safe read-only behavior. The description adds that the tool converts to canonical records but does not disclose additional behavioral traits beyond what annotations provide.
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?
The description is two sentences with no wasted words. The first sentence states the primary purpose, and the second clarifies input flexibility. Every sentence adds value, and the structure is front-loaded.
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?
Given the single required parameter and the presence of an output schema (as indicated by context), the description sufficiently explains input variations. It does not detail the output format, but that is covered by the output 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 coverage is 100% with a single parameter 'document' described as 'Parsed pain.001 document or transaction list.' The description adds further detail on accepted input structures (list or dict with specific keys), which adds meaning beyond the schema alone.
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 clearly states the verb 'Convert' and the resource 'parsed pain.001 payment instructions' into 'canonical expected records ready to reconcile'. This distinguishes it from sibling tools like normalize_camt053 which handles a different document type.
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?
The description explains acceptable input formats (list of transactions or dict with specific keys) but does not explicitly state when to use this tool versus alternatives like normalize_camt053 or other siblings. The usage context is implied but not formally guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reconcile expected payments against observed bank-statement entries, returning exact matches, short/over payments, split settlements (one-to-many), batch credits (many-to-one) and unmatched residuals, each with an explainable score and reasons.
| Name | Required | Description | Default |
|---|---|---|---|
| options | No | Optional tuning object: 'abs_tol'/'rel_tol' (amount tolerance), 'date_window_days', 'high_threshold', 'review_threshold', 'currency_strict', 'enable_one_to_many', 'max_combination'. | |
| expected | Yes | List of canonical records. Each is an object with 'id' (string) and 'amount' (number) required, plus optional 'currency' (ISO 4217), 'date' (ISO-8601), 'counterparty' (name), 'reference' (remittance/end-to-end id). | |
| observed | Yes | List of canonical records. Each is an object with 'id' (string) and 'amount' (number) required, plus optional 'currency' (ISO 4217), 'date' (ISO-8601), 'counterparty' (name), 'reference' (remittance/end-to-end id). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is read-only, idempotent, and not destructive. The description adds behavioral context by detailing the outcome (matched categories with scores and reasons) and implies no side effects, which is consistent with annotations. No contradictions.
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?
The description is a single sentence that efficiently conveys the core action and expected outputs. It is front-loaded with the main verb and resource. While it packs information densely, it remains clear and avoids unnecessary verbosity.
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?
Given the tool's complexity (3 parameters, output schema available, annotations provided), the description adequately explains the return types (exact matches, short/over, split settlements, etc.) and suggests the algorithm's behavior. It covers the essential context for an agent to understand input/output expectations.
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 the schema already documents all parameters well. The description summarizes the 'options' tuning object but does not add significant new semantics beyond what is in the schema. It restates the parameter roles at a high level, achieving a baseline score.
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 clearly states the verb 'Reconcile' and the specific resources 'expected payments' and 'observed bank-statement entries'. It lists the types of matches returned, making the purpose unambiguous. It also distinguishes from sibling tools like list_sandbox_scenarios and explain_match, which serve different functions.
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?
The description explains the tool's purpose for reconciliation and describes the various match types, providing clear context for when to use it. However, it does not explicitly state when not to use it or mention alternative tools for similar tasks, missing an opportunity for clearer guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Match each statement/deposit to a disjoint subset of invoices whose amounts sum to it (bounded subset-sum solved as an integer program). Returns matched groups and the unmatched residuals on each side.
| Name | Required | Description | Default |
|---|---|---|---|
| invoices | Yes | List of canonical records. Each is an object with 'id' (string) and 'amount' (number) required, plus optional 'currency' (ISO 4217), 'date' (ISO-8601), 'counterparty' (name), 'reference' (remittance/end-to-end id). | |
| statements | Yes | List of canonical records. Each is an object with 'id' (string) and 'amount' (number) required, plus optional 'currency' (ISO 4217), 'date' (ISO-8601), 'counterparty' (name), 'reference' (remittance/end-to-end id). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and idempotent; the description adds meaningful behavioral details by stating it solves a bounded subset-sum as an integer program, enforces disjointness, and returns matched groups plus residuals on both sides. This goes beyond the structured annotations without contradicting them.
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?
Two sentences contain the core matching behavior and the return shape with no filler. The key constraint (disjoint subset-sum) is front-loaded, and every sentence contributes something.
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?
With a rich output schema, full parameter documentation, and annotations covering safety/idempotence, the description covers the essential behavioral contract. It could add more about currency/date handling or performance limits for large integer programs, but these are not critical given the structured fields.
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 the parameters are already fully documented with required fields and optional attributes. The description adds the matching semantics (invoice subsets summing to statement amounts), but it does not add syntax or format details beyond schema. Baseline 3 is appropriate.
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 names a specific operation: matching each statement/deposit to a disjoint subset of invoices that sum to it, which clearly distinguishes it from a plain reconcile tool. The bounded subset-sum/integer program detail further specifies the method. This is more specific than the title and separates it from siblings like reconcile and explain_match.
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?
The description makes the applicable scenario clear: many-to-many reconciliation where a statement amount is covered by several invoices and unmatched residuals should be reported. It does not explicitly name alternatives or when-not-to-use conditions, but the semantics are specific enough that an agent can infer when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a named sandbox scenario and immediately reconcile it -- the one-call way to see a full, explainable result with zero setup. Great for a first run or a smoke test.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Scenario name, e.g. 'month_end'. | |
| options | No | Optional tuning object: 'abs_tol'/'rel_tol' (amount tolerance), 'date_window_days', 'high_threshold', 'review_threshold', 'currency_strict', 'enable_one_to_many', 'max_combination'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint as true and false respectively, so the safety profile is clear. The description adds 'immediately reconcile' and 'full, explainable result' but does not detail any side effects or additional behavioral traits beyond what annotations provide.
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?
The description is two sentences, front-loaded with the core action, and every word serves a purpose. No redundancy or fluff.
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?
Given the presence of an output schema and the clear description covering the combined load-and-reconcile action, the description is sufficiently complete for an agent to understand what the tool does and what to expect.
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 the schema already documents both parameters fully. The description does not add any extra meaning or context to the parameters beyond the schema.
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 clearly states it loads a named sandbox scenario and reconciles it, contrasting with sibling tools load_sandbox_scenario and reconcile which do each separately. The phrase 'one-call way to see a full, explainable result with zero setup' provides a specific verb and resource.
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?
The description explicitly recommends use for 'a first run or a smoke test', giving clear context for when to use. It does not exclude other scenarios, but the guidance is helpful and non-misleading.
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.
v0.0.5match_amounts_with_fx_driftmatch_names_probabilisticreconcile_many_to_manyv0.0.2explain_matchlist_sandbox_scenariosload_sandbox_scenarionormalize_camt053normalize_pain001reconcilerun_sandbox_scenarioScored across 10 tools
Most tools have clearly distinct roles: normalization, scenario management, pairwise matching, and the main reconcile flow. The only real overlap is between `reconcile` and `reconcile_many_to_many`, whose descriptions make the advanced grouping case explicit but could still lead an agent to pick the wrong one for many-to-one batch-credit scenarios.
All tools use consistent snake_case verb-first names, with clear patterns like normalize_<format>, match_<target>_<method>, and sandbox-scenario lifecycle verbs. The naming makes the toolset predictable and easy to navigate.
Ten tools is a well-scoped size for a reconciliation server: a main reconciler, an explainability aid, two input normalizers, a sandbox set, and specialized matchers. Each tool serves a distinct purpose in the reconciliation workflow without feeling padded or redundant.
The surface covers the full reconciliation flow end to end: normalize inputs, run reconciliation, explain scores, inspect/reset with sandbox scenarios, and handle advanced many-to-many cases. No critical dead ends or missing lifecycle operations are apparent for the stated purpose.
Pre-payout IBAN screening for AI agents: validation, sanctions, Swiss clearing, risk scoring
Documents in, reconciled double-entry books out. Statements, invoices, receipts, matched and posted.
Cross-border payment & banking intelligence for AI agents: SWIFT/BIC, IBAN, sanctions, FX, tracking.
Deterministic banking, LEI, VAT, SWIFT & compliance checks via MCP with signed XDR-1 receipts.
