FinStat

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

Name	Required	Description
`all`	No	true installs every registered chart not yet posted, then posts every active chart. Exclusive with chart_id.
`chart_id`	No	The 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.
`declarations`	No	Registered 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_tag`	Yes	Active workspace id (the workspace_tag create_workspace and list_workspaces return).

Output Schema

Name	Required	Description
`charts`	Yes	One 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.
`engine`	Yes	Stamped engine build/version identity for the tool result.
`status`	Yes	chart_posting.
`posting_count`	Yes	Charts queued to post (status posting).
`versions_note`	No	With versions_not_installed: what happened to them.
`workspace_tag`	Yes	Workspace scoped by the tool call.
`retiring_count`	Yes	Charts this post retires instead of judging (status retiring or retired).
`unmatched_note`	No	With unmatched_declarations: what to do.
`exception_count`	Yes	Charts refused with a chart_exception.
`unmatched_declarations`	No	Present 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.
`versions_not_installed`	No	Present when any are: each registered next version of a chart that is retired, which no post will install, settled by this post (registered_document_id, chart_id, reason chart_retired). Listed once; it no longer waits for a post.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 6, 2026

addedOutput schema / properties / versions_not_installed

Added value: +{
+  "description": "Present when any are: each registered next version of a chart that is retired, which no post will install, settled by this post (registered_document_id, chart_id, reason chart_retired). Listed once; it no longer waits for a post.",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / versions_note

Added value: +{
+  "description": "With versions_not_installed: what happened to them.",
+  "type": "string"
+}

First observedNov 2, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Adds substantial behavior beyond the annotations: a fixed execution order (install, entries/voids, judge, retirements), atomic failure semantics ('posts nothing'), asynchronous queuing (status posting), and that model-backed posting is metered while the check is not. The idempotentHint=true claim sits a little awkwardly against 'each post with new chart-wide entries re-judges the chart's events', but the description never states a repeat call re-applies declarations ('not yet applied'), so this is ambiguity rather than contradiction.

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?

Front-loaded with the core action, but the body is a ~300-word run-on block of domain jargon ('claims', 'parties', 'register statement', 'judge and post') with almost no structural separation. Most sentences carry real information, yet the density and lack of paragraphing make it hard to parse on first read.

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 complex, multi-stage, async mutation with an output schema, the description covers ordering, failure/repair loop, independent per-chart outcomes, async follow-up, and the meaning of key response fields (bank_disagreements, unmatched_declarations, re-opened counts). Nothing an agent needs to invoke it correctly or interpret the immediate result appears missing.

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 nonetheless adds meaning the schema does not: chart_id installs a registered-but-unposted chart at first post, all is exclusive with it, and declarations accepts only chart-space documents (registered statements or workspace declarations are refused as not_postable). What it does not clarify is the default 'all' interaction with already-applied declarations beyond what the schema text says.

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 (posts) and resource (the workspace's events to a chart / every chart) plus the side effects it applies (journal-entry declarations, voids, retirements). It explicitly distinguishes itself from siblings by name: 'use submit' for registered statements/workspace declarations and 'repair it with update_standard_chart' for failed charts.

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 explicit when-to guidance ('Declare all of a period's journal entries first, then post once'), names the alternative tool for the excluded input class (submit), names the repair path (update_standard_chart then re-post), and names the required follow-up (wait_for_workspace_idle). Exclusions and sequencing are stated rather than inferred.

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

All FinStat tools Inspect

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

Need Help?