Skip to main content
Glama

Läs årsbokslutet

read_arsbokslut
Read-onlyIdempotent

Läser årsbokslutet för enskild firma, handelsbolag, kommanditbolag, ideell förening eller stiftelse, och årsredovisningen (K2, PDF) för ekonomisk förening (doc=ar, med förvaltningsberättelse: flerårsöversikt, förändringar i eget kapital, resultatdisposition, medlemsinformation): regelverk (k1 förenklat årsbokslut eller k2) med förslag och skäl (eligibility), resultaträkningen och balansräkningen rad för rad i hela kronor med jämförelsetal och vilka konton varje post bygger på, upplysningar, underskrifter, kontroller (errors, warnings) och om årsbokslutet är markerat undertecknat. Aktiebolag och föreningar med årsredovisning svarar med fel. Scope view. Argument: orgnr, year.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "orgnr": "<orgnr>",
      "year": "<year>"
    },
    "name": "read_arsbokslut"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearYes
orgnrYesBolagets organisationsnummer, 10 siffror med eller utan bindestreck, t.ex. 559900-1004. Hämta med list_companies.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds substantive behavior beyond that: the exact return contents (resultaträkning/balansräkning line by line with comparative figures and account provenance, upplysningar, underskrifter, errors/warnings, signature flag) and the error behavior for AB. It does not mention latency, PDF vs JSON structure, or 'Scope view' meaning.

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

Conciseness3/5

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

Purpose and entity scope are front-loaded, which is good, but the body is one very long run-on sentence mixing entity types, return contents, column semantics and error behavior, followed by two dangling fragments ('Scope view. Argument: orgnr, year.'). Grouping into scope / returns / errors would make it far easier to scan.

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?

There is no output schema, so the description carries the full burden of describing return values — and it does so in detail, including errors/warnings and the signed flag. The main gap is the undocumented year parameter and the unexplained 'Scope view' phrase, but for a two-parameter read tool this is largely complete.

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 coverage is 50%: orgnr is well documented in the schema (10 digits, hyphen optional, fetch via list_companies), but year has no documentation anywhere. The description only appends 'Argument: orgnr, year', which restates the parameter names without clarifying whether year is the fiscal year, must match an existing fiscal year, or what happens if none exists. With half the schema documented, baseline 3 applies, but the description makes no compensating contribution.

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 (Läser) and resource (årsbokslut/årsredovisning) and scopes it precisely to entity types (enskild firma, handelsbolag, kommanditbolag, ideell förening, stiftelse, ekonomisk förening). It also names the content returned per document type, so an agent can tell it apart from read_annual_report or get_balance_sheet without opening another 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?

Explicit inclusion and exclusion criteria are given: which legal forms it serves and that 'Aktiebolag och föreningar med årsredovisning svarar med fel'. That is real when-not guidance, plus a hint to use doc=ar for ekonomisk förening. It falls short of naming the sibling tool (read_annual_report) the agent should call instead for AB.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources