Skip to main content
Glama

Run register diff

well_run_register_diff

Diff a workspace's bank transactions against its accounting-register transactions (e.g. QuickBooks), and persist the result.

  • Every match — hard evidence (structured reference, IBAN, tax ID) or inference-only (memo/payee reading) — is raised as a review task with the candidate already attached (raised_for_review). Nothing links automatically; resolve with well_resolve_reconciliation_task once a human decides.

  • Bank transactions with no register counterpart come back as missing_in_register_ids, each also minted as a gap review task (gaps_proposed) — resolve one with well_resolve_register_diff_gap once a human names the two ledger accounts. gaps_already_proposed counts gaps re-surfaced from an earlier run that already have an open, unresolved proposal.

  • Bank transactions NOT confirmed absent from the register come back as contended_in_register_ids — never minted as a gap. Two cases land here: (1) a plausible match lost to a higher-confidence sibling transaction this run, so the register-side movement is already accounted for by the winner; (2) the matcher couldn't produce a trustworthy answer (an invalid model response or a provider failure), so absence was never confirmed. Re-run the diff later; a genuine gap or duplicate should resolve itself once the winner's review task is handled or the matcher succeeds.

  • Register entries no bank transaction explains come back as unexplained_in_register_ids.

Returns { enabled: false, ... } with all counts 0 if the workspace's register-diff feature is off.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
since_dateNoOnly diff bank transactions on/after this date (YYYY-MM-DD).
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several — a write lands in exactly one workspace and this call would not say which.
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.
idempotency_keyNoOptional client-supplied key. A retried write with the same key returns the original result instead of re-applying the operation.
bank_workspace_connector_idYesThe bank connector's workspace_connector_id (e.g. Plaid).
register_workspace_connector_idYesThe accounting connector's workspace_connector_id (e.g. QuickBooks).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNo
enabledNo
matchedNo
successYes
gaps_proposedNo
already_linkedNo
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
raised_for_reviewNo
missing_in_registerNo
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
contended_in_registerNo
gaps_already_proposedNo
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.
missing_in_register_idsNo
unexplained_in_registerNo
contended_in_register_idsNo
unexplained_in_register_idsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / conversation_id
      Added value: +{
      +  "description": "The conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / conversation_id
      Added value: +{
      +  "description": "The conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / conversation_id_note
      Added value: +{
      +  "description": "Present only when the server opened a fresh lane, stating that no choice recorded earlier was read.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / conversation_id_source
      Added value: +{
      +  "description": "Where the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.",
      +  "enum": [
      +    "host_meta",
      +    "argument",
      +    "minted"
      +  ],
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / workspace_id / description
      Previous value: -"Target workspace. Omit to use the only authorized workspace, or (for read tools) to query all authorized workspaces grouped by workspace. Required for write tools when the token authorizes more than one workspace."New value: +"Target workspace. Omit when the token authorizes one workspace. Required when it authorizes several — a write lands in exactly one workspace and this call would not say which."
  3. Added

TDQS

A4.4/5.0
Behavior5/5

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

The description goes far beyond the sparse annotations by disclosing side effects: it persists results, mints review tasks for matches, gaps, and unexplained register entries, and explicitly explains the contended_in_register_ids cases that are never minted as gaps. This is exactly the behavioral context an agent needs beyond readOnlyHint/openWorldHint/destructiveHint.

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?

The description is long but well-structured: a front-loaded one-sentence purpose, followed by clear bullets for each output category and the feature-off case. Each bullet carries meaningful behavioral information, though a bit more brevity would be possible without losing important edge-case detail.

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?

Given the tool's complexity, the description covers all essential behavior: match handling, gap proposals, contended cases, unexplained register entries, re-run guidance, feature-off return, and pointers to resolution tools. The output schema exists, so not repeating return-value structure is fine; the description is complete enough for correct invocation and follow-up.

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

Parameters3/5

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

The input schema already provides 100% description coverage, including purpose, formats, and workspace_id selection rules. The tool description adds overall behavioral context but does not add per-parameter semantics beyond what the schema gives, so the baseline of 3 is appropriate.

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

Purpose5/5

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

The description opens with a specific verb and resource: it diffs a workspace's bank transactions against accounting-register transactions and persists the result. It also distinguishes the tool from its resolution siblings by explicitly naming well_resolve_reconciliation_task and well_resolve_register_diff_gap, so an agent understands this is the diffing step, not the resolution 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?

The description says what the tool does and gives clear procedural guidance: matching is raised for review, nothing links automatically, use the named resolution tools once a human decides, and re-run later for contended cases. It does not state an explicit 'when not to use' condition or alternative tool for when the feature is off, but the feature-off return behavior is covered.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources