FinStat

Create Standard Chart

create_standard_chart

Read-only

Seals one Standard Chart from canonical chart JSON, exactly as written and with no model: the chart_of_accounts object (guide_canonical_schema, species chart) as document, or a retained UTF-8 handle holding it. CSV, notes and Markdown are not accepted; write the chart JSON first. What is not a fact is fixed up and listed in normalized: a field name in another case or with underscores, a code given as a number, an enum value in another case, the document marker, an envelope version. A fact is never fixed up: an unknown field, a missing required field, or a chart that breaks a chart law is refused with a stable code, the JSON path, what is wrong and what is needed.

Nothing installs and no party is minted. The result carries the sealed chart inline, retains the exact sealed bytes behind a multi-read download handle, and reports compatible and exceptions against the workspace data. Review it, then register the handle. A claim binds an account a submitted register statement is about; one that binds nothing yet shows as claim_unbound when registered: submit the statements, then post_chart_accounts installs and checks the chart, and if exceptions remain, update_standard_chart proposes the repair to register and post. Journal entries post to accounts (role account in list_chart_accounts), never to a category. Not metered.

Input Schema

Name	Required	Description
`handle`	No	Workspace-scoped transfer handle naming UTF-8 bytes of that same canonical chart JSON. Exclusive with document.
`document`	No	The canonical chart_of_accounts JSON object (guide_canonical_schema, species chart), sealed exactly as written. Exclusive with handle.
`source_name`	No	Optional label for where the chart came from, such as books.chart.json. Defaults to user.chart.json.
`workspace_tag`	Yes	Active workspace id (the workspace_tag create_workspace and list_workspaces return).

Output Schema

Name	Required	Description
`chart`	Yes	Sealed standard chart_of_accounts JSON document. This is the reusable artifact.
`owner`	No	Read-only preview of the FIRST owner: name and type, plus party_id/display when a live party already answers that mention, and on_submit reuse\|found. Submit founds; this call does not.
`engine`	Yes	Stamped engine build/version identity for the tool result.
`handle`	No	Multi-read download:N handle naming the retained sealed chart bytes — save them locally and pass to verify, open, or submit.
`owners`	Yes	Whose books: the chart's owner set, each a party mention (name, type) resolved at submit.
`status`	Yes	chart_created on success.
`retained`	No	Download descriptor for the retained sealed bytes: session_id, handle, file_name, media_type, byte_count, sha256, expires_at, download_program.
`file_name`	Yes	Suggested <entity>.chart.json file name.
`resources`	No	Related workspace resource links.
`chart_name`	Yes	Name asserted by the chart document.
`llm_called`	Yes	Always false: the chart is sealed exactly as given, with no model.
`normalized`	No	What was fixed up on the way, when anything was: each with path and change (a field renamed, a code written as a string, an enum value recased, the document marker added, an envelope version removed). Facts are never fixed up.
`owner_match`	Yes	Which account owner sets these books accept: any \| all \| exact \| subset.
`source_name`	Yes	Source label used for authoring context.
`content_hash`	Yes	Canonical SHA-256 identity of the chart document.
`workspace_tag`	Yes	Workspace that scopes authoring and metered usage.
`accounting_basis`	Yes	cash or accrual.
`preview_markdown`	Yes	Human-readable rendering only; never validate, submit, or install this field.
`chart_account_count`	Yes	Number of chart-account definitions.
`postable_chart_account_count`	Yes	Number of non-summary chart accounts.
`claimed_workspace_account_identifiers`	Yes	Workspace-account designators claimed by chart accounts.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing the side-effect profile ("Nothing installs and no party is minted"), the normalization list of auto-fixed non-facts, the refusal contract with stable codes plus JSON path and remedy, the multi-read download handle, and "Not metered". One caveat: sealing and retaining bytes is a state-producing behavior alongside readOnlyHint=true, though "nothing installs" keeps it from being a true 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 dense run-on block that chains normalization cases, refusal semantics, workflow, and claim semantics into long comma-spliced clauses. Most content earns its place, yet readability and scanability suffer noticeably.

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?

For a tool with a nested oneOf input and an output schema, this covers the missing pieces: input format restrictions, normalization versus refusal boundary, handle lifecycle, and the follow-on workflow. The remaining gap is that it explains return contents the output schema already provides, while never naming the nearest structural siblings for disambiguation.

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 already 100%, so the baseline is 3, but the description adds meaning the schema does not: the document must be a canonical chart_of_accounts per guide_canonical_schema, and the normalization rules (codes as numbers, enum case, underscore field names) tell the caller the document may be loosely formatted rather than strictly. source_name is left undocumented but is optional and self-describing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource: sealing one Standard Chart from canonical chart JSON, sealed exactly as written. It also carves out a boundary against siblings by stating "Nothing installs and no party is minted", which separates it from post_chart_accounts and update_standard_chart. The jargon-dense phrasing ("species chart", "retained UTF-8 handle") costs some immediate clarity, so it stops short of a 5.

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 explicit input constraints ("CSV, notes and Markdown are not accepted; write the chart JSON first") and an explicit next-step sequence: review the result, register the handle, then post_chart_accounts installs and checks, and update_standard_chart repairs residual exceptions. What it lacks is a direct comparison against create_standard_book or create_standard_declaration_chart, which are plausible confusable siblings.

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?