Apier

Company state on a date, or its observed changes

get_company_history

Read-onlyIdempotent

Company history from Apier's archive of Brønnøysund observations. Mode as_of with date returns the state Apier had observed at the end of that day: every tracked field with its status, source and licence. Mode history with from and to (at most 366 days) returns up to 1,000 changes observed in the window, or with view diff one field-by-field comparison. The archive starts 2026-07-30 and nothing earlier is back-filled; coverage says what is covered. A record of what the register showed, not what was in force, never a verdict. Errors: VALIDATION_FAILED, UPSTREAM_UNAVAILABLE; a credential without read:brreg can't see the tool; a call returns unknown tool (-32602). No API key? Use Bearer apier_sandbox_test_ (a fresh suffix) to get fixtures; valid orgs are the 818, 99966 and 99977 series and 999000002 (see GET /api/v1/sandbox/fixtures). Cost: 50 øre (NOK 0.50) per call, prepaid (prices: the get_pricing tool or GET /api/v1/pricing). Docs: https://www.apier.no/docs/guides/company-history

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": {
      "org_number": "<org_number>",
      "mode": "<mode>"
    },
    "name": "get_company_history"
  }
}

Input Schema

Name	Required	Description
`to`	No	Only with mode `history`, and required there: end of the window (YYYY-MM-DD), not after today in Europe/Oslo and at most 366 days after `from`.
`date`	No	Only with mode `as_of`, and required there: a calendar date (YYYY-MM-DD), not after today in Europe/Oslo. A date before the archive start is answered with the facts `not_checked`.
`from`	No	Only with mode `history`, and required there: start of the window (YYYY-MM-DD), not after `to`.
`mode`	Yes	`as_of` returns the state Apier had observed at the end of `date`; `history` returns up to 1,000 changes Apier observed between `from` and `to` (`truncated` marks more) (or, with `view` `diff`, one field-by-field comparison of the two ends).
`view`	No	Only with mode `history`: `events` (default) lists the changes; `diff` compares the state at the end of `from` with the state at the end of `to`.
`org_number`	Yes	9-digit Norwegian organisasjonsnummer (Brønnøysund ID); MOD-11-checked up-front — a failing value is rejected as VALIDATION_FAILED, so correct the number rather than retrying it.

Output Schema

Name	Required	Description
`_meta`	No
`result`	Yes	The /as-of or /history response: observed facts with their source, licence and coverage window; never a verdict.
`metadata`	Yes
`justification`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description layers on what they cannot: archive start 2026-07-30 with no back-fill, a 1,000-change cap with a `truncated` marker, credential requirement (`read:brreg`), the exact error codes and the -32602 unknown-tool outcome, and a 0.50 NOK prepaid cost per call. That is unusually complete disclosure for a read tool.

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?

Purpose and modes are front-loaded and every sentence carries operative information. The tail end (sandbox fixtures, pricing, docs URL) is dense and run-on, but it is genuinely useful rather than filler.

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

Completeness5/5

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

For a six-parameter, two-mode tool with an output schema, the definition covers the remaining burden: coverage semantics, truncation, auth scope, cost, sandbox fallback and failure modes. An agent has everything needed to call it correctly without opening the docs link.

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 100% and each parameter already carries a detailed description including the mode pairing and date constraints, so the description is largely restating schema facts like the 366-day limit and pre-archive `not_checked` behaviour. A baseline 3 is appropriate: the schema, not the description, does the semantic work here.

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 opening sentence names a specific resource (company history over Brønnøysund observations) and immediately splits it into two concrete modes, `as_of` returning an observed state and `history` returning observed changes. It also draws the semantic boundary ('a record of what the register showed, not what was in force, never a verdict'), which separates it from verdict/compliance siblings.

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?

It states precisely when each mode applies, which parameters pair with which mode, the 366-day window limit and the `events` vs `diff` choice. What it doesn't do is route the agent away from sibling tools such as list_changes or get_company_profile, so selection between tools still requires inference.

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

All Apier tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.