Skip to main content
Glama

List document acquisitions

well_list_document_acquisitions
Read-only

List the collect runs that fetched one document, oldest first: the run that first brought it in, then each later run that fetched the same file again and recognised it. Each row gives the collect_id, the provider, the run's status, the outcome for this document (created, already_processed or reprocess_required) and when it was fetched.

Use it to answer "where did this invoice come from?" or "was this receipt fetched twice?". Pass the document_id. Page with cursor from the previous result's next_cursor. A document of another workspace, or a deleted document, returns an empty list.

When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass workspace_id on the call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoAcquisitions to return, at most 500. Default 50.
cursorNoThe next_cursor of the previous page.
document_idYesThe document_id of the document whose acquisitions to list.
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several: this read reports one workspace's own figures and will not choose 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.
workspace_scopeNoRestrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNo
successYes
next_cursorNo
acquisitionsNo
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
newly_connectedNoTools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.
resolved_workspaceNoThe workspace that answered, when the caller named none and the token authorizes several.
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: oldest-first ordering, that a document from another workspace or a deleted document yields an empty list, and that the read explicitly refuses to guess a workspace when several are authorized.

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?

Front-loaded with what the tool returns before moving to usage and workspace routing, and each paragraph carries distinct information (row shape, use cases, token/workspace rules). It is a little long at three paragraphs, but no sentence is filler.

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?

Covers the things that actually block correct invocation: which parameter selects the document, how to page, and when workspace_id is mandatory versus omittable. With an output schema present, the description need not explain return values, and its edge-case notes on empty lists round it out.

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 six parameters, including the workspace_id required-when-several rule and the conversation_id round-trip. The description restates those rules rather than adding syntax or format detail the schema lacks, so 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?

States a specific verb and resource with unusual precision: 'the collect runs that fetched one document, oldest first', then enumerates the fields each row carries. That level of specificity (fetch runs per document, with collect_id/provider/status/outcome) implicitly separates it from the nearby well_list_document_events sibling, which returns a different kind of history.

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?

Gives concrete questions the tool answers ('where did this invoice come from?', 'was this receipt fetched twice?'), which is exactly the when-to-use guidance an agent needs. It also states the precondition for workspace routing and the sequential-call rules (pass cursor from next_cursor; pass conversation_id on every call in the same conversation).

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