Skip to main content
Glama
iseppo

e-arveldaja MCP Server

by iseppo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Book Lightyear Distributions

book_lightyear_distributions
Destructive

Create journal entries for Lightyear dividend, interest, and reward distributions, including withheld tax. Preview with dry run before posting.

Instructions

Create journal entries for Lightyear dividend, interest, and reward distributions, including withheld tax. DRY RUN by default.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dry_runNoPreview without creating entries (default true)
file_refNoOpaque Lightyear AccountStatement file reference.
file_pathNoAccountStatement path/base64 input. Provide exactly one of file_path or file_ref.
fee_accountNoPlatform fee expense account (default 8610 Muud finantskulud)
plan_handleNoExecution-plan handle from the reviewed dry run. Required for dry_run=false.
tax_accountNoWithheld tax receivable/expense account (for tax_amount from CSV)
broker_accountYesBroker cash account (e.g. 1120 Lightyear konto)
income_accountYesIncome account for Dividend rows (dividends from directly-held shares → 8330 'Tulu aktsiatelt ja osadelt'). Fund Distribution rows use fund_distribution_account and Interest rows use interest_account.
reward_accountNoAccount for platform rewards/bonuses (default: auto-detect 'Muud finantstulud', standard 8600). Rewards are broker fee/campaign income, not securities income.
interest_accountNoAccount for Interest rows (default: auto-detect 'Intressitulu hoiustelt', standard 8400).
broker_dimension_idNoDimension ID for broker account (accounts_dimensions_id)
fund_distribution_accountNoAccount for fund Distribution rows (default: auto-detect 'Tulu fondiosakute ümberhindlusest', standard 8320).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.27.0
    • addedInput schema / properties / fund_distribution_account
      Added value: +{
+  "description": "Account for fund Distribution rows (default: auto-detect 'Tulu fondiosakute ümberhindlusest', standard 8320).",
+  "type": "number"
+}
    • changedInput schema / properties / income_account / description
      Previous value: -"Investment income account for the distribution. Dividends from directly-held shares → 8330 'Tulu aktsiatelt ja osadelt'; fund distributions → 8320; interest → 8400."New value: +"Income account for Dividend rows (dividends from directly-held shares → 8330 'Tulu aktsiatelt ja osadelt'). Fund Distribution rows use fund_distribution_account and Interest rows use interest_account."
    • addedInput schema / properties / interest_account
      Added value: +{
+  "description": "Account for Interest rows (default: auto-detect 'Intressitulu hoiustelt', standard 8400).",
+  "type": "number"
+}
  2. Changed6 schema fields changedv0.25.2
    • changedInput schema / properties / file_path / description
      Previous value: -"Absolute path to Lightyear AccountStatement CSV file."New value: +"AccountStatement path/base64 input. Provide exactly one of file_path or file_ref."
    • addedInput schema / properties / file_ref
      Added value: +{
+  "description": "Opaque Lightyear AccountStatement file reference.",
+  "type": "string"
+}
    • changedInput schema / properties / income_account / description
      Previous value: -"Investment income account (e.g. 8320 Tulu fondiosakutelt, 8400 Intressitulu)"New value: +"Investment income account for the distribution. Dividends from directly-held shares → 8330 'Tulu aktsiatelt ja osadelt'; fund distributions → 8320; interest → 8400."
    • addedInput schema / properties / plan_handle
      Added value: +{
+  "description": "Execution-plan handle from the reviewed dry run. Required for dry_run=false.",
+  "type": "string"
+}
    • changedInput schema / properties / reward_account / description
      Previous value: -"Account for platform rewards (default: 3800 Muud äritulud). Rewards are non-investment income."New value: +"Account for platform rewards/bonuses (default: auto-detect 'Muud finantstulud', standard 8600). Rewards are broker fee/campaign income, not securities income."
    • changedInput schema / required
      Previous value: -[
-  "file_path",
-  "broker_account",
-  "income_account"
-]New value: +[
+  "broker_account",
+  "income_account"
+]
  3. First observedv0.18.1

TDQS

A3.7/5.0
Behavior4/5

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

The annotations declare destructiveHint=true, so the agent knows this is a mutation. The description adds valuable context beyond annotations by stating 'DRY RUN by default,' which is a critical safety behavior not covered by the annotations. It also correctly aligns with the destructive nature (creating journal entries). However, it does not disclose other behavioral details like idempotency or the need for a plan_handle for final execution, but those are partially covered by the schema. Given the annotations, the description adds solid behavioral value without contradiction.

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 concise and front-loaded with the core purpose in the first sentence. The second sentence 'DRY RUN by default' is a key safety note placed prominently. There is no fluff or redundant information. While it is brief, it covers the main purpose and a critical behavioral default. It earns a high score for efficiency, though it could arguably be slightly more structured by separating purpose and default behavior.

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

Completeness2/5

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

Despite the 100% schema coverage, the description lacks critical process context. The tool involves a dry-run-then-commit flow (as indicated by the plan_handle parameter) but the description never mentions that users must first run a dry run to obtain an execution plan and then confirm with plan_handle for actual booking. This is essential for correct usage. Additionally, with no output schema, the description should hint at what the tool returns (e.g., an execution plan or result), but it does not. For a complex tool with 12 parameters and a two-step workflow, this description is incomplete.

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

Parameters3/5

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

The schema description coverage is 100%, so all parameters are documented in the schema. The description adds only a high-level overview and mentions 'withheld tax' and 'DRY RUN by default,' but these are also captured in the schema (e.g., tax_account param and dry_run param). It does not add deeper meaning about how parameters interrelate (e.g., which accounts apply to which row types) beyond the schema's own descriptions. Thus, it meets the baseline for full schema coverage but does not elevate beyond it.

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 the tool's purpose: create journal entries for Lightyear dividend, interest, and reward distributions, including withheld tax. It uses a specific verb ('create') and identifies the resource (journal entries) and the exact type of distributions. It distinguishes itself from siblings like 'book_lightyear_trades' and 'parse_lightyear_statement' by its focus on distributions, not trades or parsing. The mention of 'withheld tax' adds important scope detail.

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 implies usage for distributions but does not explicitly state when to use this tool versus alternatives. It doesn't say 'use this for dividends, interest, and rewards, not for trade booking or capital gains.' There are sibling tools like 'book_lightyear_trades' and 'prepare_dividend_package' where a clear distinction would help. The description relies on the tool's name and purpose to convey usage context, but it lacks explicit exclusions or alternatives, leaving some inference to the agent.

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