Skip to main content
Glama

Find candidate transactions bulk

find_candidate_transactions_bulk
Read-only

BULK / multi-document version of find_candidate_transactions: for MANY outstanding documents at once, return each document alongside its candidate settling bank transactions + best match, in ONE read-only call — so reconciling a large AP/AR backlog needs one call, not one round-trip per bill. Select the document set EITHER by passing an explicit documentids list, OR with the same filters as list_documents (type, direction in/out, contact, status e.g. overdue, from/to due-date range, unpaid, min_outstanding) — e.g. type=bill + unpaid + status=overdue to pull candidates for every overdue bill. Capped at limit documents (default 50, hard max 200); when more match, truncated is true and matched reports the full count, so narrow the filter or page. Returns {results [{document {...}, candidates [transactions], best {transactionid, confidence, reason}}], count, matched, truncated, limit}. READ-ONLY: it suggests matches, never records them (settle bills via settle_bills). To settle an invoice, first check whether the candidate's bank line already has its own income: list_transactions shows it in that line's $incomeids. If it does, settle with save_income, id = that income and accountid = the invoice id. Use record_document_payment only when the line has no income, because it always creates a new income and would count the money twice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoOnly documents with a due date on/before this date (inclusive, ISO 8601). Documents with no due date are kept.
fromNoOnly documents with a due date on/after this date (inclusive, ISO 8601). Documents with no due date are kept.
typeNoFilter the document set by kind (invoice, bill, …). Ignored when :documentids is given.
limitNoMax documents to process this call (default 50, hard max 200). If more match, :truncated is true and :matched reports the full count — narrow the filter or page.
statusNoFilter to documents whose computed status matches (case-insensitive), e.g. "overdue", "due", "partiallypaid".
unpaidNoWhen true, only documents with an outstanding balance (excludes fully paid rows). Recommended for reconciliation.
contactNoFilter to documents for this contact id (a client or supplier).
directionNoFilter by money direction: "in" (invoices, quotes, credit notes) or "out" (bills, purchase orders, debit notes).
documentidsNoExplicit list of document ids (cont-… or inv-…) to fetch candidates for. When given, the filter fields below are ignored. Foreign/missing ids are silently dropped.
min_outstandingNoOnly documents whose outstanding balance is at least this amount (inclusive).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / documentids / description
      Previous value: -"Explicit list of document ids (cont-…) to fetch candidates for. When given, the filter fields below are ignored. Foreign/missing ids are silently dropped."New value: +"Explicit list of document ids (cont-… or inv-…) to fetch candidates for. When given, the filter fields below are ignored. Foreign/missing ids are silently dropped."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, but the description goes far beyond: it states matches are suggested and never recorded, discloses the limit cap (default 50, hard max 200) and the truncated/matched semantics when more rows match, and spells out the double-counting hazard of record_document_payment. This is rich behavioral context an agent genuinely needs.

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?

Long but front-loaded and dense: the bulk purpose, selection modes, cap behavior, return shape, and settlement routing each earn their place. The settlement-routing sentences at the end are arguably tangential to *this* tool, but they prevent a costly double-payment mistake, so the length is justified rather than padded.

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?

Despite having no output schema, the description documents the return shape (results/document/candidates/best, count, matched, truncated, limit), the caps, and the null-vs-partial behavior. For a read-only, 10-param, no-required-param tool, nothing an agent needs to call it correctly is missing.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains the either/or semantics (filter fields are ignored when documentids is passed), the combination logic for filters, and the paging behavior tied to limit/truncated. It does not restate every param, but the additive value is clear.

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?

States a specific verb (find/return candidates) and resource (transactions for documents), and immediately frames itself as the 'BULK / multi-document version of find_candidate_transactions', distinguishing it from its closest sibling. An agent can tell exactly what it gets back (each document + candidates + best match) without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use ('reconciling a large AP/AR backlog needs one call, not one round-trip per bill'), the two selection modes, and a concrete filter example (type=bill + unpaid + status=overdue). It also routes away to alternatives: settle_bills for settling, save_income vs record_document_payment depending on whether a bank line already has income, and list_transactions to check $incomeids.

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