Skip to main content
Glama
Sign In
e-arveldaja MCP Server

e-arveldaja MCP Server

by iseppo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Reconcile Inter-Account Transfers

reconcile_inter_account_transfers
Destructive

Matches own-account bank transfers and reconciles them safely: dry-run builds a reviewed plan, then execute confirms the reviewed set while skipping already journalized transfers.

Instructions

Match own-account bank transfers. DUPLICATE-SAFE: skips transfers already journalized from the other side. DRY RUN by default returns a plan_handle enumerating the reviewed confirms/deletes; execute=true REQUIRES that handle and runs exactly the reviewed set. For one-sided transfers with 2+ possible targets, pass target_accounts_dimensions_id.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "reconcile_inter_account_transfers"
  }
}

Input Schema

NameRequiredDescriptionDefault
executeNoActually confirm matched pairs (default false = dry run)
keep_sideNoInter-account only: which leg of a matched transfer pair is confirmed (the other is deleted). Default outgoing. incoming requires a checksum-verified incoming CAMT marker on that leg, else the pair goes to ambiguous_pairs (direction_unresolved). Resend the same value at execute.
plan_handleNoExecution-plan handle from the reviewed dry run. Required for execute=true.
max_date_gapNoMaximum days between C and D transaction dates (default 1, max 31)
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 one-sided transfers (no matching D/C pair), specify the target bank account dimension ID. Required when there are 3+ bank accounts and counterparty IBAN is missing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.39.0
    • addedInput schema / properties / keep_side
      Added value: +{
+  "description": "Inter-account only: which leg of a matched transfer pair is confirmed (the other is deleted). Default outgoing. incoming requires a checksum-verified incoming CAMT marker on that leg, else the pair goes to ambiguous_pairs (direction_unresolved). Resend the same value at execute.",
+  "enum": [
+    "outgoing",
+    "incoming"
+  ],
+  "type": "string"
+}
  2. 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"
+}
  3. Changed1 schema field changedv0.29.2
    • addedInput schema / additionalProperties
      Added value: +false
  4. Addedv0.25.3
  5. Removedv0.25.2
  6. First observedv0.18.1

TDQS

A4.2/5.0
Behavior5/5

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

Goes well past the annotations (destructiveHint=true, readOnlyHint=false) by disclosing the duplicate-safety guarantee, the two-phase dry-run/plan_handle contract that binds execution to exactly the reviewed set, and the one-sided-transfer resolution path. That is precisely the behavioral context an agent needs before invoking a destructive mutation.

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?

Four dense sentences, front-loaded with purpose and then the safety contract; nothing is redundant. The all-caps labels and shorthand ('DUPLICATE-SAFE', 'REQUIRES') are efficient but slightly telegraphic.

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

Completeness4/5

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

For a destructive six-parameter tool with no output schema, the description covers the execution lifecycle and the one non-obvious parameter. It could say more about what the dry-run result enumerates beyond confirms/deletes (e.g. ambiguous pairs), but the essential call contract is complete.

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 adds real meaning on top: it explains why target_accounts_dimensions_id exists (one-sided transfers, 2+ possible targets) and how plan_handle and execute are coupled. keep_side and delete_proposed_mirrors are left entirely to their schema text, which is why this stops short of a 5.

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 verb and a tightly scoped resource: 'Match own-account bank transfers'. The 'own-account' qualifier implicitly separates it from the broader reconcile_bank_transactions sibling, though no sibling is named explicitly.

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 clear operational context: dry run is the default, execute=true requires the plan_handle from that reviewed dry run, and target_accounts_dimensions_id is the fallback for one-sided transfers with 2+ candidate targets. It never states when to prefer this over reconcile_bank_transactions or batch_confirm_journals, so routing between siblings is left partly to inference.

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