Skip to main content
Glama
iseppo

e-arveldaja MCP Server

by iseppo

Prepare Dividend Distribution

prepare_dividend_package

Calculate Estonian dividend income tax and preview draft journal entries against legal distribution limits, then create the approved net dividend and tax expense postings.

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. 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)."
  2. Addedv0.25.3
  3. Removedv0.25.2
  4. First observedv0.18.1

TDQS

A4.5/5.0
Behavior5/5

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

Annotations declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the description carries a substantial behavioral burden. It fully discloses the mutation (creates draft journal), the legal hard-block logic, the force override behavior, duplication handling (duplicate vs. keyword conflict), and the dry_run preview mechanism. There is no contradiction with annotations; in fact, the description enriches them with operational detail.

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 lengthy but densely informative. It opens with the core purpose, then layers the legal rules, error cases, prerequisites, and workflow in a logical sequence. While not as concise as a two-liner, every clause carries weight; the semicolon-heavy structure keeps it readable. It could be tightened with bullets, but it is not bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 11 parameters, legal constraints, and a specific workflow, the description is exceptionally thorough. It covers the calculation, journal entries, legal checks, force semantics, conflict handling, prerequisites, and the preview step. The only missing piece is an explicit statement of the return value structure (beyond 'reports max_net_dividend'), which is expected given no output schema. Still, the overall context is robust.

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 baseline is 3. The description adds value beyond the schema by explaining how parameters interact: e.g., net_dividend is the basis for the net-assets check, force overrides legal blocks, and dry_run controls the two-step creation. It also clarifies that restricted_reserve_accounts affects the legal floor. This exceeds the baseline.

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 states a precise verb and resource: 'Calculate dividend CIT and create draft journal entries.' It distinguishes the tool by specifying the exact calculation (22/78 CIT) and the journaling behavior (net dividend debits retained earnings, CIT as income-tax expense). This is clearly differentiated from siblings like create_journal or book_lightyear_distributions by the dividend-specific logic and legal checks.

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

Usage Guidelines4/5

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

The description provides clear context for when to use the tool: requires an approved annual report and profit-distribution decision, and mandates a preview-then-approve workflow via dry_run. It does not explicitly name alternatives or exclusions, but the prerequisites and workflow steps make usage unambiguous. The only gap is no explicit contrast with sibling tools, but the context is sufficient.

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