Skip to main content
Glama

Re-trigger posting

well_repost_journals
Idempotent

Re-run (repost) the posting for this fiscal period's ready rows — the workspace's re-triggerable posting gap. This is the ACTION that books the rows well_list_unposted_journals lists as ready to post: when the accounting is ready and simply has not posted, calling this re-runs the deterministic posters and clears it. It operates on the ALREADY-RESOLVED workspace and takes no arguments — do not list or switch workspaces first.

This is NOT well_list_workspaces (which only enumerates workspaces and posts nothing), and NOT well_set_transaction_ledger_account (which assigns an account to ONE row that is MISSING one). This tool posts rows that already have everything they need; it never assigns an account or picks a category.

Do NOT call this while in_flight_processing is true — Well is still processing the rows (enrichment in flight); wait and re-read instead. Do NOT call it to fix a row that needs a category, a ledger account, or a party decision — those are substantive halts a retry only re-fails, and well_list_unposted_journals never lists them.

The re-run is workspace-scoped and idempotent: it re-posts the whole re-triggerable set, and the posters skip anything already booked, so a repeated press is safe. It returns enqueued (rows that reached their poster) and skipped (each row that did not, with a reason).

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
workspace_idNoTarget 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.
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.
idempotency_keyNoOptional client-supplied key. A retried write with the same key returns the original result instead of re-applying the operation.
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
skippedYes
successYes
enqueuedYes
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.
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. 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."
  2. 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"
      +}
  3. 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"
      +}
  4. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare idempotentHint=true, destructiveHint=false, readOnlyHint=false, but the description goes further: it explains the workspace-scoped idempotency mechanism ('the posters skip anything already booked'), the precondition that in-flight enrichment must finish first, and the return shape (`enqueued` and `skipped` with reasons). This is behavioral context well beyond the structured fields.

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?

The action, its precondition, and its exclusions are front-loaded in the first sentence, and each paragraph addresses a distinct concern (what it is, what it is not, preconditions/idempotency, return, workspace selection). It is on the long side and the final paragraph partially restates the schema's `workspace_id` guidance, which costs it the top score.

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?

For a zero-required-parameter, idempotent write with an output schema and full annotation coverage, the description supplies everything needed to call it correctly: preconditions, exclusions, workspace-scoping rules, and idempotency guarantees. Return values are additionally summarized even though an output schema exists.

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 and the schema already documents `workspace_id`, `conversation_id`, and `idempotency_key`. The description adds workflow-level meaning: no arguments are needed in the single-workspace case, do not list or switch workspaces first, and `workspace_id` is only required when multiple workspaces are authorized — reinforcing rather than merely repeating the schema.

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 precise verb and resource: re-run/repost the posting for this fiscal period's ready rows, explicitly framed as the ACTION counterpart to the read-only `well_list_unposted_journals`. It also names the siblings it is not (`well_list_workspaces`, `well_set_transaction_ledger_account`) and contrasts the scope of each, so an agent can disambiguate without opening another 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 (rows are ready and simply unposted), explicit when-not (do not call while `in_flight_processing` is true; do not call to fix a row missing a category, ledger account, or party decision, since the retry only re-fails). It also names the alternative reads and the workspace-selection procedure (direct call when one workspace is authorized; pass `workspace_id` when several are).

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