Sök svenska aktiebolag och hämta bokslut, nyckeltal och registeruppgifter.
Scored across 4 tools
Each tool targets a distinct resource and action: searching by name/orgnr, fetching company registration data, fetching financial statements, and fetching corporate group relationships. There is no overlap; an agent can easily select the right tool based on the needed data type.
All tool names follow a consistent Swedish verb_noun pattern: hamta_ (get/fetch) for retrieval of specific entity types, and sok_ (search) for lookup. The naming is uniform and predictable, making tool selection straightforward.
With 4 tools, the server is well-scoped for a focused company data domain. Each tool covers a clear, necessary capability without redundancy or bloat.
The tool surface covers the core workflow: search to find a company, retrieve basic details, obtain financial statements, and inspect corporate group relations. For a read-only company information server, this is a complete and coherent set with no obvious dead ends.
Fullständig resultat- och balansräkning ur bolagets egen årsredovisning. Utan år ges alla år som sammandrag; med år ges hela uppställningen post för post. Belopp i kronor, precis som bolaget lämnat dem – ingenting räknas om. Knappt två tredjedelar av aktiebolagen lämnar årsredovisning digitalt och har därför bokslut här; för övriga är listan tom. De börsnoterade moderbolagen finns med genom sin koncernredovisning enligt IFRS; de talen är märkta regelverk IFRS och är koncernens, inte den juridiska personens.
| Name | Required | Description | Default |
|---|---|---|---|
| ar | No | Räkenskapsårets slutår, t.ex. 2024. | |
| orgnr | Yes | Organisationsnummer, med eller utan bindestreck. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well: it states amounts are in kronor as reported (no recalculation), explains the coverage limitation (~2/3 of companies), and discloses that listed parent companies appear via IFRS consolidated figures marked as such, not as the legal entity. This is rich, honest context. It doesn't mention pagination or response size, but for a financial statement tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the core purpose and then adds conditional behavior, units, coverage caveat, and IFRS nuance. Every sentence earns its place, though it could be slightly better structured with line breaks or bullet points for the caveats. It's appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only retrieval tool with 2 parameters and no output schema, the description covers the essential context: what data is returned, how the optional parameter changes the result, units, coverage limitations, and a special case (IFRS). The only minor gap is that it doesn't describe the response structure or field names, but since there's no output schema and the tool is a straightforward financial statement fetch, this is a small omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters (orgnr and ar). The description adds meaningful context about how 'ar' changes the output (summary vs. post-by-post), which goes beyond the schema's simple 'Räkenskapsårets slutår' description. However, it doesn't add detail about orgnr format beyond what the schema says, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a complete income statement and balance sheet from a company's own annual report, distinguishing it from sibling tools like hamta_foretag (company data) and hamta_koncernrelationer (group relations). It also specifies the exact behavior with and without the 'ar' parameter, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to get bokslut from a company's annual report) and provides a clear conditional: without 'ar' you get all years as a summary, with 'ar' you get the full breakdown post by post. It also notes that only ~2/3 of companies have digital annual reports, so an empty list is expected for others. However, it doesn't explicitly name alternative tools for those cases, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Registeruppgifter och senaste nyckeltal för ett företag: namn, status, organisationsform, adress, bransch, registreringsdatum, omsättning, resultat, anställda och soliditet. Belopp i kronor. Ett fält som är null betyder att uppgiften inte redovisats – inte att den är noll.
| Name | Required | Description | Default |
|---|---|---|---|
| orgnr | Yes | Organisationsnummer, med eller utan bindestreck. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description adds useful interpretation semantics: 'Belopp i kronor' and, importantly, that null means 'uppgift saknas' rather than zero. This prevents misreading missing data. It does not mention error/not-found behavior or data freshness, so it falls short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the resource and content in the first sentence, then appends two short, high-value clarifications (currency and null semantics). No redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with one parametercars and a light output schema, the description covers the needed selection and interpretation information well. It lacks only an explicit pointer to siblings (e.g., 'use sok_foretag to search without a known org number').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high: the single orgNr parameter is described in the schema as 'med eller utan bindestreck'. The description adds no parameter-specific details beyond that, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation ('Retrieve company registration data and latest key figures') and enumerates the returned fields. It does not explicitly contrast with sibling tools such as hamta_bokslut or sok_foretag, which prevents a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus the siblings hamta_bokslut or sok_foretag. The intended use (fetching a company by org number) is only implied by the description and the required parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Moder- och dotterföretag som bolaget har angett i sina årsredovisningar, periodiserade och med källutdrag. Uppgifterna är historiska rapportuppgifter, inte ett påstående om dagens ägande. Rapporterat namn och organisationsnummer bevaras. identifierat_orgnr är null när namnmatchningen är okänd eller tvetydig.
| Name | Required | Description | Default |
|---|---|---|---|
| orgnr | Yes | Organisationsnummer, med eller utan bindestreck. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It details periodization, source excerpts, preservation of reported names/org numbers, and null behavior for identifierat_orgnr. It also clarifies the historical nature, key behavioral context. It does not mention permissions or rate limits, but for a read tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured, front-loading the core purpose in the first sentence. The additional sentences add essential behavioral clarifications, though the final sentence about identifierat_orgnr could be considered output detail, but it's not excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description explains data provenance, periodization, historical nature, and null handling, giving an agent enough to understand what the tool returns. It lacks explicit output format details, but given low complexity and complete parameter schema, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter is simply 'orgnr' with format guidance. The description does not add further semantics to the input parameter; it only mentions an output-related field (identifierat_orgnr) without expanding the input meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving parent and subsidiary companies reported in annual reports, with periodization and source excerpts. It distinguishes the tool from siblings by specifying the resource (group relationships) and the historical nature, which is unique among the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: the data is historical report data, and explicitly states it is not a statement about today's ownership, which guides when not to use it. However, it does not name alternative tools or provide explicit when-to-use instructions against siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sök svenska företag på namn eller organisationsnummer. Ger de främsta träffarna med organisationsnummer, ort, status och senaste omsättning. Använd det här först när du bara har ett namn – de andra verktygen kräver organisationsnummer. Täcker alla registrerade svenska bolag, även avregistrerade.
| Name | Required | Description | Default |
|---|---|---|---|
| fraga | Yes | Företagsnamn eller organisationsnummer. | |
| limit | No | Antal träffar, 1–50. Förval 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns top matches, includes key fields, and covers all registered Swedish companies including deregistered ones. While it does not discuss ranking or no-result behavior, the disclosed scope and output traits are meaningful and non-obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, each earning its place: what the tool searches, what it returns, when to use it, and what data coverage it has. The most decision-relevant usage guidance is front-loaded immediately after the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with two fully documented parameters and no output schema, the description provides sufficient context: input types, key output fields, coverage, and explicit routing against siblings. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents 'fraga' as company name or organizationsnummer and 'limit' as hit count with default. The description reinforces that fraga accepts either input type, but adds no new parameter semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Sök svenska företag på namn eller organisationsnummer.' It clearly states what results are returned and differentiates from siblings by noting that other tools require an organizationsnummer, making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Använd det här först när du bara har ett namn – de andra verktygen kräver organisationsnummer.' This tells an agent exactly when to choose this tool over alternatives and why, which is strong contextual routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
hamta_koncernrelationerhamta_boksluthamta_foretagsok_foretagSwedish company lookups and annual-report financials from Bolagsverket/SCB. Paid per call (x402).
Danish company registry (CVR): company search, financials, ownership, beneficial owners and more.
Swedish B2B intelligence for AI agents: insolvency risk, procurement, BRF health and more.
Vyhledávání a detail českých firem, finanční výkazy a ukazatele z veřejných rejstříků.
Add one secure layer between your agents and this server.
