Skip to main content
Glama
iseppo

e-arveldaja MCP Server

by iseppo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Book Lightyear Trades

book_lightyear_trades
Destructive

Books Lightyear stock Buy/Sell trades into e-arveldaja, previewing by default. For sells, requires a capital gains file to calculate FIFO cost basis and recognized gain/loss.

Instructions

Book Lightyear stock Buy/Sell trades. DRY RUN by default. For sells, capital_gains_file is required for FIFO cost basis and recognized gain/loss.

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_accountNoAccount for EXPENSED trade fees — every Buy and Sell fee, both the platform fee and the FX-conversion fee (default: auto-detect 'Kulu aktsiatelt ja osadelt', standard 8335). No fee is capitalized into the investment cost: Lightyear's FIFO cost basis is fee-exclusive, and RTJ 3 expenses transaction costs on assets held at fair value through profit or loss.
plan_handleNoExecution-plan handle from the reviewed dry run. Required for dry_run=false.
loss_accountNoRealized loss account, debited on a sell loss (default: auto-detect 'Kulu aktsiatelt ja osadelt', standard 8335)
skip_tickersNoComma-separated tickers to skip (default: BRICEKSP, ICSUSSDP). Pass "none" to disable; the empty string is treated as the default.
broker_accountYesBroker cash account (e.g. 1120 Lightyear konto)
gain_loss_accountNoRealized gain account, credited on a sell gain (default: auto-detect 'Tulu aktsiatelt ja osadelt', standard 8330)
capital_gains_fileNoAbsolute path to Lightyear CapitalGainsStatement CSV (required for sell entries)
investment_accountYesInvestment/securities account (e.g. 1550 Finantsinvesteeringud)
broker_dimension_idNoDimension ID for broker account (accounts_dimensions_id)
capital_gains_file_refNoOpaque Lightyear capital-gains file reference; exclusive with capital_gains_file.
investment_dimension_idNoDimension ID for investment account (accounts_dimensions_id)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.29.2
    • addedInput schema / additionalProperties
      Added value: +false
  2. Addedv0.25.3
  3. Removedv0.25.2
  4. First observedv0.18.1

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the risk profile is known; the description usefully adds that the default is a non-mutating dry run and that sells need a capital-gains file for FIFO basis. It does not warn about duplicate journals on repeat non-dry-run calls, which is the main residual behavioral gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short, front-loaded sentences: action, safety default, then conditional requirement. No filler, and the most decision-relevant fact (dry run by default) appears early.

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 14-parameter booking tool with no output schema, the description covers the action, the safe default, and the one hard precondition. The dry-run → plan_handle → execute workflow is left to the schema, which is acceptable given the 100% coverage but would have been worth one sentence.

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?

Schema description coverage is 100% with rich per-parameter text (fee_account, skip_tickers, plan_handle defaults), so the schema carries the load. The description only reiterates the capital_gains_file requirement already encoded in the schema, adding little parameter-level meaning.

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 and resource — booking Lightyear stock Buy/Sell trades — which cleanly separates it from siblings like parse_lightyear_statement (parse only) and book_lightyear_distributions (different asset event). An agent can tell what this tool produces without opening the schema.

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?

Clearly signals that the default call is a preview and that sells additionally require capital_gains_file, which is real usage guidance. It stops short of naming prerequisites (parse the statement first, or the reviewed-plan workflow behind plan_handle) or stating when not to call it.

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