Skip to main content
Glama
Sign In

FinStat

by ai.finstat
OverviewDiscussionsAdmin

Post chart accounts

post_chart_accounts
Idempotent

Posts the workspace's events to one chart (chart_id) or to every chart (all: true), and applies the journal-entry declarations, voids and retirements registered for it (declarations: a set of registered_document_id, or all, the default). A registered chart is installed at its first post, under the chart_id register returned, then checked. One order, every time: install, then journal entries and voids (applied before this call returns), then judge and post, then retirements last (a retirement applies once its chart's post has finished, or at once when the chart has exceptions). A chart this post retires (its retirement among the declarations posted) is not judged: its entries apply and it retires, status retiring or retired. declarations names chart-space documents only; a registered statement or workspace declaration is refused (not_postable): use submit. Each chart is first checked against the data, without a model: every owned primary account with movements must be bound by a claim, every claim must bind an account a register statement in the workspace is about, and every owner must be a party. A chart that fails returns a chart_exception naming each problem and posts nothing; repair it with update_standard_chart, register the chart it returns, and post it again: the post installs that next version under the same chart_id, add-only. A chart that passes is queued (status posting) and judges every pending event once; follow it with wait_for_workspace_idle. A row lists bank_disagreements when a declared cash line has no bank movement of its own: the author voids, corrects or keeps the entry. unmatched_declarations names registered entries whose "chart" is no chart's name here. Charts pass or fail independently. Declare all of a period's journal entries first, then post once: each post with new chart-wide entries re-judges the chart's events; each row says about how many the post's declarations re-opened. Model-backed posting is metered; the check is not.

Input Schema

NameRequiredDescriptionDefault
allNotrue installs every registered chart not yet posted, then posts every active chart. Exclusive with chart_id.
chart_idNoThe chart to post: an installed chart, or one registered and not yet posted (register returned its chart_id), which this post installs. Exclusive with all.
declarationsNoRegistered journal-entry declarations, voids and retirements to apply with this post: an array of registered_document_id, or "all" (the default) for every one registered for the posted chart and not yet applied.
workspace_tagYesActive workspace id (the workspace_tag create_workspace and list_workspaces return).

Output Schema

NameRequiredDescriptionDefault
chartsYesOne row per chart: chart_id, chart_name, status (posting, chart_exception, retiring or retired) and exceptions (each with exception, designator, account_id, events, first_date, last_date); installed (chart or next_version) when this post installed a registered chart or version; bank_disagreements and a bank_note when the book and the bank disagree: the lines of each conflict, numbered, whose declared cash lines compete for fewer bank movements (journal_entry_id, journal_line_id, entry_date, account_id, amount, bank_rows, declared_lines, unmatched, conflict); a posting chart adds reopened_by_declarations (about how many judged events the declarations it applied re-opened) and, when any were re-opened, a note.
engineYesStamped engine build/version identity for the tool result.
statusYeschart_posting.
posting_countYesCharts queued to post (status posting).
workspace_tagYesWorkspace scoped by the tool call.
retiring_countYesCharts this post retires instead of judging (status retiring or retired).
unmatched_noteNoWith unmatched_declarations: what to do.
exception_countYesCharts refused with a chart_exception.
unmatched_declarationsNoPresent when any are: each registered declaration waiting for a post whose "chart" names no active or registered chart in the workspace, so no post applies it (registered_document_id, document_kind, chart, reason no_chart or retired_chart). Kept: a chart registered later under that name takes it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, it discloses the install-then-entries-then-judge-then-retire order, that entries and voids are applied before return, that a retiring chart is not judged, and that model-backed posting is metered while the check is not. It also explains validation failure behavior via chart_exception and the posting queue status.

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 description is front-loaded with the core action and then layers necessary edge cases, with little obvious filler. It is dense and could be easier to scan if split into shorter sections, but the length is largely justified by the tool's complex workflow.

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?

Given the mutation behavior, 100% schema coverage, annotations, and an output schema, the description is complete enough: it covers failure modes, recovery, sequencing, and follow-up actions. An agent has what it needs to invoke the tool correctly and interpret where to go next.

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 schema already documents the parameters, but the description adds meaningful semantics: declarations must name chart-space documents, default to all, and registered statements or workspace declarations are refused. It also clarifies that chart_id may refer to an already-installed chart or one that this post installs.

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 states a specific verb and resource: it posts the workspace's events to one chart or every chart and applies journal-entry declarations, voids and retirements. It explicitly distinguishes the chart_id and all modes and names submit for the neighboring case of statements or workspace declarations.

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?

It gives explicit when-to-use guidance, including using submit for non-chart-space documents, repairing a failed chart with update_standard_chart and reposting, and following a queued post with wait_for_workspace_idle. It also advises declaring all period entries first and then posting once.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All FinStat toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources