reconciliation_executeExecuta o motor de conciliação em 3 camadas (regras determinísticas + fuzzy matching + LLM) para uma sessão. Retorna resumo com matches encontrados, taxa de automação e exceções.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | ID da sessão de conciliação a executar |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description does not contradict this. It adds context about the multi-layer process and the return summary, but doesn't elaborate on side effects or what gets destroyed. Given the annotation, the description provides some additional insight but not a full picture.
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?
A single sentence that efficiently conveys the core action, mechanism, and return type. It is front-loaded and every part contributes functional meaning, with no redundancy.
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 description covers the operation's result and mechanism, but misses workflow context (e.g., needing a session created and populated first) and doesn't detail the response structure beyond a summary. For a destructive, complex operation, this is a moderate gap, though annotations offset the destructive aspect.
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?
With 100% schema description coverage, the schema fully documents the only parameter (sessionId: number, 'ID da sessão de conciliação a executar'). The description adds no extra parameter detail, but that is unnecessary. Baseline of 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 clearly states that the tool executes the reconciliation engine with three layers (deterministic rules, fuzzy matching, LLM) for a session. This distinguishes it from sibling tools like reconciliation_create_session or reconciliation_import_entries, with a specific verb ('Executa') and resource ('motor de conciliação').
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?
No explicit guidance on when to use this tool versus alternatives. It doesn't mention prerequisites such as creating a session or importing entries, nor does it contrast with other reconciliation_* siblings. The implied usage context exists but is not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Many tools have distinct purposes, but several overlap: 'calcular_cbs_ibs' and 'consultar_aliquota_cbs_ibs' both deal with CBS/IBS rates, 'criar_cobranca' and 'criar_cobranca_pix' create similar things, and multiple metrics tools (dashboard_executivo, saude_financeira, autopilot_regua) could confuse an agent. The reconciliation_* group is well-differentiated, but overall the large, overlapping surface creates ambiguity.
Names mix Portuguese and English inconsistently (e.g., 'agendar_cobranca' vs. 'subscribe_webhook'). Most Portuguese names follow verb_noun, but many English names are noun_verb (e.g., 'reconciliation_execute') rather than verb_noun. Additionally, some names are vague or non-descriptive ('autopilot_regua', 'badges_contadores', 'metricas_escritorio'), breaking any predictable pattern.
61 tools is excessive for most MCP servers, even for a broad financial/fiscal automation domain. The count feels bloated, and several tools (e.g., criar_orcamento, listar_orcamentos) are dead weight being deactivated. This would likely be better split into multiple focused servers (e.g., cobranças, reconciliation, fiscal).
The tool surface covers many workflows: cobranças, NFS-e, reconciliation, tax simulation, dashboards, webhooks, and client insights. However, there are notable gaps in basic CRUD: no update/delete for cobranças or clientes, and no way to manage orcamentos (they're deactivated). The reconciliation module is very complete, but the overall surface has dead ends and missing lifecycle operations.