Skip to main content
Glama

List journals still to post

well_list_unposted_journals
Read-only

List the transactions AND invoices of a fiscal period whose journal entry a posting retry can still clear on its own — the re-triggerable posting gap. An empty list with scan_truncated: false means no re-triggerable row remains in the rows scanned. That is NOT proof the period is posted: this read omits rows halted on a substantive reason a repost cannot clear (a missing ledger account, a tax gate, a locked period), so never declare the period posted on an empty read alone. If the close still reports an unposted blocker for this period, those rows need an accounting decision, not a re-trigger.

This is NOT the categorization surface. For a row that still needs a category or a ledger account, use well_list_unposted_transactions. This read carries only the rows that are ready to post and simply have not yet: the posting pipeline did not run. It never lists a row halted on a substantive reason (a missing ledger account, a tax gate, a locked period) — a retry only re-fails those, and the categorization and hydration steps own them.

Each row carries source_id, source_kind (transaction or invoice), name (the counterparty composite), amount, and period_date.

in_flight_processing: true means Well is still processing these rows — enrichment (classification, matching, re-extraction) is in flight, so wait and re-read rather than reposting. Re-read on the close's wait cadence until it is false; only then is the (i)-set settled enough to re-trigger. The paired write is well_repost_journals.

scan_truncated: true means the (i)-set was read from a bounded slice of the workspace's rows, not all of them. An empty list under this flag means "no re-triggerable row was found in the rows scanned", NOT "every row is posted" — do not tell the user the close can skip this step on a truncated empty read.

The period is named in FISCAL terms, and a workspace's fiscal calendar need not follow the calendar year. Take fiscal_year and fiscal_period from a well_list_periods entry, or from the months the user already selected this session; never derive them from a calendar month yourself.

success: false means the period is UNKNOWN, not clear. The read failed, so no count exists, and an empty records on a failed read is not "everything posted".

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

NameRequiredDescriptionDefault
limitNoMax rows to return.
fiscal_yearYesThe fiscal year of the period to read.
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.
fiscal_periodYesThe fiscal period, 1-12 for a month; 13 is the adjustment period and resolves to no rows.
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

NameRequiredDescriptionDefault
errorNo
recordsYes
successYes
returnedNo
scan_truncatedYes
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.
in_flight_processingYes
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. Changed2 schema fields changed
    • removedOutput schema / properties / resolved_workspace / properties / name / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / resolved_workspace / properties / name / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  2. Changed1 schema field changed
    • changedOutput schema / properties / newly_connected / description
      Previous value: -"Tools 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. Start the reply with 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."New value: +"Tools 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."
  3. Changed1 schema field changed
    • addedInput schema / properties / workspace_scope
      Added value: +{
      +  "description": "Restrict 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.",
      +  "enum": [
      +    "family"
      +  ],
      +  "type": "string"
      +}
  4. Changed1 schema field changed
    • addedOutput schema / properties / newly_connected
      Added value: +{
      +  "description": "Tools 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. Start the reply with 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.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "name": {
      +        "type": "string"
      +      },
      +      "service_id": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "name",
      +      "service_id"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  5. Added

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare readOnlyHint/destructiveHint, but the description adds substantial behavioral context: the meaning of empty results, scan_truncated semantics (partial scan, not proof of done), in_flight_processing (wait and re-read rather than repost), and success:false meaning UNKNOWN rather than clear. These are exactly the non-obvious traits an agent needs to avoid misreading results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core is front-loaded well, but the text is long and repeats the same parenthetical three times — 'a missing ledger account, a tax gate, a locked period' — once in the empty-read caveat and again in the NOT-the-categorization paragraph. That verbatim repetition is waste in an otherwise purposeful document. Still readable and structured, so not lower.

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?

Output schema exists, so return values needn't be explained; the description nonetheless enumerates the per-row fields and, critically, covers every failure mode (empty, truncated, in-flight, success:false) and the workspace/fiscal-calendar prerequisites. Complete for an agent to call and interpret it correctly.

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 coverage is 100%, so the baseline is 3. The description adds genuine value beyond the schema: it warns that fiscal_year/fiscal_period are FISCAL terms that may not match the calendar year and must come from well_list_periods or the user's selection, and clarifies the multi-workspace workspace_id requirement. It does not re-explain limit or conversation_id, but the schema already covers those.

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 (list), specific resources (transactions AND invoices of a fiscal period), and a precise scope qualifier — 'whose journal entry a posting retry can still clear on its own'. It explicitly contrasts with the sibling well_list_unposted_transactions, so an agent can distinguish the two without opening either 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 and when-not-to-use: 'This is NOT the categorization surface. For a row that still needs a category or a ledger account, use well_list_unposted_transactions.' Also names the paired write well_repost_journals and explains the single-vs-multi workspace call decision. Nothing left to inference.

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