# com.datavrn/schedule-iii (remote · app.datavrn.com)

Deterministic Schedule III statements for Indian companies: trial balance in, Excel workbook out.

- Trust score: 77/100 (medium)
- Change this week: +5
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-13

## Components

- remote · `app.datavrn.com`: 77/100 (this document), [markdown](https://verifymcp.io/servers/com-datavrn-schedule-iii/api-mcp.md), [page](https://verifymcp.io/servers/com-datavrn-schedule-iii/api-mcp)

## Channel facts

- Endpoint: `https://app.datavrn.com/api/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.0.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-13.

- **Endpoint Security**: 94/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token.
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
  - The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 63/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 12828 tokens (~217/item across 59 items; 59 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 23/100
  - Stability observed for 7 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 88/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 63% of tool parameters carry a description.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http com-datavrn-schedule-iii https://app.datavrn.com/api/mcp
```

### Codex

```toml
[mcp_servers.com-datavrn-schedule-iii]
url = "https://app.datavrn.com/api/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-datavrn-schedule-iii": {
      "type": "remote",
      "url": "https://app.datavrn.com/api/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-datavrn-schedule-iii --url https://app.datavrn.com/api/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  com-datavrn-schedule-iii:
    url: "https://app.datavrn.com/api/mcp"
```

### Other

```json
{
  "mcpServers": {
    "com-datavrn-schedule-iii": {
      "type": "http",
      "url": "https://app.datavrn.com/api/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-13 (score 77, 0)

- [security] Tool “set_header_row” is now declared destructive
- [security] Tool “revoke_capture_declaration” is now declared destructive
- [security] Tool “save_asset_movements” is now declared destructive
- [security] Tool “save_disclosures” is now declared destructive
- [security] Tool “save_py_values” is now declared destructive
- [security] Tool “save_share_capital” is now declared destructive
- [security] Tool “save_statement_settings” is now declared destructive
- [security] Tool “confirm_column_mapping” is now declared destructive
- [security] Tool “finalise_statement” is now declared destructive

### 2026-08-12 (score 77, 0)

- [security] Tool “get_consolidated_statements” rewrote its description, which is the text the model reads

### 2026-08-11 (score 77, +3)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-08-09 (score 74, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-08-07 (score 73, +1)

- [functional improvement] Stability: unverified → 0.03

### 2026-08-06 (score 72)

First indexed and scored.

## MCP tools (59)

### `list_clients` (~40 tokens)

List entities

List the entities (companies) this credential can work with. Call this first to resolve the client_id every other tool needs. Returns each entity id and name.

### `create_client` (~62 tokens)

Create entity

Create a new entity (company) in the organization. Requires a Manager-role key. Use only when the user explicitly asks to set up a new entity; show them the name you will create first.

Input parameters:

- `business_model_code`
- `name` (string, required)

### `upload_trial_balance` (~300 tokens)

Upload trial balance

Stage a Trial Balance spreadsheet (xlsx or csv, max 4 MB) for an entity by INLINING its bytes as base64. This path is ONLY for programmatic callers (a script, Claude Code, an automation) that already have the raw file on disk. If a HUMAN has the file — e.g. they attached it to this chat — do NOT use this tool and do NOT base64-encode the file: call create_upload_link instead and give them the link to upload it in their browser. File size does not change this: even a small attached file goes through create_upload_link — inlining a human-supplied file is unreliable and its bytes routinely truncate. Returns the upload session with detected columns and mapping SUGGESTIONS — nothing is ingested yet. Next: review the suggested column mapping with your user, then call confirm_column_mapping.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `file_base64` (string, required): The file bytes, base64-encoded.
- `file_name` (string, required): The file's name, e.g. 'tb-2026-03.xlsx'.
- `format` (string): Leave unset — the assistant handles Trial Balances only; any other format is refused (use the Datavrn web app).
- `source` (string): Set 'tally_file' when the file is a Tally xlsx export; omit otherwise.

### `get_upload` (~61 tokens)

Get upload status

Read an upload session: status, detected header row and columns, the confirmed mapping (if any), and the stored validation outcome. Use to check what a staged upload still needs.

Input parameters:

- `upload_id` (string, required): The upload session id returned by upload_trial_balance.

### `set_header_row` (~62 tokens)

Set header row

Correct the detected header row of a staged upload (1-based). Only needed when get_upload/upload_trial_balance shows the wrong row was detected.

Input parameters:

- `header_row` (integer, required)
- `upload_id` (string, required): The upload session id returned by upload_trial_balance.

### `confirm_column_mapping` (~102 tokens)

Confirm column mapping

Confirm the column→field mapping for a staged upload and run validation. Returns the full validation result (row counts, warnings, blocking issues). Mapping suggestions are never auto-applied — pass exactly the mapping your user approved. Review any warnings with your user before ingesting.

Input parameters:

- `mapping` (object, required)
- `options` (object)
- `save_as` (string)
- `upload_id` (string, required): The upload session id returned by upload_trial_balance.

### `ingest_upload` (~99 tokens)

Ingest upload into the books

Commit a validated upload into the entity’s books. If validation produced WARNINGS, this refuses until acknowledge_warnings=true — present every warning to your user and obtain their explicit go-ahead first; never acknowledge warnings the user has not seen. Returns the ingestion outcome including any notices.

Input parameters:

- `acknowledge_warnings` (boolean)
- `confirm_merges` (array)
- `upload_id` (string, required): The upload session id returned by upload_trial_balance.

### `list_periods` (~67 tokens)

List reporting periods

List the reporting periods a Schedule III statement can be prepared for (periods with a live Trial Balance). Returns period ids for get_schedule3_workspace, save_py_values, and generate_schedule_iii.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.

### `get_schedule3_workspace` (~138 tokens)

Get Schedule III workspace

THE state tool: grouping progress, every required capture answer, generated/finalised versions, finalisation blockers, and bounded per-version control summaries. Report generation never marks capture complete. Exception output is rule/severity/count only — no account names or amounts. Call this to know what is left before finalising.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `period_id` (string, required): The reporting period id — from list_periods.
- `template_id` (string, required): The statement template id (e.g. 'schedule3_v1' Division I; see list_snapshots/workspace).

### `list_grouping_suggestions` (~343 tokens)

List grouping suggestions

List ungrouped accounts with DETERMINISTIC grouping suggestions (curated rules + name/group-path matching — no AI is involved; Datavrn never applies a suggestion itself). Paginated. Each row carries a reason and a confidence tier: present them to your user GROUPED BY CONFIDENCE, and call out low-confidence and balance-bearing rows for individual attention — a single blanket approval is not a review of the low-confidence tail. Confirm only what your user approves via confirm_groupings. Returns a summary (counts by confidence tier) plus one page of suggestion rows — fetch tier by tier with the confidence filter instead of everything at once; pass include='confirmed' to see already-confirmed groupings.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `confidence` (string): Keep only suggestion rows in this confidence tier ('none' = accounts with no deterministic suggestion). Filters rows only — the summary counts stay over the whole population.
- `has_balance` (boolean): Keep only suggestion rows whose account carries a live balance (true) or not (false).
- `include` (string): Which rows to page: 'suggestions' (default), 'confirmed' (already-grouped accounts), or 'both'.
- `limit` (integer): Page size (default 50, max 200).
- `offset` (integer): Rows to skip (default 0).
- `period_id` (string, required): The reporting period id — from list_periods.
- `template_id` (string, required): The statement template id (e.g. 'schedule3_v1' Division I; see list_snapshots/workspace).

### `confirm_groupings` (~165 tokens)

Confirm account groupings

Persist USER-approved account→line groupings. Omitted accounts stay unchanged. Only explicit leaf_code:null clears a saved grouping. When clearing a saved grouping, use the current grouping_version from list_grouping_suggestions. An actual clear first returns an approval request; nothing changes then. Resend the unchanged request with the approval details to proceed. Clearing an already-unclassified account is an idempotent no-op. Every row must be explicit — there is deliberately no "apply all suggestions" option.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `decisions` (array, required)
- `grouping_version` (integer)
- `removal_count` (integer)
- `removal_token` (string)
- `template_id` (string, required)

### `save_adjustments` (~144 tokens)

Save adjustment entry

Save one balanced adjustment journal entry (debits = credits) as an atomic whole entry. Creating a new entry proceeds immediately. Replacing an existing entry first returns an approval request; nothing changes then. Review the existing entry in the Schedule III workspace, then resend the unchanged request with the approval details to proceed. Amounts are strings in rupees.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `entry_no` (integer, required)
- `lines` (array, required)
- `period_id` (string, required)
- `removal_count` (integer)
- `removal_token` (string)
- `template_id` (string, required)

### `save_py_values` (~133 tokens)

Save prior-year comparatives

Override the prior-year comparative for one or more statement lines with an audited figure. The prior-year column fills itself automatically from the previous year's Trial Balance read through the current groupings, so use this only when the audited financial statements differ from that figure (for example appropriations booked outside the ledger), or when there is no previous-year Trial Balance to derive from — ask your user for the audited figures in those cases.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `period_id` (string, required)
- `template_id` (string, required)
- `values` (array, required)

### `save_asset_movements` (~80 tokens)

Save asset movements

Save fixed-asset movements (additions, deletions, depreciation charge, depreciation on deletions) per gross-block line for the PPE schedule.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `movements` (array, required)
- `period_id` (string, required)
- `template_id` (string, required)

### `save_provision_movements` (~166 tokens)

Save provision movements

Upsert provision movements (additions, amounts utilised) per provision line. Omitted saved lines stay unchanged. To remove selected saved lines, pass remove_leaf_codes; to remove the entire saved set, pass clear_all (never both). An actual removal first returns an approval request; nothing changes then. Review current movements in the Schedule III workspace, then resend the unchanged request with the approval details to proceed.

Input parameters:

- `clear_all` (boolean)
- `client_id` (string, required): The entity (client) id — from list_clients.
- `movements` (array, required)
- `period_id` (string, required)
- `removal_count` (integer)
- `removal_token` (string)
- `remove_leaf_codes` (array)
- `template_id` (string, required)

### `save_reserves_movements` (~173 tokens)

Save reserves movements

Upsert reserves/equity movements (transfers in/out, dividends, other changes) per reserves line. Omitted saved lines stay unchanged. To remove selected saved lines, pass remove_leaf_codes; to remove the entire saved set, pass clear_all (never both). An actual removal first returns an approval request; nothing changes then. Review current movements in the Schedule III workspace, then resend the unchanged request with the approval details to proceed.

Input parameters:

- `clear_all` (boolean)
- `client_id` (string, required): The entity (client) id — from list_clients.
- `movements` (array, required)
- `period_id` (string, required)
- `removal_count` (integer)
- `removal_token` (string)
- `remove_leaf_codes` (array)
- `template_id` (string, required)

### `save_share_capital` (~118 tokens)

Save share capital

Save the share-capital reconciliation for the period: the opening share count, the shares issued and bought back during the year, and the amount issued and the amount bought back.

Input parameters:

- `amount_bought_back` (required)
- `amount_issued` (string, required)
- `client_id` (string, required): The entity (client) id — from list_clients.
- `opening_shares` (required)
- `period_id` (string, required)
- `shares_bought_back` (required)
- `shares_issued` (required)
- `template_id` (string, required)

### `save_statement_settings` (~247 tokens)

Save statement settings

Save statement settings (rounding unit, signatory details, company information used on the statement face).

Input parameters:

- `cin` (required)
- `client_id` (string, required): The entity (client) id — from list_clients.
- `entity_class`
- `entity_name_override` (required)
- `equity_face_value` (required)
- `font_name` (string)
- `include_cfs` (boolean|null)
- `period_id` (string, required)
- `registered_office` (required)
- `rounding_off` (boolean): Whole-rupee value rounding. When true (the default), every figure is rounded to the nearest rupee and the net rounding difference is posted as a computed "Rounding off" line under Other expenses so t…
- `suppress_nil_lines` (boolean)
- `template_id` (string, required)
- `unit_divisor` (number, required)
- `unit_label` (string, required)
- `weighted_equity_shares` (required)
- `weighted_equity_shares_py` (required)
- `weighted_potential_equity_shares` (required)
- `weighted_potential_equity_shares_py` (required)

### `save_disclosures` (~97 tokens)

Save disclosures

Save the notes/disclosures text 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.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `payload` (object, required)
- `period_id` (string, required)
- `template_id` (string, required)

### `declare_capture_na` (~402 tokens)

Record nothing to report, or not applicable

Record that a capture section had NOTHING to report this period, DOES NOT APPLY to this entity, or that this is the entity’s FIRST YEAR (previous-year figures only). These are three different statements and are not interchangeable: "nothing this period" means the section applies but had no activity; "does not apply" means it never applies to this entity at all. This is your user’s professional assertion, recorded as authorised by them — ask which one is true, and never guess. NOT every reason is available for every section — call get_schedule3_workspace and read allowed_reason_codes on the section before you ask your user, so you never put a choice to them that Datavrn will refuse. The restrictions: Settings takes NO answer here at all (it is only answered by saving the settings); share capital and partner capital take only "nothing this period", because those sections are shown only for statement formats they apply to, so "does not apply" can never be true; and "first year" belongs only to previous-year figures. To record a REVIEW being complete (previous-year figures, disclosures) use confirm_capture_review instead; this tool cannot make that assertion. A section can only hold one active answer: to change one, revoke it with revoke_capture_declaration and record a new one — an answer is never edited in place. Generate a fresh version after your last capture change — finalisation checks the version’s frozen capture state, not today’s.

Input parameters:

- `capture_kind` (string, required)
- `client_id` (string, required): The entity (client) id — from list_clients.
- `note` (string)
- `on_behalf_of` (string, required): The email address your user signs in to Datavrn with. This records who authorised the change alongside the connection that made it. Ask them for it — do not guess.
- `period_id` (string, required)
- `reason_code` (string, required)
- `template_id` (string, required)

### `confirm_capture_review` (~334 tokens)

Confirm a section has been reviewed

Record your user’s confirmation that they have REVIEWED a whole section and it is complete — the entire previous-year comparative column, or the entire disclosure set. A review confirmation is your user’s professional assertion, recorded as authorised by them. Before calling this, show them what you are confirming — the whole comparative, or the whole disclosure set — and get their explicit go-ahead. Never confirm a review that has not happened. Saving figures or text does NOT complete these two sections and never has; only this confirmation does. The confirmation is pinned to the exact set that was reviewed, so ANY later save to that section withdraws it — if a confirmation appears not to stick, the next step is to re-review and confirm again, never to retry. Only two sections take a review confirmation: the previous-year comparative and the disclosure set. Every other section is answered by saving its rows, or by declare_capture_na. Datavrn notifies the member you name that this was recorded in their name. Generate a fresh version after your last capture change — finalisation checks the version’s frozen capture state, not today’s.

Input parameters:

- `capture_kind` (string, required)
- `client_id` (string, required): The entity (client) id — from list_clients.
- `note` (string)
- `on_behalf_of` (string, required): The email address your user signs in to Datavrn with. This records who authorised the change alongside the connection that made it. Ask them for it — do not guess.
- `period_id` (string, required)
- `reason_code` (string, required)
- `template_id` (string, required)

### `revoke_capture_declaration` (~234 tokens)

Withdraw a recorded capture answer

Withdraw a recorded capture answer or review confirmation. Statement readiness will show that section as unanswered again. A version you have already generated is NOT affected — if you do not want that version finalised, answer the section again and generate a fresh version. Nothing is deleted: the withdrawn answer stays on the record with who recorded it and who withdrew it, and recording a new answer afterwards creates a new entry rather than overwriting the old one. One thing on this connection is affected immediately: if you already called get_finalise_readiness and hold an approval for that version, withdrawing an answer invalidates it, and the next finalise_statement will refuse and ask you to review the current state again.

Input parameters:

- `capture_kind` (string, required)
- `client_id` (string, required): The entity (client) id — from list_clients.
- `on_behalf_of` (string, required): The email address your user signs in to Datavrn with. This records who authorised the change alongside the connection that made it. Ask them for it — do not guess.
- `period_id` (string, required)
- `template_id` (string, required)

### `copy_capture_declarations` (~205 tokens)

Copy last period’s capture answers

Copy the previous period’s "nothing this period" and "does not apply" answers into this period, for sections that have no answer yet. It NEVER copies a review confirmation — a review is about this period’s content and cannot be inherited. Last period’s answer is not evidence about this period: list what it would copy to your user, section by section, and get their go-ahead before calling it. Answers already recorded for this period are left alone. Generate a fresh version after your last capture change — finalisation checks the version’s frozen capture state, not today’s.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `on_behalf_of` (string, required): The email address your user signs in to Datavrn with. This records who authorised the change alongside the connection that made it. Ask them for it — do not guess.
- `period_id` (string, required)
- `template_id` (string, required)

### `save_partner_capital` (~559 tokens)

Save partner or owner capital schedule

Save the partner or owner capital schedule for an LLP or other non-corporate entity — Note 3a (capital account) or Note 3b (current account), one section per call. Send the COMPLETE schedule for the section you name: anyone you leave out is removed, and a renamed partner reads as one removal plus one addition. If your request would remove anyone, would change the figures of a partner who stays — including their profit-sharing ratio — or would repeat a person’s name that is not already repeated on file, this returns an approval request first and changes NOTHING; tell your user exactly what would change and get their go-ahead before resending with the approval. Two rows with the same person name are both kept: Datavrn never merges them, because two partners may genuinely share a name. A repeated name is therefore saved as a separate row each time it appears, and every one of those rows adds to that person’s balance on the note, so check with your user that there really are that many people before you send a schedule that repeats a name. Adding a partner with a new, different name needs no approval. share_pct is the profit-sharing ratio stated in the LLP or partnership agreement at the reporting date. A ratio that changed part-way through the year cannot be represented here, and a partner who joined or left mid-year cannot be dated — record the position at the reporting date and tell your user the note cannot explain a mid-year change. These figures come from the agreement; Datavrn does not verify them. Datavrn warns about ratios that do not total 100% only when at least TWO capital-account rows carry a ratio, so a partly-filled schedule gets no warning at all — check the total yourself with get_partner_capital. This is your user’s data about named people, recorded as authorised by them. After a successful save, read the section back with get_partner_capital and show your user the new closing balances — this replaces the whole section, and a schedule they cannot see a…

Input parameters:

- `account_kind` (string, required)
- `client_id` (string, required): The entity (client) id — from list_clients.
- `on_behalf_of` (string, required): The email address your user signs in to Datavrn with. This records who authorised the change alongside the connection that made it. Ask them for it — do not guess.
- `period_id` (string, required)
- `removal_count` (integer)
- `removal_token` (string)
- `rows` (array, required)
- `template_id` (string, required)

### `get_partner_capital` (~263 tokens)

Read partner or owner capital schedule

Read the partner or owner capital schedule currently on file — Note 3a and Note 3b. THIS RETURNS PEOPLE’S NAMES, along with each person’s profit-sharing ratio and amounts. Call it before save_partner_capital so you can show your user what is on file and what your change would do — that save replaces the whole section, so a schedule you cannot see is a schedule you cannot safely replace. It also returns the total of the capital-account profit-sharing ratios, because Datavrn warns about a total that is not 100% only when at least two rows carry a ratio.

Input parameters:

- `account_kind` (string): Limit to one section: 'capital' is Note 3a, 'current' is Note 3b. Omit for both.
- `client_id` (string, required): The entity (client) id — from list_clients.
- `limit` (integer): Page size (default 50, max 200).
- `offset` (integer): Rows to skip (default 0).
- `period_id` (string, required): The reporting period id — from list_periods.
- `template_id` (string, required): The statement template id (e.g. 'schedule3_v1' Division I; see list_snapshots/workspace).

### `save_accounting_policies` (~465 tokens)

Save significant accounting policies

Save the Significant Accounting Policies text (Note 2) your user has chosen, one policy per title. SEND THE COMPLETE SET EVERY TIME: this replaces all of Note 2, so any title you leave out of this call is removed — including one someone answered in the Datavrn app. Call list_statement_policy_choices first and send back every title. If your call would drop a saved policy, Datavrn saves nothing and returns an approval request naming how many would be dropped — show your user, and send the approval back only if they mean to drop them. A complete resend drops nothing and saves straight away. Use the exact policy headings this statement format carries; a heading Datavrn does not recognise is refused and nothing is saved. Resolving a bracketed template choice such as "[FIFO / weighted average]" is an ACCOUNTING POLICY DECISION SPECIFIC TO THIS ENTITY: get your user’s explicit choice, and never pick one because it is the common answer. If a policy was set this year and differs from last year’s answer, that is a CHANGE IN ACCOUNTING POLICY requiring disclosure under AS-5 / Ind AS 8 — tell your user before you save it. Check list_statement_policy_choices first: a row that differs from last year while its captured flag is false is NOT a change — last year’s wording has simply not been carried forward, and unless you send it again this note prints Datavrn’s generic template wording in its place. Saving here re-opens the disclosure review — after your last change, confirm the disclosure review again with confirm_capture_review before generating. Recorded as authorised by the member you name. Generate a fresh version after your last capture change — finalisation checks the version’s frozen capture state, not today’s.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `on_behalf_of` (string, required): The email address your user signs in to Datavrn with. This records who authorised the change alongside the connection that made it. Ask them for it — do not guess.
- `period_id` (string, required)
- `policies` (object)
- `removal_count` (integer)
- `removal_token` (string)
- `template_id` (string, required)

### `save_regulatory_affirmations` (~465 tokens)

Save regulatory affirmations

Save the CARO / Other Regulatory Information affirmations your user has confirmed, one per title. SEND THE COMPLETE SET EVERY TIME: this replaces the whole Other Regulatory Information note, so any title you leave out of this call is removed — including one someone answered in the Datavrn app. Call list_statement_policy_choices first and send back every title. If your call would drop a saved affirmation, Datavrn saves nothing and returns an approval request naming how many would be dropped — show your user, and send the approval back only if they mean to drop them. A complete resend drops nothing and saves straight away. Use the exact affirmation headings this statement format carries; a heading Datavrn does not recognise is refused and nothing is saved. Some statement formats — the ICAI formats for LLPs and non-corporate entities — carry no Other Regulatory Information note at all, and this tool refuses for them. Each affirmation is a REGULATORY REPRESENTATION made in the entity’s name — for example whether any proceedings for benami property are pending, or whether the entity has been declared a wilful defaulter. Put each one to your user individually and record their answer. Never affirm one because it is the usual answer, never infer one from a template default, and never confirm a batch of them in one go. If an affirmation differs from last year’s answer, tell your user — call list_statement_policy_choices to see what was answered last year. Saving here re-opens the disclosure review — after your last change, confirm the disclosure review again with confirm_capture_review before generating. Recorded as authorised by the member you name. Generate a fresh version after your last capture change — finalisation checks the version’s frozen capture state, not today’s.

Input parameters:

- `affirmations` (object)
- `client_id` (string, required): The entity (client) id — from list_clients.
- `on_behalf_of` (string, required): The email address your user signs in to Datavrn with. This records who authorised the change alongside the connection that made it. Ask them for it — do not guess.
- `period_id` (string, required)
- `removal_count` (integer)
- `removal_token` (string)
- `template_id` (string, required)

### `list_statement_policy_choices` (~491 tokens)

Review policy and affirmation choices

List every Significant Accounting Policy and Other Regulatory Information affirmation for this statement, with the text that will print, whether a template choice is still unresolved, and what was answered LAST YEAR. This is what makes two rules actionable rather than decorative: never resolve a bracketed choice for your user, and always tell them when an answer differs from last year. CHECK THE ROW’S captured FLAG BEFORE YOU CALL ANYTHING A POLICY CHANGE. differs_from_prior is true in two different situations and only one of them is a change: with captured true the wording was set this year and genuinely differs, which IS a change in accounting policy requiring disclosure under AS-5 / Ind AS 8; with captured false nothing has changed — last year was answered, this year has not been, and the text shown is Datavrn’s generic template wording, which is what will PRINT unless last year’s wording is entered again. Warn your user about that second case explicitly: it silently replaces a policy they wrote. The summary gives you both numbers separately — changed_total (real AS-5 changes) and not_carried_forward_total (answered last year, not yet this year); differs_from_prior_total is simply the two added together. An unresolved choice blocks finalisation, so work through them with your user before generating the version you intend to finalise. "Last year" means the SAME MONTH ONE YEAR EARLIER — the same comparative period the statement itself reports — not the period immediately before this one. The summary names it: prior_period_label is the year that was compared against, and prior_period_found tells you whether Datavrn holds that year at all. A blank last-year answer means nothing was recorded for that year — when prior_period_found is false it means Datavrn has no such reporting period, so there is nothing to compare. Either way it does NOT mean last year matched this year; say which of the two it is.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `limit` (integer): Page size (default 50, max 200).
- `offset` (integer): Rows to skip (default 0).
- `period_id` (string, required): The reporting period id — from list_periods.
- `template_id` (string, required): The statement template id (e.g. 'schedule3_v1' Division I; see list_snapshots/workspace).

### `get_finalise_readiness` (~363 tokens)

Check finalisation state and get approval

Read the full finalisation state of one statement version, and get the approval finalise_statement needs. Call it ONCE immediately before finalising — it re-reads the stored workbook, so do not poll it. SHOW YOUR USER EVERY ROW THIS RETURNS — the gates that must be green, each warning they would be accepting and why, how many input cells are still empty, any control that could not be evaluated, and capture_live_diverged_message when it is present — before you finalise. Do not summarise the warnings away. capture_live_diverged_message means a capture answer changed after this version was generated: the version can still be sealed as it stands, and generating a fresh one is the alternative. Read it out and let your user choose. A control that "could not be evaluated" is not a pass: it is a check Datavrn did not run, and your user is entitled to know what was not checked before they seal the version. The approval is single-use, expires in 15 minutes, and is tied to this exact version, this connection and the member you name — if anything about the statement changes in between, finalise_statement will refuse and you start again from here. If your connection is not permitted to finalise, you still get the whole state; there is simply no approval to hand back.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `on_behalf_of` (string, required): The email address your user signs in to Datavrn with. This records who authorised the change alongside the connection that made it. Ask them for it — do not guess.
- `snapshot_id` (string, required): The statement version id — from list_snapshots or get_schedule3_workspace.

### `finalise_statement` (~378 tokens)

Seal the permanent client copy of a version

Seal a statement version as Datavrn’s permanent client copy, recorded as authorised by the member you name. THIS IS NOT APPROVAL OR ADOPTION OF THE FINANCIAL STATEMENTS AND IT IS NOT A SIGNATURE. It does not discharge section 134(1) for a company or section 34(3) for an LLP. THERE IS NO UNDO. A change afterwards means generating a new version and finalising that one; the version you seal here stays sealed. Call get_finalise_readiness first, show your user every gate and every warning it returns, get their explicit go-ahead, and only then send the confirm_token it gave you together with the acknowledgements. Never acknowledge a warning your user has not seen, and never write the acceptance reason yourself — it is their professional judgment in their own words. Datavrn will refuse if anything about the statement changed after you read the state, and nothing will be finalised. If the response comes back with reused set to true, a finalisation of this same version was already under way: nothing new was done and your approval was not used. Do not call finalise_statement again — the status field says where that finalisation is (queued, running, or paused, which means it hit a temporary problem and Datavrn will retry it on its own). Poll get_job with the job_id and tell your user what it says.

Input parameters:

- `acknowledgments` (object, required)
- `client_id` (string, required): The entity (client) id — from list_clients.
- `confirm_token` (string, required)
- `on_behalf_of` (string, required): The email address your user signs in to Datavrn with. This records who authorised the change alongside the connection that made it. Ask them for it — do not guess.
- `snapshot_id` (string, required)

### `generate_schedule_iii` (~246 tokens)

Generate Schedule III statements

Queue the Schedule III workbook build (returns a job_id to poll with get_job — the build runs as a background job). REFUSES when ungrouped accounts exist unless acknowledged: before acknowledging, present the ungrouped accounts to your user and obtain their explicit go-ahead; record it in acknowledge_reason and pass the exact count in acknowledge_count — an acknowledgement WITHOUT its count is always re-demanded. A multi-month statement period additionally requires acknowledge_multi_month_pnl WITH acknowledge_month_count (confirm with your user that the TBs are period movements, not cumulative). Never acknowledge anything the user has not seen. Once queued, the build usually completes in a few minutes — tell your user their statements are being prepared and poll get_job periodically; do not present the wait as a problem.

Input parameters:

- `acknowledge_count` (integer)
- `acknowledge_month_count` (integer)
- `acknowledge_multi_month_pnl` (boolean)
- `acknowledge_reason` (string)
- `acknowledge_unclassified` (boolean)
- `client_id` (string, required): The entity (client) id — from list_clients.
- `period_id` (string, required)
- `template_id` (string, required)

### `get_job` (~148 tokens)

Get job status

Poll a background job by id until status is succeeded or failed. A failed job carries its user-safe error reason — show it to your user. Jobs run on a background worker that claims queued work on a schedule, so a job sitting at "queued" (0 attempts) for the first few minutes is NORMAL, not a fault — keep polling every ~30–60s and reassure the user it is being prepared; do NOT report this as an error or a Datavrn bug. Only if it is still "queued" well past a few minutes should you tell the user it is taking longer than usual.

Input parameters:

- `job_id` (string, required): The job id returned by generate_schedule_iii.

### `list_snapshots` (~70 tokens)

List statement versions

List the frozen Schedule III workbook versions for an entity (newest first), including each version’s period, template, and unclassified count at build time.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `template_id` (string): Filter to one template.

### `get_workbook_download` (~92 tokens)

Download workbook

Mint a short-lived signed URL for a frozen workbook version (the Excel file). Give the URL to your user to open in a browser — it needs no login and expires in about 10 minutes. The bytes are immutable and integrity-hashed.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `snapshot_id` (string, required): The snapshot id from list_snapshots.

### `create_upload_link` (~200 tokens)

Create upload link

Mint a single-use, login-free upload link so YOUR USER can give Datavrn a file directly from their browser — the file never passes through you, so it cannot truncate or corrupt. Use this whenever a human has the file (a trial balance export, etc.). The link stages the file for ONE entity and expires in about 15 minutes; nothing is ingested until the column mapping is confirmed.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `file_name` (string, required): The file the user is expected to upload, e.g. 'tb-2026-03.xlsx' (shown on the upload page).
- `format` (string): Leave unset — the assistant handles Trial Balances only; any other format is refused (use the Datavrn web app).
- `source` (string): Set 'tally_file' when the file is a Tally xlsx export; omit otherwise.

### `get_upload_link_status` (~76 tokens)

Get upload link status

Check an upload link's state: pending (the user has not uploaded yet), uploaded (returns the upload_id — continue with get_upload), or expired (mint a fresh link with create_upload_link). Poll after the user says they uploaded the file.

Input parameters:

- `link_id` (string, required): The link id returned by create_upload_link.

### `get_statement_figures` (~303 tokens)

Read statement figures

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. Figures are Datavrn's deterministic engine output; interpretation is your assistant's.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `period_id` (string, required): The reporting period id — from list_periods.
- `template_id` (string, required): The statement template id (e.g. 'schedule3_v1' Division I; see list_snapshots/workspace).
- `version` (integer): A specific statement version; omit for the latest.

### `get_statement_notes` (~419 tokens)

Read statement notes

Read the line-by-line breakdown of a generated statement's notes — every line's current and prior-year amount, and the note total. Pass note_numbers (from get_statement_figures' note_index) to fetch specific notes, or omit for all. Use this to answer "what's in Other Expenses?" or "what makes up trade receivables?". Each line has a kind: 'component' (an additive line), 'subtotal' (a presentational group subtotal — do NOT add it into the total, or you double-count), or 'header'. Fixed-asset / intangible notes carry a `block` per class with gross_block, accumulated depreciation, and net (the additions/deletions movement schedule itself lives in the workbook). If the full set is too large it returns too_large:true with a note_index — fetch note_numbers in small batches. A single very large note (e.g. a PPE schedule or an ageing note) is returned in explicitly-flagged line pages: each page carries the authoritative note total, lines_page, lines_total, and has_more_lines — keep fetching lines_page until has_more_lines is false; never treat one page's lines as the whole note. Amounts are decimal strings in rupees. Figures are Datavrn's deterministic engine output; interpretation is your assistant's.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `lines_page` (integer): For a single very large note returned in line pages: the 1-based line page to fetch (fetch exactly one note; keep going until has_more_lines is false).
- `note_numbers` (array): Specific note numbers to fetch (from note_index); omit for all notes.
- `period_id` (string, required): The reporting period id — from list_periods.
- `template_id` (string, required): The statement template id (e.g. 'schedule3_v1' Division I; see list_snapshots/workspace).
- `version` (integer): A specific statement version; omit for the latest.

### `get_tb_rows` (~395 tokens)

Read trial-balance source data

Read the SOURCE DATA behind a statement: the trial-balance rows (account name, debit, credit) as landed for a period, BEFORE grouping — the pre-statement numbers, not statement figures. PREFER FILTERS over fetching everything: name_patterns (e.g. ['cash','bank','od']), side ('debit'/'credit' by net balance), and min_abs_balance return a small exact subset with its own debit/credit totals — e.g. wrong-side cash accounts = name_patterns ['cash','bank'] + side 'credit'. Paginated (page 1-based; page_size default 50, max 500). These are the CURRENT live rows: statement figures are frozen at a generated version, so if the trial balance was re-uploaded after a version was generated, these rows may not tie to that version (the response `note` says so). Amounts are decimal strings in rupees. Figures are Datavrn's deterministic engine output; interpretation is your assistant's.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `min_abs_balance` (string): Keep only accounts whose balance (the larger of its debit/credit) is at least this many rupees — a decimal string like '100000'.
- `name_patterns` (array): Up to 10 case-insensitive substrings; an account matches if its name contains ANY of them (e.g. ['gst','tds']).
- `page` (integer): 1-based page number (default 1).
- `page_size` (integer): Rows per page (default 50, max 500 — prefer filters over big pages).
- `period_id` (string, required): The reporting period id — from list_periods.
- `side` (string): Keep only accounts whose net balance falls on this side (debit = debits exceed credits). Accounts netting to zero match neither.

### `get_pending_work` (~165 tokens)

List pending work across entities

Answer "what's left to do?" across every entity you can see — one row per entity, with what is blocking its Schedule III statement: whether the trial balance is in, how many accounts are still ungrouped, the latest generated version, and whether it has been finalised. Pass period_label to pick a period, or omit to default to the period most of your entities have a trial balance for (not necessarily the newest — one entity uploading a future period early will not flip the board). Rows include deep links that open the Datavrn web app (a login is needed there).

Input parameters:

- `period_label` (string): Reporting period label, e.g. '2026-03'; omit to default to the period most of your entities have a trial balance for.

### `list_allocation_runs` (~216 tokens)

List allocation runs

MANAGEMENT data class. Discover persisted allocation runs and their conservation heads; this does not generate or recompute allocation. Money is decimal-string rupees. Results are ordered period, version, then run id, and the signed page_token is pinned to the complete filtered source: if it reports source_changed, restart at page 1. current_only means latest generated version, not source freshness; known_stale and not_assessed are both warnings, never a claim that the source is fresh. Raw stale reasons and warning context are not returned.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `current_only` (boolean): Return only the latest generated version per period (default true); this is not a freshness claim.
- `page_size` (integer): Rows per source-pinned page (default 20, max 50).
- `page_token` (string): Signed continuation from the prior page; restart without it if source_changed.
- `period` (string): Optional management month in YYYY-MM.

### `get_allocation_account_figures` (~236 tokens)

Read allocation account figures

MANAGEMENT data class. Read the current persisted allocation run at account grain: books figure plus spreading adjustment equals MIS figure, all as decimal-string rupees. Filter account names or minimum absolute MIS amount before paging. The summary covers the full filtered set and ties the spreading reconciliation; no target-level split or source transactions are returned. The signed page_token is source-pinned, so restart at page 1 if source_changed. known_stale and not_assessed disclose run state; neither means fresh.

Input parameters:

- `account_name_patterns` (array): Up to 10 case-insensitive account-name substrings; any match is retained.
- `client_id` (string, required): The entity (client) id — from list_clients.
- `min_abs_mis` (string): Minimum absolute MIS figure in rupees as a decimal string, e.g. '100000'.
- `page_size` (integer): Rows per source-pinned page (default 50, max 200).
- `page_token` (string): Signed continuation from the prior page; restart without it if source_changed.
- `period` (string, required): Management month in YYYY-MM.

### `get_allocation_target_figures` (~274 tokens)

Read allocation target figures

MANAGEMENT data class. Read the current persisted allocation run at account × target × source × mode grain, with decimal-string allocated amounts. For step-down, filter allocation_sources=['step_down']; for profit centres, filter target_types=['profit_centre','sub_profit_centre']. Use filters before paging; the signed page_token is source-pinned, so restart at page 1 if source_changed. Target labels are cost-centre names as of the run and current profit-centre names; no owners, descriptions, source transactions, or recomputation are returned.

Input parameters:

- `account_name_patterns` (array): Up to 10 case-insensitive account-name substrings; any match is retained.
- `allocation_sources` (array): Restrict to allocation sources.
- `client_id` (string, required): The entity (client) id — from list_clients.
- `min_abs_amount` (string): Minimum absolute allocated amount in rupees as a decimal string, e.g. '100000'.
- `page_size` (integer): Rows per source-pinned page (default 50, max 200).
- `page_token` (string): Signed continuation from the prior page; restart without it if source_changed.
- `period` (string, required): Management month in YYYY-MM.
- `target_types` (array): Restrict to allocation target types.

### `get_spreading_reconciliation` (~255 tokens)

Read spreading reconciliation

MANAGEMENT data class. Read the persisted books-to-MIS spreading reconciliation, not a new allocation run. Accounts view gives account-grain books plus adjustments equals MIS; adjustments view requires one account and pages its rule adjustments. Money is decimal-string rupees. Whole-run summary figures never change with account filters. The signed page_token is source-pinned, so restart at page 1 if source_changed. Raw warning context is withheld; known_stale and not_assessed are disclosure states, not freshness claims.

Input parameters:

- `account_id` (string): Required for adjustments view; an account in this entity and run.
- `account_name_patterns` (array): Up to 10 case-insensitive account-name substrings; any match is retained.
- `client_id` (string, required): The entity (client) id — from list_clients.
- `page_size` (integer): Rows per source-pinned page: accounts default 25/max 100; adjustments default 50/max 200.
- `page_token` (string): Signed continuation from the prior page; restart without it if source_changed.
- `period` (string, required): Management month in YYYY-MM.
- `view` (string): accounts (default) or adjustments; adjustments requires account_id.

### `list_budgets` (~182 tokens)

List budgets

MANAGEMENT data class. Discover budget ids and versions without identity fields. Locked FX rate and all money-valued fields are decimal strings. Filter status or fiscal-year start before paging. The signed page_token is pinned to the complete filtered source; restart at page 1 if source_changed. This lists budget headers only, not cells, approvals identities, or a recalculated budget.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `fiscal_year_start` (string): Optional fiscal-year first-of-month date, e.g. 2026-04-01.
- `page_size` (integer): Rows per source-pinned page (default 20, max 50).
- `page_token` (string): Signed continuation from the prior page; restart without it if source_changed.
- `status` (string): Optional budget status.

### `get_budget` (~258 tokens)

Read budget

MANAGEMENT data class. Read one versioned budget: identity-free header, its pinned P&L tree, and filtered/paginated cells with entered-versus-inferred truth. Amounts and locked FX rate are decimal strings. Filter months, lines, centres, or inference before paging; the signed page_token is source-pinned, so restart at page 1 if source_changed. Cells across different P&L lines are not one meaningful grand total, so no cross-line grand total is exposed. No people, ownership, editability, or approval identities are returned.

Input parameters:

- `budget_id` (string, required): Budget id from list_budgets.
- `client_id` (string, required): The entity (client) id — from list_clients.
- `cost_centre_ids` (array): Up to 25 cost-centre ids.
- `inference` (string): Cell inference state (default all).
- `line_codes` (array): Up to 25 P&L line codes.
- `month` (string): Optional budget month in YYYY-MM.
- `page_size` (integer): Cells per source-pinned page (default 100, max 200).
- `page_token` (string): Signed continuation from the prior page; restart without it if source_changed.

### `get_variance_report` (~252 tokens)

Read variance report

MANAGEMENT data class. Read the existing budget-or-prior variance report for a month; it never recalculates it. Amounts are decimal strings; a null actual or variance means unavailable, never zero. Rows view has whole-report unfiltered rollups and no cross-side grand total; filters affect only rows and filtered grain counts. Explanations view withholds internal notes and may redact structured PII. Filter lines or centres before paging; the signed page_token is source-pinned, so restart at page 1 if source_changed.

Input parameters:

- `basis` (string): Comparator basis (default budget).
- `client_id` (string, required): The entity (client) id — from list_clients.
- `cost_centre_ids` (array): Up to 25 cost-centre ids.
- `line_codes` (array): Up to 25 P&L line codes.
- `page_size` (integer): Rows per source-pinned page (default 50, max 100).
- `page_token` (string): Signed continuation from the prior page; restart without it if source_changed.
- `period` (string, required): Management month in YYYY-MM.
- `view` (string): Report rows (default) or safe explanations.

### `get_consolidated_statements` (~475 tokens)

Read sealed consolidated statements

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. 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.

Input parameters:

- `group` (string, required): An active group UUID or its exact case-insensitive display name.
- `page_size` (integer): Rows per source-pinned page (default 50, max 100).
- `page_token` (string): Signed continuation from the prior page; restart without it if source_changed.
- `period` (string, required): The period matching periodicity.
- `periodicity` (string, required): Period grammar: monthly YYYY-MM, quarterly FYyyyy-Qn, annual FYyyyy.
- `statement` (string): Statement face (default pnl).

### `list_cost_centres` (~122 tokens)

List cost centres

List the cost centres for an entity. Use this before proposing account mappings so you can group the proposal by target name and distinguish operating from support centres. This is status-only: it returns names and kinds, never rupee amounts. Tell the user what the existing structure means before suggesting a change.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `page` (integer): 1-based page number (default 1).
- `page_size` (integer): Rows per page (default 100, max 200).

### `create_cost_centre` (~190 tokens)

Create a cost centre

Create one cost centre for an entity after showing the user the exact name, kind, parent, effective date, and reason. This is one explicit centre at a time; there is no apply-all shortcut. After creating it, call list_cost_centres again and explain which mapping suggestions can now use it.

Input parameters:

- `centre_kind` (string): Operating or shared-support centre; defaults to operating.
- `client_id` (string, required): The entity (client) id — from list_clients.
- `code`: Optional short code.
- `description`: Optional plain-language description.
- `effective_from` (string): Date from which this centre applies; defaults to the start of the entity data.
- `name` (string, required): The cost-centre name to create.
- `parent_cost_centre_id`: Optional existing parent cost-centre id.
- `reason` (string, required): Why the user asked for this centre.

### `list_profit_centres` (~101 tokens)

List profit centres

List the profit centres for an entity. Use this to explain available targets before a user confirms any explicit mapping. This is status-only: it returns names and hierarchy, never rupee amounts.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `page` (integer): 1-based page number (default 1).
- `page_size` (integer): Rows per page (default 100, max 200).

### `create_profit_centre` (~123 tokens)

Create a profit centre

Create one profit centre for an entity after showing the user the exact name, optional parent, and description. This is one explicit centre at a time; there is no apply-all shortcut. Re-list the centres after creation so the user can see the new target before any mapping confirmation.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `description`: Optional plain-language description.
- `name` (string, required): The profit-centre name to create.
- `parent_profit_centre_id`: Optional existing parent profit-centre id.

### `list_account_mappings` (~230 tokens)

Review account mappings

Review account-to-cost-centre mapping status and deterministic suggestions for an entity. This is status-only: it returns account names, types, target names, confidence, reasons, and balance-bearing booleans, but never debit, credit, balance, or any rupee amount. Always present the rows grouped by confidence tier and target, state exact counts, flag every medium/low-confidence row, and show the two distinct completion counts: unmapped_total and unmapped_with_balance. Do not call either count pending.

Input parameters:

- `balance_bearing_only` (boolean): Return only accounts that carry a balance, without returning the balance itself.
- `client_id` (string, required): The entity (client) id — from list_clients.
- `name_patterns` (array): Return accounts whose code or name contains at least one of these case-insensitive patterns.
- `page` (integer): 1-based page number (default 1).
- `page_size` (integer): Rows per page (default 100, max 200).
- `unmapped_only` (boolean): Return only accounts that still need a centre mapping.

### `confirm_centre_mappings` (~206 tokens)

Confirm cost-centre mappings

Persist only the explicit account-to-centre decisions the user approved. Before calling, show the proposal grouped by confidence tier and target with exact counts, call out every medium/low-confidence row, and get a clear approval for the enumerated items. Omitted accounts stay unchanged; there is no apply-all, auto-confirm, or use-suggestions flag. After the write, report confirmed, unmapped_total, and unmapped_with_balance so the user knows exactly what remains. This tool never returns rupee amounts.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `effective_from` (string, required): The effective date shown to the user.
- `items` (array, required): Every account decision explicitly approved by the user; never a blanket flag.
- `removal_count` (integer): The exact removal count returned by the removal preview.
- `removal_token` (string): Only include the short-lived token returned by the removal preview for this exact proposal.

### `list_reporting_lines` (~201 tokens)

Review reporting-line mappings

Review reporting-line classification status and deterministic suggestions for an entity and reporting period. This is status-only: it returns names, line labels, confidence, reasons, and balance-bearing booleans, but never debit, credit, balance, or any rupee amount. Present suggestions grouped by confidence tier and target, with exact counts and both unmapped_total and unmapped_with_balance; do not call either count pending.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `name_patterns` (array): Return accounts whose code or name contains at least one of these case-insensitive patterns.
- `page` (integer): 1-based page number (default 1).
- `page_size` (integer): Rows per page (default 100, max 200).
- `period_id` (string, required): The reporting period id from list_periods.
- `unmapped_only` (boolean): Return only accounts without a confirmed reporting line.

### `confirm_reporting_lines` (~189 tokens)

Confirm reporting-line mappings

Persist only the explicit reporting-line decisions the user approved. Before calling, show the proposal grouped by confidence tier and target with exact counts, flag every medium/low-confidence row, and get clear approval for the enumerated decisions. Omitted accounts stay unchanged. Sending leaf_code:null permanently removes that account saved reporting line; send it only when the user explicitly asked to clear that row. There is no apply-all or auto-confirm flag. The response tells you how many were confirmed, cleared, and whether the balance-bearing set is fully mapped; never claim completion without checking those fields.

Input parameters:

- `client_id` (string, required): The entity (client) id — from list_clients.
- `decisions` (array, required)
- `removal_count` (integer): The exact removal count returned by the removal preview.
- `removal_token` (string): Only include the short-lived token returned by the removal preview for this exact proposal.

### `get_setup_status` (~297 tokens)

Show setup status and the next step

Answer "how do I get started?", "what do I do next?", or help a user who seems lost setting up. Returns where they are in the journey from an empty organization to a finished Schedule III statement, and the ONE next step to take. Call it WITHOUT client_id first (the organization view): it lists the entities this credential can see, or — if there are none — the step to create the first one. Then call it again WITH one entity’s client_id for that entity’s full step-by-step path (upload trial balance → confirm groupings → capture figures → generate → download). Each step has a status (done / next / todo / blocked / web_only) and either the exact tool to call or a web-app link. NARRATE ONE STEP AT A TIME — walk the user through the single `next` step; do not dump the whole list unprompted. Steps marked web_only are done in the Datavrn web app and need a login — never claim you can do them yourself. This tool reports STATUS only (counts, names, what is done) — it never returns a figure or balance; read those with get_statement_figures once a statement is generated.

Input parameters:

- `client_id` (string): An entity id (from list_clients or the organization view) for that entity’s full path; omit for the organization-level overview and, on an empty org, the create-entity step.

### `verify_connection` (~79 tokens)

Verify connection

Confirm the Datavrn connection is working and report what it can do. Call this first — or whenever the user asks whether Datavrn is connected — to get back the organization, the access profile (what this connection may see and do), and the next step. Running it successfully also marks the connection healthy in the user’s Datavrn settings.

### `get_help` (~72 tokens)

Get the agent guide

Get the Datavrn agent guide: how connecting works (OAuth and API key), what an assistant can do, how reading a statement as data works, and the guarantees and limits — plus the current list of tools. Call this to answer a user's questions about how Datavrn works from canonical documentation instead of guessing.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-datavrn-schedule-iii/api-mcp#diagnostics

## Score history

- 2026-08-13: 77
- 2026-08-12: 77
- 2026-08-11: 77
- 2026-08-10: 74
- 2026-08-09: 74
- 2026-08-08: 73
- 2026-08-07: 73
- 2026-08-06: 72

## Links

- Remote endpoint: https://app.datavrn.com/api/mcp
- Website: https://app.datavrn.com/agents
- Changelog RSS feed: https://verifymcp.io/servers/com-datavrn-schedule-iii/api-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-datavrn-schedule-iii/api-mcp.json
- HTML version of this page: https://verifymcp.io/servers/com-datavrn-schedule-iii/api-mcp