Skip to main content
Glama

schedule-iii

by com.datavrn

Read statement figures

get_statement_figures
Read-only

Read a generated Schedule III statement's figures: the balance-sheet and profit-and-loss faces, current-year and previous-year balance-sheet tie verdicts separately (a null verdict means UNKNOWN, never a pass: either no comparative was captured, or the version predates per-column balance recording), the unclassified count, and the notes listed by number. Also returns bounded exception counts by rule/severity and the frozen control changes versus the immediately previous recorded version; it never recomputes either from live books. Figures come from a generated version (the latest unless you pass a specific version) and match the workbook exactly. If the version was generated before figure reads existed it returns available:false with reason "figures_not_available" and only the legacy flat tie verdict; tell the user to generate the statement again, read the latest version, then retry. For a note's line-by-line breakdown, use its note_index entry with get_statement_notes. Amounts are decimal strings in rupees. ONE EXCEPTION: the profit-and-loss face ends with the statutory earnings-per-share rows, marked kind:"eps". Their figures are ₹ PER SHARE, not rupees of profit — report them as EPS and never add them into a face total. They are null until the weighted average share counts are saved in statement settings. Figures are Datavrn's deterministic engine output; interpretation is your assistant's.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
versionNoA specific statement version; omit for the latest.
client_idYesThe entity (client) id — from list_clients.
period_idYesThe reporting period id — from list_periods.
template_idYesThe statement template id (e.g. 'schedule3_v1' Division I; see list_snapshots/workspace).

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses extensive behaviors: null verdicts mean UNKNOWN not pass, old versions return available:false with a specific reason, it never recomputes from live books, figures match the workbook, amounts are decimal strings, and the EPS rows are per share and excluded from totals. This far exceeds what annotations provide.

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 densely packed with necessary information, organized into clear sentences and paragraphs. It front-loads the primary purpose and then covers edge cases and exceptions. While longer than average, every sentence earns its place—for instance, the EPS rule and null-verdict semantics are critical for correct usage. Not excessively verbose.

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?

Given the tool's 4 parameters, no output schema, and no enums, the description fully equips an agent: it details all return categories, handles versioning edge cases, explains the EPS exception, and provides recovery instructions for unavailable figures. The inclusion of 'frozen control changes' and 'never recomputes' clarifies non-obvious behavior. Nothing essential 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 description coverage is 100% as all 4 parameters have descriptions. The tool description adds no additional parameter-level detail beyond what the schema already states (e.g., version meaning latest unless specified is already in the schema). Baseline 3 applies because the schema does the heavy lifting; no compensation needed.

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 description precisely states the tool reads a generated Schedule III statement's figures, enumerating the exact elements (balance-sheet and P&L faces, tie verdicts, unclassified count, notes, exception counts, control changes). It distinguishes itself from sibling get_statement_notes by explicitly routing line-by-line breakdowns to that tool. The verb 'read' and resource 'statement figures' are unambiguous.

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?

Clearly states when to use this tool versus the alternative: 'For a note's line-by-line breakdown, use its note_index entry with get_statement_notes.' It also provides recovery guidance for old versions (regenerate, read latest, retry) and clarifies that interpretation is the assistant's responsibility. No exclusions are missing.

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

All schedule-iii toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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