FinStat

Generate balance sheet

generate_balance_sheet

Read-onlyIdempotent

Generates a standard balance sheet for one chart as of one date: assets, liabilities, and equity by account with totals, and the Assets = Liabilities + Equity verdict. chart_id is required only when the workspace has more than one active chart; as_of_date is an inclusive cutoff, and omitting it means all posted activity; include_zero_accounts defaults to true. Amounts are summed as posted. completeness says what the books lack: a chart_exception (nothing posted since the data changed), open requests, notices. Read-only and not metered.

Input Schema

Name	Required	Description
`chart_id`	No	Optional chart id. Required when the workspace has more than one active chart; may be omitted when exactly one exists.
`as_of_date`	No	Optional inclusive cutoff date in YYYY-MM-DD format. Omitted means all posted activity.
`workspace_tag`	Yes	Active workspace id (the workspace_tag create_workspace and list_workspaces return).
`include_zero_accounts`	No	Include chart accounts with no posting activity. Defaults to true.

Output Schema

Name	Required	Description
`assets`	Yes	Asset rows.
`engine`	Yes	Stamped engine build/version identity for the tool result.
`equity`	Yes	Equity rows: ending equity without current earnings; those sit in net_income.
`status`	Yes	balance_sheet_generated on success.
`balanced`	Yes	True when total_assets equals total_liabilities plus total_equity.
`chart_id`	Yes	The one chart this report covers.
`as_of_date`	Yes	Inclusive cutoff; null means all posted activity.
`chart_name`	Yes	The chart's name.
`net_income`	Yes	Current earnings through the date, not yet closed to equity; included in total_equity — the standard Net Income row.
`liabilities`	Yes	Liability rows.
`completeness`	Yes	What these books lack. complete is true only with no chart_exception and no open request. A chart with an exception has posted nothing since the data changed, so the numbers predate it; open requests (list_review_items, level request) leave the books short or provisional; notices change nothing.
`total_assets`	Yes	Sum of detail asset amounts.
`total_equity`	Yes	Detail equity plus net_income.
`workspace_tag`	Yes	Workspace scoped by the tool call.
`total_liabilities`	Yes	Sum of detail liability amounts.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Adds context beyond the annotations: amounts are summed as posted (no adjustments), the completeness field reports chart_exception, open requests, and notices, and the tool is not metered. 'Read-only' merely restates readOnlyHint, but the aggregation semantics and completeness semantics are genuinely new information.

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?

One front-loaded paragraph: the core action and scope come first, then parameter nuances, then behavioral notes. It is dense with semicolon-chained clauses and could be split for readability, but no sentence is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return shapes needn't be spelled out, and the description still explains the notable completeness/ chart_exception field and the lack of metering. For a read-only, idempotent report generator this covers what an agent needs, though cross-tool routing guidance is absent.

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 coverage is 100%, and the description largely restates the schema's own wording for chart_id conditionality, the inclusive YYYY-MM-DD cutoff, and the include_zero_accounts default. The baseline 3 applies because the schema already carries these semantics with no added nuance.

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 ('Generates a standard balance sheet') plus the exact scope ('for one chart as of one date') and the contents it returns (assets, liabilities, equity by account with totals, and the A = L + E verdict). This clearly distinguishes it from siblings like generate_trial_balance and generate_profit_and_loss.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete conditional guidance: chart_id is needed only when the workspace has more than one active chart, and omitting as_of_date means all posted activity. It does not, however, say when to prefer this over generate_trial_balance or generate_profit_and_loss, so sibling selection is left to inference.

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?