Apier
REMOTE · WWW.APIER.NO
Machine-verifiable Norwegian company authority: status, roles and coded signing authority.
Available components
Last scanned (15 hours ago)
Scores higher than 98% of remote servers
Reachable. Last reached 5 Nov 2026.
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security97
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation is enforced on tool calls, advertised via RFC 9728 protected-resource metadata. Discovery is public, which costs nothing: no tool can be invoked without a token. View diagnostics → Pass
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC is configured correctly; the domain's records validate against the full chain to the root. View diagnostics → Pass
- The authorisation server offers only Dynamic Client Registration (RFC 7591), which MCP 2026-07-28 deprecated in favour of Client ID Metadata Documents. View diagnostics → Partial
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability76
- 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).Pass
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 6313 tokens (~315/item across 20 items; 19 tools + 1 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management72
- Stability check failed: schema churn in the 30 days we've observed: 7 tool removals, 0 breaking changes, 0 auth/transport breaks, 1 additions. See how to fix → Fail
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 19 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 21 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Checks we ran (13)
- TLS certificate
- Authorization
- HTTPS
- HSTS header
- DNSSEC
- Transport
- Schema quality
- Stability
- Tool coverage
- Injection markers
- Destructive annotations
- Judged manipulation
- MCP protocol
Does not apply to this hosted endpoint (2)
- Supply Chain SecurityScored on package channels only. This is a hosted endpoint, so there is nothing to install or inspect.
- Provenance & TransparencyScored on package channels only. This is a hosted endpoint, so there is nothing to install or inspect.
The score does not measure everything. What the score does not measure →
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 4 Nov 26 0
- New tool “get_company_evidence_pack” functional
- 3 Nov 26 0
- The server rewrote its instructions, which are the text every model session reads security
- Tool “explain_compliance_error” rewrote its description, which is the text the model reads security
- Tool “get_altinn_migration_guidance” rewrote its description, which is the text the model reads security
- Tool “get_company_accounts” rewrote its description, which is the text the model reads security
- Tool “get_company_authority” rewrote its description, which is the text the model reads security
- Tool “get_company_context” rewrote its description, which is the text the model reads security
- Tool “get_company_deadlines” rewrote its description, which is the text the model reads security
- Tool “get_company_obligations” rewrote its description, which is the text the model reads security
- Tool “get_company_profile” rewrote its description, which is the text the model reads security
- Tool “get_company_summary” rewrote its description, which is the text the model reads security
- Tool “get_company_verification” rewrote its description, which is the text the model reads security
- Tool “get_credit_balance” rewrote its description, which is the text the model reads security
- Tool “get_exchange_rate” rewrote its description, which is the text the model reads security
- Tool “get_pricing” rewrote its description, which is the text the model reads security
- Tool “get_public_deadlines” rewrote its description, which is the text the model reads security
- Tool “get_public_obligations” rewrote its description, which is the text the model reads security
- Tool “list_changes” rewrote its description, which is the text the model reads security
- Tool “search_companies” rewrote its description, which is the text the model reads security
- 1 Nov 26 0
- Tool “get_company_authority” rewrote its description, which is the text the model reads security
- 31 Oct 26 0
- “get_company_verification” added an optional parameter “mode” cosmetic
1 cosmetic change on this day. Switch on “Show cosmetic changes” to see it.
- 25 Oct 26 0
- Tool “get_company_authority” rewrote its description, which is the text the model reads security
- Tool “get_company_verification” rewrote its description, which is the text the model reads security
- Tool “get_company_verification” changed its title: Company verification verdict → Company verification status cosmetic
- 24 Oct 26 −4
- Stability: pass → fail ▼ security
- Tool “check_authorization” was removed ▼ security
- Tool “check_fullmakt” was removed ▼ security
- Tool “get_company_filing_history” was removed ▼ security
- Tool “list_acting_capacity” was removed ▼ security
- Tool “request_fullmakt” was removed ▼ security
- Tool “revoke_fullmakt” was removed ▼ security
- Tool “validate_action” was removed ▼ security
- Tool “get_company_authority” rewrote its description, which is the text the model reads security
- Tool “list_changes” rewrote its description, which is the text the model reads security
- Prompt “prepare_vat_return” was removed ▼ functional
- Schema quality: 8129 → 5696 ▲ functional
- Destructive annotations: 100 → pass functional
- Server version: 2026.10.0 → 2026.10.1 functional
- 19 Oct 26 0
- Tool “list_acting_capacity” rewrote its description, which is the text the model reads security
- 17 Oct 26 0
- Tool “get_altinn_migration_guidance” rewrote its description, which is the text the model reads security
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Probed https://www.apier.no/api/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=www.apier.no | CN=YR2,O=Let's Encrypt,C=US | 15 Oct 2026 | 13 Jan 2027 | RSA 2048 | SHA256-RSA | 6a6c6ba4449a3c04e70a8d29ee9f82599b2 |
| SANs: www.apier.no | ||||||
| CN=YR2,O=Let's Encrypt,C=US (CA) | CN=Root YR,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | RSA 2048 | SHA256-RSA | 4ebd24947e24d394802d84a52fd5b319 |
| CN=Root YR,O=ISRG,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | RSA 4096 | SHA256-RSA | f24b6d17f9d9ad7cb1c9fea78782699f |
Background: What to check on a remote MCP endpoint →
DNSSEC secure
Validation of www.apier.no. — Secure
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | Trust anchor | 20326, 38696 | 8, 8 | Verified |
| no. | DS published | 38032 | 13 | Verified |
| apier.no. | DS published | 43675, 43675 | 15, 15 | Verified |
| www.apier.no. | Verified address RRset verified with the apex keys |
Authentication Enforced and verified
The endpoint asked for a token and published valid RFC 9728 metadata describing how to get one.
| Result | Enforced and verified |
|---|---|
| Enforced | On tool calls |
| HTTP status | 200 |
WWW-Authenticate challenge Bearer realm="apier-mcp", error="invalid_token", error_description="A valid Apier API key or an OAuth 2.1 access token for this resource is required", resource_metadata="https://www.apier.no/.well-known/oauth-protected-resource/api/mcp"
Bearer realm="apier-mcp", error="invalid_token", error_description="A valid Apier API key or an OAuth 2.1 access token for this resource is required", resource_metadata="https://www.apier.no/.well-known/oauth-protected-resource/api/mcp" | Header | Value |
|---|---|
| strict-transport-security | max-age=63072000; includeSubDomains; preload |
| content-security-policy | default-src 'self'; script-src 'self' 'unsafe-inline' https://plausible.io https://js.stripe.com https://news.google.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob: https:; font-src 'self' data:; connect-src 'self' https://plausible.io https://*.sentry.io https://*.ingest.sentry.io https://api.stripe.com https://*.supabase.co wss://*.supabase.co https://news.google.com; frame-src https://js.stripe.com https://news.google.com; frame-ancestors 'none'; worker-src 'self' blob:; manifest-src 'self'; media-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; upgrade-insecure-requests |
| x-content-type-options | nosniff |
| x-frame-options | DENY |
| referrer-policy | strict-origin-when-cross-origin |
| permissions-policy | camera=(), microphone=(), geolocation=(), payment=(), usb=(), accelerometer=(), gyroscope=(), magnetometer=(), bluetooth=(), serial=(), hid=(), midi=(), interest-cohort=(), browsing-topics=() |
Protected resource metadata
| Document | https://www.apier.no/.well-known/oauth-protected-resource/api/mcp |
|---|---|
| Retrieved | Yes |
| Resource | https://www.apier.no/api/mcp |
| Authorisation server | https://ietncbksyajattlahlzs.supabase.co/auth/v1 |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://www.apier.no/api/mcp | Verified | 200 | |
| http (plaintext) | http://www.apier.no/api/mcp | HTTPS enforced | 308 | https://www.apier.no/api/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
explain_compliance_error Explain a compliance error (keyless) ~351
Keyless. Resolve a structured Apier compliance error code into a Norwegian-bokmål Explanation envelope: summary, bokmål why, ordered fix_steps, optional documentation link + legal_basis, and an optional handover block (who / where / what / why) for errors a human must resolve (e.g. AUTH_INSUFFICIENT_ROLE, AUTH_NO_DELEGATION, SCOPE_MISSING) — agent-resolvable errors ship `handover: null`. Accepts any code from the closed EXPLAINER_ERROR_CODES catalogue. Optional flat context_org_number / context_scope / context_role / context_field / context_upstream_system strings carry placeholder values interpolated into the bokmål text; missing values fall back to 'ukjent <noun>'. Failure modes: VALIDATION_FAILED on an unknown code; a credential without `read:rulebook` can't see the tool (tools/list leaves it out). The same code and context always give the same text. For a company's live obligations rather than an error explanation, use get_company_obligations instead. Docs: https://www.apier.no/docs/guides/error-handling
| Name | Type | Req | Description |
|---|---|---|---|
| context_field | string | – | Field name interpolated into the explanation. |
| context_org_number | string | – | Organisation the error relates to (9 digits). |
| context_role | string | – | Role code interpolated into the explanation. |
| context_scope | string | – | Scope token interpolated into the bokmål explanation. |
| context_upstream_system | string | – | Upstream system name interpolated into the explanation. |
| error_code | string | yes | An Apier error code from an error envelope. Full list: apier://tools/explain_compliance_error/guide |
| Name | Type | Req | Description |
|---|---|---|---|
| _meta | – | – | – |
| justification | – | yes | – |
| metadata | – | yes | – |
| result | object|null | yes | `explanation`: summary, bokmål why, ordered fix_steps, optional documentation link + legal_basis, and an optional human handover block. |
No examples provided.
get_altinn_migration_guidance Altinn 2 → Altinn 3 migration guidance ~308
Discover the Altinn 3 equivalent of an Altinn 2 service or role code. The 19 June 2026 Altinn 2 deprecation deadline has passed, so this serves remediation for integrations still on Altinn 2. Pass { altinn2_code } (alphanumeric, 1–10 chars, e.g. A0208) for one mapping, or omit it for the whole map. Every response carries the deprecation status computed in Europe/Oslo (deprecation_deadline, days_remaining, deadline_passed). Each entry ships a `verified` flag: gate any production migration on `verified === true`; unverified entries are hints. Deterministic static map (Digdir-sourced); no government system is contacted. Zero-auth REST twin: GET /api/v1/tools/altinn-migration. Failure modes: NOT_FOUND for a code not in the map, VALIDATION_FAILED (INVALID_CODE). Keyless: callable with no API key at all (per-IP limited); a credential without `read:digdir` can't see the tool. No sandbox mirror; a sandbox bearer runs this keyless path. Docs: https://www.apier.no/docs/guides/altinn-system-users
| Name | Type | Req | Description |
|---|---|---|---|
| altinn2_code | string | – | An Altinn 2 service or role code to resolve (alphanumeric, 1–10 chars, e.g. A0208). Omit to get the entire migration map. |
| Name | Type | Req | Description |
|---|---|---|---|
| _meta | – | – | – |
| justification | – | yes | – |
| metadata | – | yes | – |
| result | object|null | yes | The migration lookup: `deprecation_deadline` (Oslo), `days_remaining`, `deadline_passed`, and either one `entry` or the full `mappings[]`. Gate production migration actions on `verified === true`. |
No examples provided.
get_company_accounts Company annual accounts snapshot ~327
A current snapshot of a Norwegian company's annual accounts (årsregnskap) from the OPEN Regnskapsregisteret tier: `has_filed_annual_accounts` (null = unknown, never a fabricated false), `last_accounts_year` and that year's minimal `key_figures` (currency always surfaced, presentation basis, totals). No multi-year history. `null` comes only when the register answers 404 or 410 (200 with `null`, not a 404); an outage answers 503 UPSTREAM_UNAVAILABLE. Failure modes: VALIDATION_FAILED, UPSTREAM_UNAVAILABLE; a credential without `read:brreg` can't see the tool. For a go/no-go verdict, use get_company_verification; for identity, use get_company_context. No API key? Use Bearer apier_sandbox_test_<suffix> (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/norwegian-company-annual-accounts
| Name | Type | Req | Description |
|---|---|---|---|
| org_number | string | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| _meta | – | – | – |
| justification | – | yes | – |
| metadata | – | yes | – |
| result | object|null | yes | The /accounts snapshot: `has_filed_annual_accounts` (tri-state), `last_accounts_year`, and that year's minimal `key_figures` (currency always surfaced, presentation basis, totals). Current-snapshot o… |
No examples provided.
get_company_authority Company signing-authority resolver ~327
The register's coded signing rules for this company, uninterpreted. Call get_company_verification first; this ignores bankruptcy and dissolution. The class (sole, joint, by_role, prokura_only, no_authority, unknown) comes from Fullmakttjenesten and the role holders; `coded_authority` (absent in sandbox) adds coded clauses and stamps. Statutory authority only; it never answers yes or no on who may sign. Failure modes: NOT_FOUND, ENTITY_REMOVED, UPSTREAM_UNAVAILABLE, VALIDATION_FAILED; a credential without `read:brreg` can't see the tool. Altinn rights are not read (withdrawn); for roles use get_company_context, for status use get_company_verification. No API key? Use Bearer apier_sandbox_test_<suffix> (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/signature-rights-norwegian-company
| Name | Type | Req | Description |
|---|---|---|---|
| org_number | string | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| _meta | – | – | – |
| justification | – | yes | – |
| metadata | – | yes | – |
| result | object|null | yes | The /authority answer: a deterministic `classification`, `combinations[]`, the `signaturrett_holders` / `prokura_holders` lists, `kombinasjon_available`, and the stamp-honest `coded_authority` model… |
No examples provided.
get_company_context Company registry facts ~313
Brønnøysund identity slice for a Norwegian organisation: legal name, form of organisation, NACE codes, municipality, registration_date, and the signaturrett / prokura roles (names and role codes from the public register; never fødselsnummer or other national identifiers). Identity ONLY, no verdict on obligations; add get_company_obligations or get_company_deadlines for the regulatory layer. Failure modes: NOT_FOUND, ENTITY_REMOVED, UPSTREAM_UNAVAILABLE, VALIDATION_FAILED; a credential without `read:brreg` can't see the tool (tools/list leaves it out). For an obligations verdict, use get_company_summary instead; for NACE descriptions, use get_company_profile instead. No API key? Use Bearer apier_sandbox_test_<suffix> (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-snapshot
| Name | Type | Req | Description |
|---|---|---|---|
| org_number | string | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| _meta | – | – | – |
| justification | – | yes | – |
| metadata | – | yes | – |
| result | object|null | yes | The Brønnøysund identity slice: legal name, organisasjonsform, NACE codes, municipality, registration_date, and the signaturrett/prokura roles (names and role codes from the public register; never fø… |
No examples provided.
get_company_deadlines Company filing calendar ~362
The coming filing calendar for one company, horizon_months ahead. One entry per obligation and period: obligation_id (the rule_id of get_company_obligations), period_label, due_at, adjusted_for, original_due_at and filing_status. If rulebook_coverage is `covered`, an empty list means none fall due in the window; raise horizon_months (max 60). Sandbox: fixed dates far ahead, horizon_months ignored, no rulebook_coverage; real window: a production key (generic year: use get_public_deadlines). Failure modes: NOT_FOUND, ENTITY_REMOVED, UPSTREAM_UNAVAILABLE, VALIDATION_FAILED; a credential without `read:brreg` can't see the tool. Verdict: use get_company_obligations. No API key? Use Bearer apier_sandbox_test_<suffix> (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/norway-corporate-tax-return-deadline
| Name | Type | Req | Description |
|---|---|---|---|
| horizon_months | integer | – | Look-ahead window in months (1–60). Omitted → the endpoint's default horizon (12). |
| org_number | string | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| _meta | – | – | – |
| justification | – | yes | – |
| metadata | – | yes | – |
| result | object|null | yes | The upcoming filing calendar: per obligation×period, due_at (Europe/Oslo), adjusted_for, original_due_at, period_label and filing_status, plus rulebook_coverage. |
No examples provided.
get_company_evidence_pack Signed evidence pack of what Apier observed about a company ~376
One signed JSON record of what Apier observed about a Norwegian company today: the check bundle, archived changes in the window (`changes_from`, at most 366 days back), your receipts, each archived record's daily anchor proof when available (else pending or proof_unavailable), coverage window and source licences. A record of observation, not a verdict, no admissibility claim. The user can save the `result` object as a .json file and open it at https://www.apier.no/evidence-pack/viewer to verify it. Errors: VALIDATION_FAILED, NOT_FOUND, ENTITY_REMOVED; a credential without `read:brreg` can't see the tool; a call returns unknown tool (-32602). No API key? Use Bearer apier_sandbox_test_<suffix> (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/evidence-pack
| Name | Type | Req | Description |
|---|---|---|---|
| changes_from | string | – | Start of the change window as a calendar date (YYYY-MM-DD). Default: today minus 366 days. Never after today and at most 366 days before it; a date before the archive start is answered as asked, with… |
| org_number | string | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| _meta | – | – | – |
| justification | – | yes | – |
| metadata | – | yes | – |
| result | object|null | yes | The /evidence-pack response: the signed `pack` and its `public_log` entry. Save this `result` object (not the whole MCP envelope) as a .json file to keep or hand on; it verifies offline and in the ke… |
No examples provided.
get_company_obligations Company regulatory obligations ~317
Evaluate the Apier Rulebook for a Norwegian organisation: one entry per rule with rule_id, obligation_name, evaluation_result (applicable, not_applicable or insufficient_data), a reason, the legal_reference, frequency, data_tier_required and the bokmål description, which is inherited byte for byte (never re-translate it). Sandbox fixtures have no rulebook_coverage. Failure modes: NOT_FOUND, ENTITY_REMOVED, UPSTREAM_UNAVAILABLE, VALIDATION_FAILED; a credential without `read:brreg` can't see the tool. For the calendar alone, use get_company_deadlines instead; for the entity-type set that needs no org number or key, use get_public_obligations instead. No API key? Use Bearer apier_sandbox_test_<suffix> (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/norwegian-company-obligations
| Name | Type | Req | Description |
|---|---|---|---|
| org_number | string | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| _meta | – | – | – |
| justification | – | yes | – |
| metadata | – | yes | – |
| result | object|null | yes | The full rule-engine evaluation: one entry per rule with rule_id, evaluation_result, reason, lovdata legal_reference and bokmål description, plus rulebook_coverage. |
No examples provided.
get_company_profile Company profile (Brønnøysund) ~351
Resolve a Norwegian organisasjonsnummer (9 digits) into a structured company profile from Brønnøysund Enhetsregisteret: display name, form of organisation, NACE codes with descriptions, addresses, the dates of registration and dissolution, the `active` / `dissolved` status enum, the MVA-registered flag, and the role codes of persons in the public register (no names); never fødselsnummer or other national IDs. The backing REST route is POST /api/v1/brreg/company-profile. For deadlines and filing status, use get_company_summary; for the signaturrett / prokura role-code summary, use get_company_context instead. No sandbox mirror; it returns SANDBOX_TOOL_UNAVAILABLE under a sandbox bearer. Failure modes: COMPANY_NOT_FOUND, VALIDATION_FAILED, ORG_NUMBER_INVALID_CHECKSUM, UPSTREAM_UNAVAILABLE; a credential without `read:brreg` can't see the tool. 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/norwegian-company-register-search
| Name | Type | Req | Description |
|---|---|---|---|
| org_number | string | yes | 9-digit Norwegian organisasjonsnummer (Brønnøysund Enhetsregisteret ID). Unlike the get_company_* tools, this input schema does NOT run the MOD-11 control-digit check — MOD-11 is enforced by the back… |
| Name | Type | Req | Description |
|---|---|---|---|
| _meta | – | – | – |
| justification | – | yes | – |
| metadata | – | yes | – |
| result | object|null | yes | The Brønnøysund company profile: display name, organisasjonsform, NACE codes + descriptions, addresses, registration/dissolution dates, MVA flag, and person role codes from the public register (no na… |
No examples provided.
get_company_summary Company obligations and deadlines summary ~318
A one-shot summary of obligations and deadlines for a Norwegian organisation: your FIRST call when you orient against a company. One call gives you entity_type, nace_codes, mva_registered, data_tier, obligations[] and deadlines[] (tier_2 adds filing_status), all from one version of the rules. The sandbox answers from fixtures with a different shape (no rulebook_coverage). It is not the identity from the registry: use get_company_context instead; for a drill down call get_company_obligations; to set a horizon_months call get_company_deadlines. Failure modes: NOT_FOUND, ENTITY_REMOVED, UPSTREAM_UNAVAILABLE, VALIDATION_FAILED; a credential without `read:brreg` can't see the tool. No API key? Use Bearer apier_sandbox_test_<suffix> (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-snapshot
| Name | Type | Req | Description |
|---|---|---|---|
| org_number | string | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| _meta | – | – | – |
| justification | – | yes | – |
| metadata | – | yes | – |
| result | object|null | yes | The /summary composition: entity_type, nace_codes, mva_registered, data_tier, obligations[], deadlines[] (tier_2 adds filing_status), and (tier_1 only) upgrade_path. NOT the registry identity; call g… |
No examples provided.
get_company_verification Company verification status ~402
Fast go / no-go trust check on a Norwegian counterparty organisation. It keys ONLY off entity activity and visible signing authority. `verification_status` is `pass` (active and signing authority visible), `fail` (not active: konkurs, avvikling or oppløst) or `unknown` (not determinable; never a claimed absence). `signing_authority_summary` lists roles, not the joint rule; for that use get_company_authority. Fails with NOT_FOUND, ENTITY_REMOVED, UPSTREAM_UNAVAILABLE or VALIDATION_FAILED; a credential without `read:brreg` can't see the tool (tools/list leaves it out). For identity, call get_company_context instead. No API key? Use Bearer apier_sandbox_test_<suffix> (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/norwegian-company-register-search
| Name | Type | Req | Description |
|---|---|---|---|
| mode | string | – | `verdict` (default) returns the pass / fail / unknown status. `checks` returns the check bundle from GET /api/v1/company/{org}/checks instead: every check (registration, bankruptcy and liquidation, V… |
| org_number | string | 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. |
| Name | Type | Req | Description |
|---|---|---|---|
| _meta | – | – | – |
| justification | – | yes | – |
| metadata | – | yes | – |
| result | object|null | yes | The trust-check result: `verification_status` (pass / fail / unknown; `warn` reserved), the seven signals, Norwegian `summary`, `signing_authority_summary`, `last_accounts_year`, and the registry ide… |
No examples provided.
get_credit_balance Own prepaid credit balance ~237
Call this BEFORE a batch of metered calls to confirm the calling key's prepaid credit balance covers it, and AFTER a 402 INSUFFICIENT_CREDITS + human top-up to verify the funds landed. The balance is ALWAYS the authenticated key's own — no parameters, so reading another key's balance is structurally impossible. Returns api_key_id, balance_ore (whole øre, always an integer), currency (NOK), updated_at (null = never topped up = balance 0), and top_up_url (hand it to a human). Affordability: cost_ore from get_pricing times planned calls versus balance_ore. Free, zero side effects. Failure modes: 401 without a key (NOT keyless: use get_pricing for keyless price discovery); a credential without `read:credits` (or `read:*`) can't see the tool; CREDIT_BALANCE_UNAVAILABLE (503, retryable; a money read is never fabricated). Under a sandbox bearer it returns SANDBOX_TOOL_UNAVAILABLE. Docs: https://www.apier.no/docs/guides/agent-payments
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| _meta | – | – | – |
| justification | – | yes | – |
| metadata | – | yes | – |
| result | object|null | yes | The authenticated key's own prepaid balance: api_key_id, balance_ore, currency, updated_at, top_up_url. |
No examples provided.
get_exchange_rate Norges Bank exchange rate (keyless) ~334
Keyless; runs the production path under a sandbox bearer. Norges Bank reference exchange rate for a currency against NOK — the benchmark Norwegian tax and accounting rules accept for foreign-currency obligations. No Norwegian-company input. Input: { base, quote, date? } — ISO 4217 codes, NOK-anchored: exactly one side MUST be 'NOK'. The response is always base NOK and quote = the other currency, whatever order you sent; rate = NOK per 1 unit of quote; date = the day the rate is valid for (weekends and holidays fall back to the prior business day, so it can differ from requested_date). A pair without a NOK side is rejected client-side as UNSUPPORTED_CURRENCY_PAIR: derive cross rates from two NOK legs. Failure modes: VALIDATION_FAILED, UNSUPPORTED_CURRENCY_PAIR, INVALID_DATE, UPSTREAM_UNAVAILABLE, NO_RATE_AVAILABLE; a credential without `read:norgesbank` can't see the tool. For obligations or deadlines rather than a rate, use get_company_summary instead. Docs: https://www.apier.no/docs/mcp
| Name | Type | Req | Description |
|---|---|---|---|
| base | string | yes | Base currency — ISO 4217 three-letter code (case-insensitive). Exactly one of base/quote must be 'NOK'. |
| date | string | – | Optional ISO 8601 date (YYYY-MM-DD); omit for the latest published rate. Non-business days fall back to the prior business day. |
| quote | string | yes | Quote currency — ISO 4217 three-letter code (case-insensitive). Exactly one of base/quote must be 'NOK'. |
| Name | Type | Req | Description |
|---|---|---|---|
| _meta | – | – | – |
| justification | – | yes | – |
| metadata | – | yes | – |
| result | object|null | yes | The Norges Bank NOK reference rate, the date it is valid for, and the source attribution. |
No examples provided.
get_pricing Apier price list (keyless) ~213
Call this BEFORE metered work to check per-call cost and whether billing enforcement is live. Keyless (runs the production path under a sandbox bearer): executes WITHOUT an API key, so an agent can price a workflow before it holds any credential. Returns the machine-readable price list: every credit-metered REST endpoint with its MCP tool name and cost in whole øre (always an integer), the enforcement.live flag (while false nothing is debited and a 402 is impossible), the 402 INSUFFICIENT_CREDITS recovery-contract field list, the top-up bounds with top_up_url, and the how_to_pay_guide URL. Prices derive from the SAME configuration the 402 meter debits, so this surface cannot drift from enforcement. Input: none — call with {}. Failure modes: per-IP rate limiting and transient errors only. For the calling key's own balance, use get_credit_balance (Bearer key required) instead. Docs: https://www.apier.no/docs/guides/billing
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| _meta | – | – | – |
| justification | – | yes | – |
| metadata | – | yes | – |
| result | object|null | yes | The machine-readable price list: per-endpoint/tool costs in whole øre, enforcement.live, the 402 recovery-contract shape, top-up bounds, and the how_to_pay_guide URL. |
No examples provided.
get_public_deadlines Norwegian filing calendar (keyless) ~285
Keyless; runs the production path under a sandbox bearer. The universal Norwegian filing calendar: the deadlines for every Norwegian business in the covered categories (MVA, A-melding, Skattemelding, Årsregnskap), which do not depend on any one organisation. One entry per obligation and period for a single Europe/Oslo calendar year: a per-period obligation_id (such as `mva-termin-4-2026`; the company tools use rule ids such as `MVA_FILING_BIMONTHLY` instead), period, deadline (Europe/Oslo), submission_window_closes, adjusted_from (the legal date before a shift, else null), legal_reference and applies_to_entity_types. The output is deterministic for a given rulebook_version. The only input is an optional `year` (2020–2100; defaults to the current Oslo year). Failure modes: VALIDATION_FAILED on year shape; a credential without `read:rulebook` can't see the tool. For a specific company's calendar, use get_company_deadlines instead. Docs: https://www.apier.no/docs/guides/norway-corporate-tax-return-deadline
| Name | Type | Req | Description |
|---|---|---|---|
| year | integer | – | Europe/Oslo calendar year the calendar should cover (2020–2100). Omitted → the current Oslo year at the endpoint. |
| Name | Type | Req | Description |
|---|---|---|---|
| _meta | – | – | – |
| justification | – | yes | – |
| metadata | – | yes | – |
| result | object|null | yes | The universal Norwegian filing calendar for one Europe/Oslo year, independent of any specific organisation. |
No examples provided.
get_public_obligations Obligations by entity type (keyless) ~248
Keyless; runs the production path under a sandbox bearer. Retrieve the universal obligation set for a Norwegian entity type — every regulatory obligation that applies by virtue of BEING that organisational form, before per-company Tier-2 data is layered on. Use it for 'what does an AS owe?' or 'what are the baseline filings for an Enkeltpersonforetak?' without naming a company. Each obligation carries tier_2_required: true means the rule engine needs commercial data to decide for a SPECIFIC company, false means it applies unconditionally. Input: { entity_type } from the closed enum AS / ENK / ANS / DA / NUF (no 'OTHER' fallback). Failure modes: VALIDATION_FAILED, UPSTREAM_UNAVAILABLE; a credential without `read:rulebook` can't see the tool. For a specific company's evaluated obligations, call get_company_obligations; for the universal calendar, use get_public_deadlines. Docs: https://www.apier.no/docs/guides/norwegian-company-obligations
| Name | Type | Req | Description |
|---|---|---|---|
| entity_type | string | yes | Norwegian organisational form (closed enum): AS / ENK / ANS / DA / NUF. |
| Name | Type | Req | Description |
|---|---|---|---|
| _meta | – | – | – |
| justification | – | yes | – |
| metadata | – | yes | – |
| result | object|null | yes | The universal obligation set for the entity type, before per-company Tier-2 data is layered on. |
No examples provided.
list_changes Query the cross-source change archive ~420
Read Apier's cross-source change archive — created / updated / deleted events detected across the upstreams Apier polls (Brønnøysund, Norges Bank, NAV, Skatteetaten Tier-2; the Digdir and Altinn schema pollers are retired, so `digdir` and `altinn` are valid but empty filters). Filter by { source, entity_type, entity_id, change_type } and a { from }–{ to } detected_at range. Queries WITHOUT entity_id withhold personal-field rows by design (`personal_fields_withheld: true`); the org-scoped form returns everything. Keyset-paginated newest-first: pass { limit } (1–500, default 50) and carry `next_cursor` back verbatim (HMAC-signed; an edited one is CURSOR_INVALID: start over without a cursor). Failure modes: VALIDATION_FAILED, CURSOR_INVALID; a credential without `read:changes` can't see the tool (tools/list leaves it out). No sandbox mirror; returns SANDBOX_TOOL_UNAVAILABLE under a sandbox bearer. Docs: https://www.apier.no/docs/guides/webhooks
| Name | Type | Req | Description |
|---|---|---|---|
| change_type | string | – | Filter to created / updated / deleted events. |
| cursor | string | – | Opaque signed cursor from a previous `next_cursor` — pass back verbatim. |
| entity_id | string | – | Filter to one entity's change stream (e.g. a 9-digit org number). |
| entity_type | string | – | Filter to one entity type (e.g. annual_accounts, company). |
| from | string | – | Lower bound on detected_at (ISO 8601 with timezone offset). |
| limit | integer | – | Page size 1–500 (route default 50). |
| source | string | – | Filter to one upstream source (e.g. brreg / altinn / digdir / norges_bank). Omit for all sources. |
| to | string | – | Upper bound on detected_at; must be ≥ from. |
| Name | Type | Req | Description |
|---|---|---|---|
| _meta | – | – | – |
| justification | – | yes | – |
| metadata | – | yes | – |
| result | object|null | yes | The change page: `data[]` rows (source, entity_type, entity_id, change_type, detected_at, source_snapshot_id, observation_kind), a `pagination` block, and `personal_fields_withheld`. Ordered newest-f… |
No examples provided.
redeem_issuance_token Redeem an owner-issued key-issuance token (keyless) ~288
Convert an owner-issued key-issuance token into your own API key — the headless onboarding step for an agent that holds no credential yet. Keyless: the one-time token IS the credential. Minting and revocation are dashboard-only, so an agent can never self-issue authority. Redemption is strictly SINGLE-USE and atomic: on success (201) the token is consumed and the result carries {id, name, scopes, created_at, plaintext_key} — returned EXACTLY ONCE; store it immediately. Failure modes: an expired / used / revoked / unknown token yields ONE uniform ISSUANCE_TOKEN_INVALID failure (ask the owner for a fresh token, never retry); MAX_KEYS_REACHED (409) means 3 active keys — the token was NOT consumed, retry with the SAME token after the owner revokes a key. After onboarding, use get_pricing to price metered work and get_credit_balance (with your new key) for the balance. No sandbox mirror; returns SANDBOX_TOOL_UNAVAILABLE under a sandbox bearer. Docs: https://www.apier.no/docs/authentication
| Name | Type | Req | Description |
|---|---|---|---|
| token | string | yes | The one-time key-issuance token the account owner minted in the Apier dashboard (Agent issuance tokens) and handed to you out-of-band. Single-use: it is consumed atomically on success. Never logged b… |
| Name | Type | Req | Description |
|---|---|---|---|
| _meta | – | – | – |
| justification | – | yes | – |
| metadata | – | yes | – |
| result | object|null | yes | The freshly issued API key: id, fixed name, read:* scopes, creation time, and the one-time plaintext_key. |
No examples provided.
search_companies Search companies by name ~305
Resolve a Norwegian company NAME to its 9-digit organisasjonsnummer. Use this as your FIRST call whenever you have a company's name but NOT its org_number — every other company tool needs the number; guessing one risks the wrong company. Searches Brønnøysund's public Enhetsregisteret and returns up to ten candidates with five fields each (name, org_number, org_form, municipality, registry status). Then call get_company_summary or get_company_context with the chosen org_number. Input: { name } (2–100 chars, æ/ø/å supported). On NOT_FOUND, broaden the name and drop the legal form — never loop on the same name. Failure modes: VALIDATION_FAILED, NOT_FOUND, UPSTREAM_UNAVAILABLE; a credential without `read:brreg` can't see the tool (tools/list leaves it out). No sandbox mirror — the sandbox fixtures catalogue already lists every synthetic org. Docs: https://www.apier.no/docs/guides/norwegian-company-register-search
| Name | Type | Req | Description |
|---|---|---|---|
| name | string | yes | Company name to search for (2–100 characters, trimmed). Free-text; matched against Brønnøysund's registered `navn` field. Omit the legal form for a broader match (search `Nordic Widgets`, not `Nordic… |
| Name | Type | Req | Description |
|---|---|---|---|
| _meta | – | – | – |
| justification | – | yes | – |
| metadata | – | yes | – |
| result | object|null | yes | The /company/search projection: { query, count, candidates } — five fields per candidate (name, org_number, org_form, municipality, status). Pick an org_number, then call get_company_summary / get_co… |
No examples provided.
How do I install the Apier MCP server?
Apier is a hosted endpoint at https://www.apier.no/api/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · www.apier.no
claude mcp add --transport http no-apier-mcp 'https://www.apier.no/api/mcp'
What is the Apier MCP server?
Apier is an MCP server listed in the public MCP registry as no.apier/mcp. Machine-verifiable Norwegian company authority: status, roles and coded signing authority. This page covers its hosted endpoint (https://www.apier.no/api/mcp).
Is the Apier MCP server safe to use?
Apier scores 91 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Apier MCP server expose?
Apier exposes 19 tools: get_company_summary, get_public_obligations, get_exchange_rate, get_company_profile, get_company_context, and 14 more. Their descriptions and schemas cost roughly 6,082 tokens of context every time the server is loaded.
Does the Apier MCP server require authentication?
Yes. Apier asked us for credentials when we connected, so you will need to authorise it in your MCP client before it can do anything.
Is the Apier MCP server still maintained?
Apier is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What did VerifyMCP test on the Apier MCP server?
VerifyMCP ran 13 checks on Apier, covering TLS certificate, Authorization, HTTPS, HSTS header and 9 more. Supply Chain Security and Provenance & Transparency do not apply to a hosted endpoint, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out.