Skip to main content
Glama

schedule-iii

Save disclosures

save_disclosures
Destructive

Save the notes/disclosures sections the user provides for the statement. Some of these sections IDENTIFY PEOPLE BY NAME — shareholders, promoters and related parties — so send only what your user has given you, exactly as they gave it. SECTIONS YOU DO NOT SEND ARE LEFT ALONE. Send only the sections you are changing; every other section keeps exactly what is saved. Within a section you DO send, the rows you send REPLACE every row saved for that section — there is no row-level merge, so always send that section complete. To CLEAR a section, send it explicitly with its own empty value: [] for corporateInfo, contingent, shareholders5pct, promoters, relatedParties and msmeAmounts; {} for ratioReasons; null for auditorPayments, csr, proposedDividend and the DSCR amounts. The three ageing sections take [] or null. Clearing removes saved content, so Datavrn saves nothing and returns an approval request naming the sections and how many rows each holds. Show your user exactly what would be cleared; only if they mean to, resend the identical call adding removal_token and removal_count from that response. The approval is single-use and lapses after five minutes — if it lapses, call again for a fresh one. Saving here re-opens the disclosure review — after your last change, confirm the disclosure review again with confirm_capture_review before generating. ratioReasons is keyed by the ratio IDENTIFIER, never its display label: current_ratio | debt_equity | dscr | roe | inv_turnover | tr_turnover | tp_turnover | ncap_turnover | net_profit | roce | roi. msmeAmounts is a POSITIONAL list of exactly five items, in this statutory order: 1. Principal amount and interest due thereon remaining unpaid at the year end (shown separately) | 2. Interest paid under section 16 of the MSMED Act, with the payment made beyond the appointed day | 3. Interest due and payable for delay in payment (paid beyond the appointed day), excluding MSMED-specified interest | 4. Interest accrued and remaining unpaid at the year end | 5. Further interest remaining due and payable in succeeding years (section 23 disallowance) — send all five, using {"currentPaise": null, "previousPaise": null} for an item with nothing to report. Dashes and capitalisation are forgiven when matching a row label (a hyphen for an en dash is fine) and Datavrn stores the prescribed spelling; the wording itself is not forgiven. PRESCRIBED ROWS BY STATEMENT FORMAT — a row label or sub-head that is not one of these is refused rather than stored (a value already saved on this statement stays editable): Division I (Non-Ind AS) ("schedule_iii_div1") — trAgeing: 6 buckets in this order [Not due | < 6 months | 6 months – 1 year | 1 – 2 years | 2 – 3 years | > 3 years], rows [Undisputed — considered good | Undisputed — considered doubtful | Disputed — considered good | Disputed — considered doubtful | Unbilled dues]; tpAgeing: 5 buckets in this order [Not due | < 1 year | 1 – 2 years | 2 – 3 years | > 3 years], rows [MSME | Others | Disputed dues — MSME | Disputed dues — Others | Unbilled dues]; cwipAgeing: 4 buckets in this order [< 1 year | 1 – 2 years | 2 – 3 years | > 3 years], rows [Projects in progress | Projects temporarily suspended]. contingent.subhead ∈ contingent liabilities [Claims against the company not acknowledged as debt | Guarantees | Other money for which the company is contingently liable] or commitments [Estimated amount of contracts remaining to be executed on capital account (net of advances) | Uncalled liability on shares and other investments partly paid | Other commitments] — set group to "contingent" or "commitment" to match, or the row is totalled under contingent liabilities (or leave subhead out and the row prints as its own line under its group). Division II (Ind AS) ("schedule_iii_div2") — trAgeing: 6 buckets in this order [Not due | < 6 months | 6 months – 1 year | 1 – 2 years | 2 – 3 years | > 3 years], rows [Undisputed — considered good | Undisputed — significant increase in credit risk | Undisputed — credit impaired | Disputed — considered good | Disputed — significant increase in credit risk | Disputed — credit impaired | Unbilled dues]; tpAgeing: 5 buckets in this order [Not due | < 1 year | 1 – 2 years | 2 – 3 years | > 3 years], rows [MSME | Others | Disputed dues — MSME | Disputed dues — Others | Unbilled dues]; cwipAgeing: 4 buckets in this order [< 1 year | 1 – 2 years | 2 – 3 years | > 3 years], rows [Projects in progress | Projects temporarily suspended]. contingent.subhead ∈ contingent liabilities [Claims against the company not acknowledged as debt | Guarantees excluding financial guarantees | Other money for which the company is contingently liable] or commitments [Estimated amount of contracts remaining to be executed on capital account (net of advances) | Uncalled liability on shares and other investments partly paid | Other commitments] — set group to "contingent" or "commitment" to match, or the row is totalled under contingent liabilities (or leave subhead out and the row prints as its own line under its group). Non-Corporate Entity ("icai_nce") and LLP ("icai_llp") — no ageing tables at all — trAgeing/tpAgeing/cwipAgeing are refused. contingent.subhead ∈ contingent liabilities [Claims against the entity not acknowledged as debt | Guarantees given on behalf of others | Other money for which the entity is contingently liable] or commitments [Estimated amount of contracts remaining to be executed on capital account (net of advances) | Uncalled liability on investments partly paid | Other commitments] — set group to "contingent" or "commitment" to match, or the row is totalled under contingent liabilities (or leave subhead out and the row prints as its own line under its group).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
payloadYes
client_idYesThe entity (client) id — from list_clients.
period_idYes
template_idYes
removal_countNo
removal_tokenNo

TDQS

A4.4/5.0
Behavior5/5

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

Annotations mark destructiveHint=true, and the description goes far beyond by detailing the exact replace semantics (rows sent replace all saved rows), the clearing behavior with approval flow, and the fact that un-sent sections are left untouched. It even warns that clearing triggers an approval request and that tokens lapse after five minutes, adding substantial behavioral context beyond the annotation.

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?

The description is extremely long and dense, packed with essential rules but presented as a single wall of text without lists or tables. While every sentence adds value, the sheer length and lack of structure hurt readability; the most critical behavior (replace-not-merge) is front-loaded early, but the exhaustive prescribed-rows section could be better organized.

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?

Despite having no output schema, the description covers every aspect an agent needs to call the tool correctly: sections to send, clearing semantics, the removal_token approval flow, prescribed rows per statement format, ratioReasons keying, msmeAmounts ordering, and the subsequent confirm_capture_review step. Nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 17%, so the description carries the full burden of explaining parameters. It specifies how each section is structured, the msmeAmounts positional list of five items, the ratioReasons keyed by identifiers never display labels, and the exact clearing values for each section type—all information not present in the 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 description clearly states it saves the notes/disclosures sections, a specific verb+resource that distinguishes it from other save_* tools like save_accounting_policies. It immediately specifies the scope and the non-merge replace behavior, leaving no ambiguity about what the tool does.

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

Usage Guidelines3/5

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

The description gives detailed instructions on how to use the tool—such as sending only changed sections, using removal_token for clearing, and confirming disclosure review afterward. However, it does not explicitly contrast this tool against alternatives like save_accounting_policies or save_statement_settings, so choosing between siblings is left to inference rather than clearly stated.

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