Well

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

Name	Required	Description
`since_date`	No	Only diff bank transactions on/after this date (YYYY-MM-DD).
`workspace_id`	No	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.
`idempotency_key`	No	Optional client-supplied key. A retried write with the same key returns the original result instead of re-applying the operation.
`bank_workspace_connector_id`	Yes	The bank connector's workspace_connector_id (e.g. Plaid).
`register_workspace_connector_id`	Yes	The accounting connector's workspace_connector_id (e.g. QuickBooks).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`error`	No
`enabled`	No
`matched`	No
`success`	Yes
`gaps_proposed`	No
`already_linked`	No
`raised_for_review`	No
`missing_in_register`	No
`contended_in_register`	No
`gaps_already_proposed`	No
`missing_in_register_ids`	No
`unexplained_in_register`	No
`contended_in_register_ids`	No
`unexplained_in_register_ids`	No

TDQS

A4.5/5.0

Behavior5/5

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

The description extensively discloses side effects beyond the annotations: matches become review tasks with candidates attached, gaps are minted as proposals, contended transactions are never minted, and results are persisted. It even explains the two underlying causes of contended results, including provider failures and invalid model responses.

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?

The description is organized with a summary sentence followed by four focused bullet points, each covering a distinct output category. Although long, every sentence contributes operational detail, and the feature-disabled note is appropriately placed at the end. Nothing feels redundant.

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?

The description covers every outcome class: raised_for_review, missing_in_register_ids, gaps_proposed, gaps_already_proposed, contended_in_register_ids, and unexplained_in_register_ids, plus the disabled-return behavior. Since an output schema exists and parameter schemas are complete, no essential context is missing.

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?

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds no additional parameter meaning beyond mentioning QuickBooks as an example register, which the schema already includes. The baseline of 3 applies.

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 opening sentence states the specific verb 'Diff' with a clear resource: bank transactions against accounting-register transactions, and notes that the result is persisted. This distinguishes it from sibling follow-up tools like well_resolve_reconciliation_task, which the description explicitly names as later steps.

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 provides practical workflow guidance: no automatic linking, resolution via well_resolve_reconciliation_task and well_resolve_register_diff_gap, and advice to re-run later for contended_in_register_ids. It also flags the feature-off disabled return. There is no sibling diff tool, so explicit alternative selection is unnecessary.

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

All Well tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: CRUD for companies, people, and invoices; financial analytics (cash, cost, runway, holdings); connector management and invocation; schema discovery; querying; reconciliation; and contact channel management. No two tools could be confused for the same action.

Naming Consistency5/5

All tools follow the `well_verb_noun` pattern with consistent verb choices (create, get, list, update, delete, add, remove, run, resolve, query, invoke). The naming is predictable and makes the tool's purpose immediately clear.

Tool Count4/5

With 26 tools, the set is slightly above the ideal 3-15 range, but every tool earns its place given the breadth of the domain (CRM, invoicing, financial analytics, reconciliation, connector management). The count is well-scoped and not excessive.

Completeness4/5

The tool surface covers core CRUD, financial KPIs, reconciliation, and connector management. Minor gaps exist (e.g., no direct tool to update contact channels or manage accounts), but the query and schema tools allow agents to work around them, and the primary workflows are fully supported.

Resources

Need Help?