Skip to main content
Glama
iseppo

e-arveldaja MCP Server

by iseppo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Reconcile Bank Transactions

reconcile_bank_transactions
Destructive

Match bank transactions to open invoices, dry-run and execute auto-confirmations, and detect and reconcile inter-account transfers.

Instructions

Merged bank reconciliation entry point. Use mode='suggest' for invoice-match suggestions, mode='dry_run_auto_confirm' or mode='execute_auto_confirm' for exact invoice matches (confidence >= 90, or the ref_number_exact rule: the reference of exactly one open unpaid EUR invoice + the exact EUR amount + a proven direction matching the invoice kind; such rows keep their lower confidence and carry auto_confirm_rule), mode='inter_account_dry_run' for own-account transfer detection, and mode='execute_inter_account' (REQUIRES the plan_handle from the dry run) to reconcile the reviewed inter-account transfers.

Input Schema

NameRequiredDescriptionDefault
modeNoWorkflow phase to run. Defaults to suggest.
plan_handleNoExecution-plan handle from the reviewed dry run. Required for mode='execute_auto_confirm' and mode='execute_inter_account', and forwarded to the executor.
max_date_gapNoMaximum days between inter-account transfer legs (default 1, max 31).
min_confidenceNoMinimum confidence threshold for invoice matching modes (auto-confirm default 90). Above 90 also disables the ref_number_exact rule.
block_on_duplicateNoFor the invoice-matching modes (suggest / dry_run_auto_confirm / execute_auto_confirm): refuse (or, in suggest, flag) an exact match whose cash movement appears already booked by another journal. Default false = advisory only.
delete_proposed_mirrorsNoInter-account only, opt-in: bind each proposed mirror deletion (a PROJECT row already journalized from the other account side) into the dry-run plan; execute deletes only rows still matching the reviewed identity. Resend the same value at execute.
target_accounts_dimensions_idNoFor inter_account_dry_run one-sided transfers, specify the target bank account dimension ID when it cannot be inferred.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.37.0
    • addedInput schema / properties / delete_proposed_mirrors
      Added value: +{
+  "description": "Inter-account only, opt-in: bind each proposed mirror deletion (a PROJECT row already journalized from the other account side) into the dry-run plan; execute deletes only rows still matching the reviewed identity. Resend the same value at execute.",
+  "type": "boolean"
+}
  2. Changed2 schema fields changedv0.29.2
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / min_confidence / description
      Previous value: -"Minimum confidence threshold for invoice matching modes."New value: +"Minimum confidence threshold for invoice matching modes (auto-confirm default 90). Above 90 also disables the ref_number_exact rule."
  3. Addedv0.25.3
  4. Removedv0.25.2
  5. Changed2 schema fields changedv0.21.0
    • addedInput schema / properties / min_confidence / maximum
      Added value: +100
    • addedInput schema / properties / min_confidence / minimum
      Added value: +0
  6. First observedv0.18.1

TDQS

A4.1/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (destructiveHint=true, idempotentHint=false) it discloses the two-phase dry-run-then-execute gating, that execute requires the reviewed plan_handle, and that mirror deletions only remove rows still matching the reviewed identity. That is unusually rich disclosure of how the destructive path is constrained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose then mode routing, and nearly every clause carries a rule or prerequisite. It is a single dense run-on sentence with nested parentheticals, which costs readability, but little is actually filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter, five-mode, destructive dispatcher with no output schema, the description covers inputs and safety well but says nothing about what each phase returns (a suggestions list, a reviewable plan plus plan_handle, an execution result) and nothing about the sibling inter-account tool. An agent could call it but would be guessing at the dry-run output shape.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description meaningfully extends it by explaining the ref_number_exact rule (one open unpaid EUR invoice + exact EUR amount + proven direction) and that such rows retain lower confidence and carry auto_confirm_rule. That is matching semantics the schema does not convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource and verb ('Merged bank reconciliation entry point') and enumerates all five workflow phases, so an agent knows exactly what the tool does. However, it never distinguishes itself from close siblings like reconcile_inter_account_transfers or classify_bank_transactions, even though two of its modes do inter-account transfer work — the word 'Merged' is the only hint of consolidation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit mode-by-mode routing ('Use mode=suggest for...', 'mode=inter_account_dry_run for own-account transfer detection') plus a hard prerequisite ('REQUIRES the plan_handle from the dry run'). It does not say when to pick this tool over the sibling reconcile_inter_account_transfers, so sibling-level alternatives remain unstated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools