Skip to main content
Glama

schedule-iii

Read sealed consolidated statements

get_consolidated_statements
Read-only

CONSOLIDATED data class. Read one sealed group profit-and-loss, balance-sheet, or cash-flow face for an exact periodicity and period. The response exposes presentation currency and exactly one decimal-string amount per line: section-natural for P&L/BS, signed cash movement for CFS. Amounts are persisted on the sealed run; P&L/BS labels are current display metadata and the signed page_token is source-fingerprinted across the complete safe face, so a changed value or label requires restarting at page 1. A stale sealed run is disclosed on every page and is never called current. Member names, components, eliminations, journal references and lineage are not returned. QUALIFICATIONS. A response may carry owned_share_capital_caveat (at seal, share capital owned by the group could not be eliminated, so those amounts remained inside consolidated share capital as the engine computed it; the DISPLAYED line may differ in either direction where a manual journal also moved it, so never characterise the direction from this field alone) and always carries domestic_cash_flow_caveat. These qualify specific statement lines. When a caveat is present, any figure it qualifies MUST be presented together with its qualification — never the number alone. owned_share_capital_caveat is null when the run was read and carries no such qualification, and {status: "unavailable"} when the run’s qualification record could not be read at all, which is not the same as clean: say so rather than presenting the figures as final. WITHHELD CASH FLOW. cash_flow_status may say the cash flow was not presented — for a group with a foreign member, or for a window with no opening balance sheet to measure from. An empty cash_flow then means the statement was WITHHELD, never that the group had no cash movements: say so. For the missing-opening-basis case cash_flow_refusal carries the cause, the message and remedies, each tagged with the channel that can perform it — agent_or_app you can do here, app_only needs a person in the Datavrn app. Never present an app_only remedy as something you will do. cash_flow_opening_basis states what a PRESENTED statement measured from; "not_recorded" means the run was sealed before Datavrn recorded that, so its basis is unknown — do not assume a prior period. ROW ROLES. Every statement row carries row_role: "line" participates in its section total, "total" restates it (Profit after tax), "attribution" splits a total (the amounts attributable to the owners and to the minority interest). To total a section, sum ONLY rows whose row_role is "line" — including a total or attribution row would double-count the group’s profit. Present the attribution rows as the split of profit after tax, never as additional income. Consolidated cash-flow is available only for an all-domestic group in v1. If any member uses a foreign currency, Datavrn does not present a consolidated cash-flow statement. Where it is presented, it is prepared by the indirect method from balance-sheet movements rather than from cash records, and classified into operating, investing and financing activities using each entity’s reporting-line mapping. Interest paid and taxes paid are not disclosed separately, so they remain inside the operating movement; a movement whose reporting line carries no cash classification is shown under “Unclassified movements — review” rather than assigned to an activity. Datavrn does not present other comprehensive income or total comprehensive income in the consolidated output.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
groupYesAn active group UUID or its exact case-insensitive display name.
periodYesThe period matching periodicity.
page_sizeNoRows per source-pinned page (default 50, max 100).
statementNoStatement face (default pnl).
page_tokenNoSigned continuation from the prior page; restart without it if source_changed.
periodicityYesPeriod grammar: monthly YYYY-MM, quarterly FYyyyy-Qn, annual FYyyyy.

TDQS

A4.6/5.0
Behavior5/5

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

The description discloses a wealth of behavioral nuances beyond what annotations indicate (readOnlyHint=true, openWorldHint=false): page_token fingerprinting, stale-run disclosure, caveats like owned_share_capital_caveat and domestic_cash_flow_caveat, conditions for withheld cash flow, and row_role semantics. It goes far beyond the safety profile and explains exactly how data is presented and qualified.

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 long but deliberately structured with clear section headers (CONSOLIDATED data class, QUALIFICATIONS, WITHHELD CASH FLOW, ROW ROLES). The core purpose is front-loaded in the first sentence, and each subsequent section adds essential operational details rather than filler. Every sentence contributes to correct invocation and interpretation, justifying the length for a tool of this complexity.

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?

With no output schema, the description carries the full burden of explaining the return format and constraints. It covers presentation currency, decimal-string amounts, row roles and summation rules, caveats and their handling, withheld cash flow semantics, and the unavailable status. It also addresses edge cases like foreign members and missing opening basis, making it remarkably complete for an agent to call and interpret correctly.

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?

While the schema covers 100% of parameters, the description adds meaningful semantics: page_token is described as 'signed continuation from the prior page; restart without it if source_changed', periodicity is elaborated with exact grammar (monthly YYYY-MM, quarterly FYyyyy-Qn, annual FYyyyy), and the statement enum's meaning is implied through the consolidated context. This elevates understanding beyond the raw schema.

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 opening sentence clearly states the verb ('Read'), the resource ('sealed group profit-and-loss, balance-sheet, or cash-flow face'), and the scope ('for an exact periodicity and period'). It distinguishes this tool from siblings like get_statement_figures or get_tb_rows by emphasizing 'sealed' and 'consolidated', leaving no ambiguity about which surface it targets.

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?

The description provides clear context for when to use the tool: reading consolidated statements for a sealed run. It also explicitly states exclusions, e.g., 'Consolidated cash-flow is available only for an all-domestic group in v1' and explains when cash flow is withheld. While it doesn't name alternative tools, it gives strong directional guidance on use cases and constraints.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool targets a distinct resource or action — get_* reads, save_* writes, confirm_* approves, preview_* shows consequences before approval. Even the management-data trio (budgets, allocations, variance) is cleanly separated by surface. Two-step flows like preview_chart_rebaseline → confirm_complete_chart are clearly sequenced, so an agent won't confuse the stages.

Naming Consistency5/5

Tool names follow a highly consistent verb_noun pattern: get_* for reads, list_* for discovery, save_* for section writes, confirm_* for approvals, create_* for new entities/centres, preview_* for pre-approval checks. The few one-offs (ingest_upload, upload_trial_balance, set_header_row) still fit the verb-first convention. No camelCase or style mixing.

Tool Count2/5

At 67 tools this is well past the 'too many' threshold. While the Schedule III domain genuinely is broad — statutorily mandated sections, two-phase approval flows, readiness checks, and a separate management-data area — the surface is heavy; an agent will spend real effort just surveying the tool list. Some consolidation of the save_reserves/provisions/assets movements or merging preview+confirm pairs is possible.

Completeness4/5

The surface covers the full lifecycle: upload → mapping/costing → grouping → capture (all statutory sections) → declarations → readiness → generate → finalise → download, plus entity setup and consolidated statements. Minor gaps: no tool directly exposes historical version diffing beyond list_snapshots, and the management-data section (budgets, allocations, variance) feels bolted on rather than integral to the core flow.

Resources