Skip to main content
Glama
iseppo

e-arveldaja MCP Server

by iseppo

Prepare Dividend Distribution

prepare_dividend_package

Preview or create Estonian dividend journal entries, calculating CIT and enforcing ÄS §157 profit and net-asset limits before booking.

Instructions

Calculate dividend CIT (22/78 from 2025-01-01; earlier dates date-gated) and create draft journal entries. Only the NET dividend debits retained earnings (Jaotamata kasum); the CIT books as a current-period income-tax expense (P&L 'Tulumaks' line), never a direct reduction of retained earnings — so the ENTIRE lg 1 distributable profit (retained earnings + closed prior-year result + unclosed prior-year P&L; not the current year) is distributable as net dividend (ÄS § 157 lg 1). Hard-blocks a net dividend exceeding it, or a distribution whose gross effect (net + CIT) would push net assets below share capital + restricted reserves (ÄS § 157 lg 2), unless force=true (never on an imbalanced ledger); pending unconfirmed dividend drafts count. Reports max_net_dividend. One journal per shareholder+date: identical retry → duplicate, different amount → dividend_key_conflict. Requires an approved annual report and a profit-distribution decision — attach the decision to the journal with attach_document. Previews by default (dry_run=true): show the preview and get explicit user approval, then call again with dry_run=false to create the draft journal.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoBook even if the ÄS § 157 lg 1 or lg 2 check fails (only alongside e.g. a capital reduction). Never overrides a ledger-imbalance block. Default false.
dry_runNoPreview calculation, legality checks, and postings without creating a journal (default true). Set false only after the user explicitly approves the previewed journal.
net_dividendYesNet dividend amount to shareholder (EUR)
effective_dateYesDistribution date (YYYY-MM-DD)
tax_payable_accountNoDividend income-tax payable (liability) account (default: auto-detect 'Dividenditulumaksu võlg', standard 2656)
share_capital_accountNoShare capital account for ÄS §157 net-assets check (default: auto-detect 'Osakapital', standard 2900)
shareholder_client_idYesShareholder client ID
dividend_payable_accountNoDividend payable account (default: auto-detect 'Dividendivõlad', standard 2650)
retained_earnings_accountNoRetained earnings account debited with the NET dividend (default: auto-detect 'jaotamata kasum', standard 2960)
income_tax_expense_accountNoIncome-tax expense account debited with the CIT — the P&L 'Tulumaks' line (default: lowest Kulud account in 8900–8999, else 8900)
restricted_reserve_accountsNoAccounts whose balances ÄS §157(2) makes non-distributable (net assets must stay above share capital + these reserves). Default: auto-detect every 'Kohustuslik reservkapital' account (active or inactive) AND always the standard reserve number 2940, so a funded-but-renamed 2940 is never missed; only booked balances raise the floor, so unfunded accounts add nothing. If your chart has REPURPOSED 2940 to a distributable reserve, pass this list explicitly (e.g. [] for no floor, or your real reserve account) to override the 2940 default. Explicit accounts need only exist (inactive OK).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.29.2
    • addedInput schema / additionalProperties
      Added value: +false
  2. Changed3 schema fields changedv0.27.0
    • changedInput schema / properties / dry_run / description
      Previous value: -"Preview calculation and postings without creating journal (default false)"New value: +"Preview calculation, legality checks, and postings without creating a journal (default true). Set false only after the user explicitly approves the previewed journal."
    • changedInput schema / properties / force / description
      Previous value: -"Create journal even if retained earnings are insufficient (default false)"New value: +"Book even if the ÄS § 157 lg 1 or lg 2 check fails (only alongside e.g. a capital reduction). Never overrides a ledger-imbalance block. Default false."
    • changedInput schema / properties / restricted_reserve_accounts / description
      Previous value: -"Accounts whose balances ÄS §157(2) makes non-distributable (net assets must stay above share capital + these reserves). Default: auto-detect every 'Kohustuslik reservkapital' account (active or inactive) AND always the standard reserve number 2940, so a funded-but-renamed 2940 is never missed; only booked balances raise the floor, so unfunded accounts add nothing. If your chart has REPURPOSED 2940 to a distributable reserve, pass this list explicitly (e.g. [] for no floor, or your real reserve account) to override the 2940 default."New value: +"Accounts whose balances ÄS §157(2) makes non-distributable (net assets must stay above share capital + these reserves). Default: auto-detect every 'Kohustuslik reservkapital' account (active or inactive) AND always the standard reserve number 2940, so a funded-but-renamed 2940 is never missed; only booked balances raise the floor, so unfunded accounts add nothing. If your chart has REPURPOSED 2940 to a distributable reserve, pass this list explicitly (e.g. [] for no floor, or your real reserve account) to override the 2940 default. Explicit accounts need only exist (inactive OK)."
  3. Addedv0.25.3
  4. Removedv0.25.2
  5. First observedv0.18.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false), and the description richly adds: what is hard-blocked (lg 1 net-dividend cap, lg 2 net-assets floor), that force never overrides a ledger-imbalance block, that pending unconfirmed drafts count, and the duplicate vs dividend_key_conflict retry semantics. It discloses a lot beyond the annotations. It stops short of describing pagination/return shape, but that's minor for a create tool.

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?

Front-loads the core action before the legal/edge-case detail, which is the right ordering. It is dense and long, but for a legally-constrained, 11-parameter tool most sentences carry real information (legal caps, force semantics, preview flow); a couple could tighten, keeping it from a full 5.

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 an 11-param mutation-ish tool with no output schema, the description is complete: it covers prerequisites, legality checks, idempotency semantics, the dry-run approval loop, and even surfaces the return value (max_net_dividend). Nothing an agent needs to invoke it safely is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the schema documents all 11 parameters itself (baseline 3). The description adds conceptual meaning beyond the field descriptions: why only the NET dividend debits retained earnings, why CIT is an expense, and how the restricted-reserve floor works — useful framing an agent won't get from the schema alone.

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?

States a specific verb+resource ('Calculate dividend CIT ... and create draft journal entries') and the exact accounting output (net dividend debiting retained earnings, CIT as P&L 'Tulumaks'). This clearly distinguishes it from generic siblings like create_journal. An agent knows immediately this is a specialized dividend-package generator, not a generic posting tool.

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?

Explicitly states prerequisites (approved annual report + profit-distribution decision, attach via attach_document) and the required workflow: preview by default, show preview, get explicit user approval, then re-call with dry_run=false. It also names the alternative action (attach_document) and the force-vs-imbalance exclusion, leaving nothing to inference.

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

Deploy Server

Other Tools