FinStat

Generate trial balance

generate_trial_balance

Read-onlyIdempotent

Generates a standard trial balance for one chart as of one date: chart-account debit and credit balances with totals, the difference, and the balance verdict — the check is Assets + Expenses = Liabilities + Equity + Revenue. 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
`rows`	Yes	Chart-account rows. Summary accounts display and are excluded from totals.
`engine`	Yes	Stamped engine build/version identity for the tool result.
`status`	Yes	trial_balance_generated on success.
`balanced`	Yes	True when the difference is zero.
`chart_id`	Yes	The one chart this report covers.
`row_count`	Yes	Number of returned rows.
`as_of_date`	Yes	Inclusive cutoff; null means all posted activity.
`chart_name`	Yes	The chart's name.
`difference`	Yes	total_debits minus total_credits.
`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_debits`	Yes	Sum of detail-account debit balances.
`total_credits`	Yes	Sum of detail-account credit balances.
`workspace_tag`	Yes	Workspace scoped by the tool call.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, it discloses that amounts are summed as posted, states the exact accounting-identity check, explains what the completeness field reports (chart_exception, open requests, notices), and notes the tool is not metered. These are genuine behavioral traits an agent cannot infer from annotations.

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?

A single dense paragraph that front-loads what the report contains, then parameter rules, then behavioral notes. Efficient with no filler, though the run of semicolon-clauses makes it slightly dense to scan.

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?

An output schema exists, so return shape needn't be spelled out, yet the description still clarifies the verdict logic and the completeness field's semantics. For a read-only, four-parameter report tool, nothing an agent needs to call it correctly is missing.

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 schema descriptions already state the conditional chart_id rule, the inclusive YYYY-MM-DD cutoff, and include_zero_accounts defaulting to true. The description restates these faithfully but adds little syntax or semantics beyond the schema, so baseline 3 applies.

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 trial balance for one chart as of one date') and enumerates the payload (debit/credit balances, totals, difference, verdict). This clearly separates it from sibling report generators like generate_balance_sheet 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 for parameters (chart_id required only when multiple active charts; omitting as_of_date means all posted activity). It does not explicitly say when to prefer this over generate_balance_sheet or generate_report, but the 'as of one date / one chart' scoping implies the distinction.

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?