Skip to main content
Glama
norma43-mcp

norma43-mcp

by ArceeDev

reconcile_movements

Read-onlyIdempotent

Matches bank movements from Norma 43 files or lists to expected invoices or ledger entries, scoring confidence and evidence for 1:1, grouped, and partial payments.

Instructions

Bank reconciliation (conciliación bancaria): match bank movements to expected items, deterministically.

Bank side: a Norma 43 file (content / content_base64) or a movements list of {id, date, amount, text}. Expected side: expected list of {id, date, amount, reference?, counterparty?} such as issued invoices (+, cobros), supplier invoices or payroll (-, pagos), or ledger entries. Signs: + is money in, - is money out, as on the statement.

Finds 1:1 matches, one transfer paying several invoices (1:N) and partial payments (N:1). Each match has a 0-100 score, a confidence (alta/media/baja) and the evidence used (amount, invoice reference found in the bank concept, counterparty name, date distance, uniqueness). Ties are never guessed: they are returned under ambiguous. Weak candidates go to suggestions. Group matches require a unique exact sum plus reference or name evidence.

Args: expected: Items to find in the bank (max 5000). content: Norma 43 file as text (alternative to movements). content_base64: Norma 43 raw bytes as base64. movements: Bank movements if you do not have a Norma 43 file (max 5000). date_window_days: Max days between bank date and item date (default 10, max 180). amount_tolerance: Max amount difference accepted, e.g. "0.50" for bank fees (default "0", max "10"). max_group_size: Max items combined in 1:N / N:1 matches (1 disables grouping, max 5). min_score: Minimum score to confirm a match (default 50).

Input Schema

NameRequiredDescriptionDefault
contentNo
expectedYes
min_scoreNo
movementsNo
content_base64No
max_group_sizeNo
amount_toleranceNo0
date_window_daysNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses the actual matching behavior: 1:1, 1:N and N:1 support, a 0-100 score with alta/media/baja confidence, the evidence dimensions used, and the critical rule that ties are never guessed but returned under `ambiguous` and weak candidates under `suggestions`. That is exactly the operational context an agent needs to trust and act on results.

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

Conciseness5/5

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

Purpose is front-loaded in one sentence, then the data model, sign convention, matching behavior, and finally a compact Args block. The length is justified because the underlying schema contains zero descriptions, so no sentence is redundant filler.

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

Completeness5/5

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

For a reconciliation engine with eight parameters, an output schema, and no schema descriptions, the definition covers inputs, semantics, scoring behavior, and result buckets (matches, ambiguous, suggestions). Nothing an agent needs to invoke it correctly or interpret the output appears to be missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden, and it does: it documents the shape of `expected` and `movements` items, item caps (5000), the date window default and max (10/180), tolerance as a string with a bank-fees example, grouping behavior ('1 disables grouping, max 5'), and the min_score default. Only the max_group_size default is omitted, which is a minor gap.

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?

The first sentence states a specific verb and resource ('match bank movements to expected items') plus a key trait ('deterministically'), and the following paragraph defines both input sides and sign convention. It does not explicitly differentiate itself from siblings like parse_norma43 or norma43_to_csv, so an agent must infer that this is the matching step rather than the parsing step.

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?

It clearly states the two alternative input paths ('content' / 'content_base64' for a Norma 43 file versus a 'movements' list) and what the expected side should contain, which is the main usage decision. It stops short of explicit exclusions or telling the agent when to prereq-parse with a sibling instead of passing the raw file here.

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