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 via settle_bills for bills or record_document_payment for invoices).

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.9/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description reveals key behaviors: the call never records matches, it is capped at limit with default 50 and hard max 200, it reports truncated and matched counts, it silently drops foreign/missing ids, and filter fields are ignored when documentids is given. This is rich, useful behavioral disclosure and is consistent with the annotation.

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 long but appropriately structured: purpose, selection modes, limits/truncation, return shape, and side-effect disclaimer each earn their place. For a complex tool with 10 optional parameters and no output schema, the density is justified and the core purpose is front-loaded.

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?

With no output schema, the description supplies the full return envelope including results, count, matched, truncated, and limit, as well as the paging/narrowing behavior. It also clarifies the read-only nature and names sibling settlement tools, so an agent has everything needed to invoke it correctly and safely.

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. The description adds meaningful semantic context by framing documentids vs the list_documents filter set as alternative selection modes and by providing a concrete example combination like type=bill + unpaid + status=overdue. This goes slightly beyond the schema's individual parameter descriptions.

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 'BULK / multi-document version of find_candidate_transactions' and explicitly states it returns each document with candidate settling bank transactions and best match in one read-only call. This clearly names a specific verb, resource, and scope, and distinguishes it from the single-document sibling tool.

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?

The description clearly says when to use the tool: for many outstanding documents or a large AP/AR backlog where one call replaces one round-trip per bill. It also explains the two selection modes and explicitly routes settlement actions to settle_bills or record_document_payment, making the boundary with alternatives obvious.

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