easor
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Read-only Easor financial reporting tools. Nothing here can change data in Easor. For a full Tuloslaskelma or Tase use build_profit_and_loss_statement / build_balance_sheet, and check unclassifiedAccounts (and balanceMismatch for Tase) before reporting a total.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_configured_organizationsA | Lists the organizations that have credentials of their own in this server's .env (from the variable names only, never their values), with the organization's name and business id from Easor when available. sharedApis names the APIs (GL_FI, SALES_FI) that also have shared credentials: those can cover organizations not in the list, which then have to be entered by number. |
| get_accounting_periodsB | Returns a customer's accounting periods (each with nested bookkeeping periods) from Easor's Organization API. Global — no region-specific path. |
| get_organisation_infoB | Returns organisation info (address, business id, VAT id/period/obligations, invoicing details, ...) from Easor's Organization API. |
| get_used_chart_of_accountsC | Returns the bookkeeping accounts used within a date range. |
| get_general_ledger_eventsB | Returns a page of general ledger events (individual postings), optionally filtered. When summing postings for a total, use (credit ?? debet ?? 0) per posting — NEVER credit - debet or debet - credit. credit and debet are mutually exclusive per posting and already correctly signed (credit negative, debet positive); subtracting one from the other double-applies the sign. This matters most when an account has both kinds of posting in the period (e.g. a sale immediately reversed same-day) — an account with only one kind can look reconciled even with a wrong formula. |
| get_voucher_imageA | Returns the PDF image of a voucher from Easor. The voucherId can be obtained from any Easor response that includes a voucher identifier (for example the voucherId field on general ledger event rows). Memorial vouchers (muistioviennit) never have an image. The organizationNumber must match the organization the voucher belongs to. Set openFile=false to receive only the base64 PDF data without saving to disk or opening a viewer (intended for embedded display in a web page; default true opens the PDF in the system viewer). |
| get_dimension_settingsB | Returns the organization's enabled dimension types (CostCenter/CostType/Project/ProjectType). |
| get_dimension_valuesC | Returns dimension values (e.g. specific cost centers/projects), paged and optionally filtered. |
| sales_get_invoiceC | Search or get invoice — GET /v1/{organizationNumber}/invoices [PublicGetInvoiceFIV1]. |
| lookup_chart_of_accounts_templateA | Looks up Easor's generic (organization-independent) Finnish chart-of-accounts template — a static reference bundled with this server, not a live API call. Use it to find which account numbers/groups are structurally relevant to a question (e.g. fixed vs. variable costs, which mainCategory alone cannot distinguish), NOT as a source of actual balances — always confirm real figures against the organization's own live data (get_used_chart_of_accounts / get_general_ledger_events / build_profit_and_loss_statement) since an organization's real chart can differ from this template. Pass listGroups:true alone to explore the group hierarchy first; otherwise filter by accountNumber (exact), accountNumberPrefix, nameContains, and/or groupContains (matches any segment of the account's group path, e.g. "MUUTTUVA" for variable-cost groups, "KIINTEÄ" for fixed-cost groups) — at least one filter is required. When presenting a grouped report — balance sheet (tase) or income statement (tuloslaskelma) alike, or anything else grouped by account — use groupPath's own names VERBATIM as section headings/structure — do not paraphrase, translate, or invent your own category labels. |
| build_profit_and_loss_statementA | Builds a fully-computed Tuloslaskelma for the given period — every official line with real activity (Kirjanpitoasetus Liite 1 kululajikohtainen-tuloslaskelma order; lines with no activity at all are omitted — subtotals like LIIKEVOITTO are always kept, even at 0), with real euro figures already in conventional presentation sign (revenue positive, costs negative, profit positive when profitable — NOT raw ledger signs). Use this instead of assembling a report by hand from lookup_chart_of_accounts_template — it always produces the same structure. fromDate and toDate must fall within the same accounting period (fiscal year) — this refuses otherwise rather than silently computing a wrong number. Any account the organization uses that isn't recognized by the bundled template is listed separately in unclassifiedAccounts (raw ledger sign there, not the presentation sign above), never silently folded into a line — check those before reporting a total. |
| build_balance_sheetA | Builds a fully-computed Tase as of the given date — VASTAAVAA (assets) and VASTATTAVAA (equity + liabilities), every official line with real activity (lines with no activity at all are omitted) and real euro figures, cumulative since inception (no period math needed for a balance-sheet account). Both sides are shown as positive figures (conventional presentation sign, NOT raw ledger signs) — a balanced Tase means EQUAL totals on both sides. The fiscal year's not-yet-closed result is included in OMA PÄÄOMA under Tilikauden voitto (tappio) and also returned as currentPeriodResult, so a mid-year Tase balances too. Use this instead of assembling a report by hand from lookup_chart_of_accounts_template — it always produces the same structure. balanceMismatch is non-null if the two sides don't match (a Tase must balance) — surface that to whoever asked rather than reporting an unbalanced tase as if it were fine. Any account the organization uses that isn't recognized by the bundled template is listed separately in unclassifiedAccounts (raw ledger sign there, not the presentation sign above), never silently folded into a line. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Most tools target a distinct resource (invoices, periods, org info, ledger events, vouchers, dimensions) and the two reporting builders are clearly separated by statement type. The main fuzzy pair is get_used_chart_of_accounts vs lookup_chart_of_accounts_template, which the descriptions do disambiguate (live data vs static template), plus the verbose descriptions carry a lot of the distinguishing weight. Overall boundaries are clear enough that misselection is unlikely.
Nearly all names follow snake_case verb_noun (get_*, list_*, build_*, lookup_*), which is predictable and readable. Deviations are minor: 'sales_get_invoice' puts the domain first instead of the verb, and 'organisation' (British) coexists with 'organization' in list_configured_organizations.
12 tools is squarely in the well-scoped range, and each one covers a distinct slice of the accounting/reporting domain (reference data, live ledger data, and two computed statements). Nothing looks redundant or padding-like.
For a read-only Finnish bookkeeping/reporting surface, coverage is strong: org info, periods, chart of accounts, ledger events, voucher images, dimensions, and computed Tase/Tuloslaskelma. Gaps exist around write operations (no invoice or voucher creation, no updates) and there is no direct voucher listing/search, only image retrieval by id.