# mcp MCP server

Compliance API bridging AI agents to Norwegian government systems (Altinn, Maskinporten, BRREG)

## Links
- Registry page: https://www.getdrio.com/mcp/no-apier-mcp
- Repository: https://github.com/PowerLaunch/apier-mcp
- Website: https://www.apier.no/docs

## Install
- Endpoint: https://www.apier.no/api/mcp
- Auth: Auth required by registry metadata

## Setup notes
- Remote header: Authorization (required; secret)
- The upstream registry signals required auth or secrets.
- Remote endpoint: https://www.apier.no/api/mcp
- Header: Authorization

## Tools
- get_company_summary (Company compliance summary) - Retrieve a one-shot compliance summary for a Norwegian organisation by its 9-digit organisasjonsnummer (organisation number, the public ID issued by the Brønnøysund Register Centre / Enhetsregisteret — Central Register of Legal Entities). Use this as your FIRST call when orienting against a company: one round-trip COMPOSES entity_type (e.g. AS / Aksjeselskap (limited company), ENK / Enkeltpersonforetak (sole proprietorship), NUF / Norskregistrert utenlandsk foretak (Norwegian branch of a foreign company)), the nace_codes industry classification, mva_registered (VAT-registration tri-state), the served data_tier, the full obligations[] catalogue the Universal Rulebook evaluates (one verdict per applicable rule, each carrying its own per-obligation state), and the rolling deadlines[] filing calendar — all computed from one rule version and one company snapshot so downstream reasoning never has to reconcile drifting views. The obligations[] array is byte-identical to what get_company_obligations returns (same rule-engine evaluation, shared cache row); deadlines[] matches get_company_deadlines over the same horizon on tier_1, and on tier_2 additionally carries the definitive per-period filing_status (filed / overdue, sourced from compliance_states) that the standalone deadlines tool never injects. This MCP tool exposes only { org_number }, so call get_company_deadlines when you need to control the deadline horizon_months. On tier_1 it also returns upgrade_path, a Norwegian pointer at the Altinn delegation flow (null on tier_2). It deliberately does NOT return the registry identity flat — no legal name, registered municipality, signaturrett (signing authority), prokura (power of procuration), role-holders, or a top-level company-wide status enum; call get_company_context for those identity fields. For deeper drill-down on individual obligations call get_company_obligations; for upcoming filing dates alone call get_company_deadlines. Input: { org_number } as 9 digits passing the Brønnøysund MOD-11 control-digit check. Failure modes the agent must handle: 404 not_found if the org_number is well-formed but unknown; SCOPE_INSUFFICIENT if the API key is not scoped read:brreg; UPSTREAM_TIMEOUT if Brønnøysund is slow; VALIDATION_FAILED on a non-9-digit or mod-11-failing input. For the registry identity flat (legal name, signaturrett, prokura, role-holders) without a compliance verdict, use get_company_context instead. No API key? Self-serve in the sandbox: authenticate tools/call with `Authorization: Bearer apier_sandbox_test_<suffix>` (ALWAYS append a unique random suffix, e.g. a fresh UUID, for session isolation) and this tool answers from deterministic synthetic fixtures with `_meta.is_sandbox: true` — use the reserved MOD-11-valid sandbox org numbers from GET /api/v1/sandbox/fixtures (e.g. 999660088). Endpoint: https://www.apier.no/api/mcp
- get_public_obligations (Obligations by entity type) - Retrieve the universal obligation set for a Norwegian entity type. Returns every regulatory obligation that applies by virtue of an entity BEING that organisational form, BEFORE per-company Tier-2 data (employee count, MVA registration, turnover) is layered on. Use this tool when an agent wants to answer 'what does an AS owe?' or 'what are the baseline filings for an Enkeltpersonforetak?' without naming a specific company. Each obligation in the response carries a tier_2_required boolean — true means the rule engine needs commercial data to know whether the obligation actually applies to a SPECIFIC company (e.g. MVA / VAT registration only applies above the NOK 50,000 turnover threshold), false means the obligation applies unconditionally to every entity of that type. Common Norwegian regulatory concepts surfaced in the response include MVA / VAT (Merverdiavgift, Norwegian value-added tax), A-melding (the monthly employer payroll report consolidating tax + payroll-tax + pension data), Aksjonærregisteret (shareholder register filing), and Årsregnskap (annual accounts). Input: { entity_type } from the closed enum AS (aksjeselskap) / ENK (enkeltpersonforetak) / ANS (ansvarlig selskap) / DA (delt ansvar) / NUF (norskregistrert utenlandsk foretak). For per-company evaluation that DOES layer on commercial data, call get_company_obligations. Failure modes the agent must handle: VALIDATION_FAILED on an unknown entity_type (the enum is closed; there is no 'OTHER' fallback); SCOPE_INSUFFICIENT if the API key is not scoped read:rulebook; UPSTREAM_TIMEOUT on rulebook latency. For a specific company's evaluated obligations rather than the entity-type template, use get_company_obligations instead. Endpoint: https://www.apier.no/api/mcp
- get_exchange_rate (Norges Bank exchange rate) - Fetch the most recent Norges Bank (Norway's central bank, Norges Bank in Norwegian — the official issuer of the krone) exchange-rate reference for a currency against NOK. Norges Bank publishes the daily NOK reference rate at ~16:00 Oslo time and Norwegian tax + accounting authorities (Skatteetaten / Norwegian Tax Administration; Regnskapsloven / Accounting Act) accept it as the canonical conversion benchmark for obligations denominated in foreign currency — including annual accounts (Årsregnskap), MVA / VAT (Merverdiavgift) filings on cross-border transactions, and dividend reporting. Use this tool whenever an agent needs an authoritative NOK rate for a regulatory calculation. The response includes the rate value, the date the rate is valid for (Norges Bank publishes weekday rates only; weekends + Norwegian public holidays return the prior business day's rate), and the source attribution so the agent can cite it back to a user. This is one of the few tools that does NOT depend on Norwegian-company input; it is the currency-of-record lookup. Input: { base, quote, date? } — base and quote are ISO 4217 three-letter currency codes (case-insensitive, exactly 3 letters), and rates are NOK-ANCHORED: exactly one of base/quote MUST be 'NOK', the other side any currency Norges Bank publishes. A pair without a NOK side (e.g. EUR/USD) is rejected client-side as UNSUPPORTED_CURRENCY_PAIR before any request is sent — fetch both NOK legs and derive the cross rate yourself if you need one. date is an optional ISO 8601 day (YYYY-MM-DD); omit it for the latest published rate. Failure modes the agent must handle: VALIDATION_FAILED on a non-ISO-4217 input; UNSUPPORTED_CURRENCY_PAIR when neither or both sides are NOK; INVALID_DATE on a malformed or future date; UPSTREAM_TIMEOUT if Norges Bank is slow; NO_RATE_AVAILABLE (404) if Norges Bank does not publish the currency; SCOPE_INSUFFICIENT if the API key is not scoped read:norgesbank. For compliance obligations or filing deadlines rather than a currency rate, use get_company_summary instead. Endpoint: https://www.apier.no/api/mcp
- list_acting_capacity (Acting capacity for a person) - Resolve every Norwegian regulatory action a person is currently authorised to perform on behalf of a specific organisation. The lookup combines the actor's Altinn role assignments (DAGL — Daglig leder / managing director, LEDE — Styreleder / board chair, MEDL — Styremedlem / board member, NESTL — Nestleder / vice chair, INNH — Innehaver / sole proprietor, REGN — Regnskapsfører / accountant, REVI — Revisor / auditor) with a conservative role-to-action map maintained in `src/lib/altinn/role-action-map.ts`. The response returns the raw Altinn role list AND the derived action tokens an agent may safely pass to /v1/actions/execute downstream, with a per-action `legal_reference` citation pinned to lovdata.no (all 10 entries verified 2026-05-16 — aksjeloven, skatteforvaltningsloven, regnskapsførerloven, revisorloven). Inputs are an 11-digit Norwegian fødselsnummer or D-nummer (which is HMAC-SHA-256 hashed via RECEIPT_HMAC_SECRET before any storage; the raw value is NEVER persisted, NEVER logged, and NEVER returned in the response — the response echoes only `actor.fnr_hmac`) plus the 9-digit Norwegian organisasjonsnummer of the represented entity. Results are cached for up to 1 hour in `resolved_permissions` so repeat lookups within the cache window do not re-hit Altinn; `metadata.cached === true` indicates a cache hit. Required scope: `read:altinn`. PR-MCP-02b: when ALTINN_MODE=sandbox, returns deterministic fixture payloads for OEM evaluation; metadata.data_sources tags as 'altinn-sandbox' and _meta.is_sandbox=true. For your own consumer's delegation snapshot on the org, use check_authorization instead. Endpoint: https://www.apier.no/api/mcp
- get_company_profile (Company profile (Brønnøysund)) - Resolve a Norwegian organisasjonsnummer (9-digit org number) into a structured company profile sourced from Brønnøysund Enhetsregisteret (data.brreg.no). The response carries the company's display name, organisational form (e.g. AS = Aksjeselskap, ENK = Enkeltpersonforetak, ASA = Allmennaksjeselskap), Norwegian industry codes (NACE) with descriptions, the registered street address (forretningsadresse) and any separate business address (postadresse), the Enhetsregisteret registration date, the agent-facing status enum (`active` for operating entities, `dissolved` for entities that have been deleted, gone bankrupt, are under voluntary or forced liquidation), the dissolution date when known (slettedato), the MVA-registered flag (registrertIMvaregisteret), and a deduplicated list of role codes assigned to natural persons (DAGL, LEDE, MEDL, NESTL, INNH, etc.). Per Norwegian data minimisation rules (CLAUDE.md Rule 11), the response deliberately CARRIES role codes ONLY — never personal identifiers (fødselsdato, personnummer, home address, email, phone). The data is Tier 1 public infrastructure under NLOD (Norsk lisens for offentlige data); no delegation is required. Cache TTL is 24 hours (matches Brreg's daily publish cadence); if Brreg is unavailable, the response may serve a stale cached row up to 7 days old with metadata.stale=true and metadata.staleness_seconds populated. Required scope: `read:brreg`. Raw-HTTP fallback note: the backing REST route is POST /api/v1/brreg/company-profile (the org number goes in the JSON body), whereas the sibling company tools are GET /api/v1/company/{org}/… — a known method inconsistency, so do not assume GET when calling this endpoint directly over HTTP. For an evaluated compliance verdict rather than the raw registry profile, use get_company_summary instead. Endpoint: https://www.apier.no/api/mcp
- check_authorization (Authorisation snapshot) - Return the authorisation snapshot for the calling consumer's delegation on a Norwegian organisation. The response carries: the current `status` enum (`full` / `partial` / `none`); the `missing_scopes` array (Altinn / Maskinporten scope tokens the delegation lacks — empty when status=`full`); the `granted_scopes` array (the scope tokens the delegation already covers); and the `delegation_chain` (ordered list of System-User and consumer-id breadcrumbs the auth gateway walked to derive the verdict). Agents that need to check whether a SPECIFIC regulatory action (submit_mva, file_a_melding, etc.) is permitted should fetch the snapshot via this tool and compare `granted_scopes` to the scopes their target action requires — the rulebook's action→scope mapping is in the openapi.json `x-action-scopes` extension. The evaluation always runs against the calling consumer — there is no per-action and no per-actor input at v1. (The PR-070-tools brief's proposed `action` and `actor_national_id` parameters were dropped to match the route exactly. The underlying /v1/auth/permissions/{org} route does not parse either today; both will land in future PRs once the route adds the parameters AND a canonical fnr validator + shared hashFnr helper extract from PR-MCP-02's inline implementation per SA-001 §3.) Failure modes: SCOPE_INSUFFICIENT if the API key is not scoped read:altinn; VALIDATION_FAILED on shape or mod-11. The underlying endpoint is always a 200 — when no delegation exists for the (consumer, org) pair the verdict is `status: "none"` with the missing scopes enumerated, NOT a 404. Required scope: `read:altinn`. For which actions a SPECIFIC person may perform for the org, use list_acting_capacity instead. Endpoint: https://www.apier.no/api/mcp
- get_company_context (Company registry facts) - Retrieve the structured Brønnøysund identity slice for a Norwegian organisation by its 9-digit organisasjonsnummer (organisation number, the public ID issued by the Brønnøysund Register Centre / Enhetsregisteret — Central Register of Legal Entities). The response carries the canonical registry facts: legal name; entity type / organisasjonsform (e.g. AS / Aksjeselskap (limited company), ENK / Enkeltpersonforetak (sole proprietorship), NUF / Norskregistrert utenlandsk foretak (Norwegian branch of a foreign company), ASA / Allmennaksjeselskap (public limited company)); the Norwegian Industrial Classification (NACE) industry codes assigned to the entity; the registered street and postal addresses; the Enhetsregisteret incorporation date; the dissolution date when the entity has been deregistered (`slettedato`); and the role-holder summary (signaturrett / signing-authority and prokura / power-of-procuration role codes assigned to natural persons — codes only, never personal identifiers per the data-minimisation policy). Cache window is 24 hours; cache hits are served from the canonical companies table without re-hitting Brønnøysund. Choose this tool when an agent needs the identity slice ONLY without the rule-engine compliance verdict; pair with get_company_obligations or get_company_deadlines for the regulatory layer. Input: { org_number } as 9 digits passing the Brønnøysund MOD-11 control-digit check. Failure modes: 404 NOT_FOUND if the org_number is well-formed but unknown to Brønnøysund; SCOPE_INSUFFICIENT if the API key is not scoped read:brreg; UPSTREAM_TIMEOUT on Brønnøysund latency; VALIDATION_FAILED on shape or mod-11 failure. Required scope: `read:brreg`. For a compliance verdict (obligations + deadlines) rather than registry identity, use get_company_summary instead. No API key? Self-serve in the sandbox: authenticate tools/call with `Authorization: Bearer apier_sandbox_test_<suffix>` (ALWAYS append a unique random suffix, e.g. a fresh UUID, for session isolation) and this tool answers from deterministic synthetic fixtures with `_meta.is_sandbox: true` — use the reserved MOD-11-valid sandbox org numbers from GET /api/v1/sandbox/fixtures (e.g. 999660088). Endpoint: https://www.apier.no/api/mcp
- get_company_deadlines (Company filing calendar) - Compute the upcoming Norwegian regulatory filing calendar for a specific organisation, looking horizon_months into the future. The response is one entry per (obligation, period) pair, each carrying: a stable obligation_id matching get_company_obligations; the due_date as an ISO 8601 timestamp in Europe/Oslo (DST-aware — the engine never hardcodes +01:00 / +02:00 and CET ↔ CEST transitions do not shift due dates by a calendar day); the legal_reference citation; a recurring boolean indicating whether the deadline repeats on a fixed cadence; and a business_day_adjusted boolean indicating whether the engine moved the date to the next Norwegian business day to land off a weekend or public holiday. Choose this tool when the agent needs the calendar view (when does the next MVA / A-melding / Årsregnskap filing land?) rather than the obligation menu. Pair with get_company_obligations to learn what each obligation_id requires. Inputs: { org_number } as 9 digits passing the Brønnøysund MOD-11 control-digit check, plus an optional horizon_months between 1 and 60 (defaults to the endpoint's standard horizon — matches the route's own horizonMonthsSchema clamp). Determinism (Rule 9): same input + same rulebook_version produces a byte-identical calendar. Failure modes: 404 NOT_FOUND for unknown org_numbers; SCOPE_INSUFFICIENT if the API key is not scoped read:brreg; VALIDATION_FAILED on shape, mod-11, or out-of-range horizon (boundary [1, 60] matching the underlying route — round-7 polish widened from [1, 24] so the tool no longer refuses horizons the REST surface accepts). Required scope: `read:brreg` (matches the underlying /v1/company/{org}/deadlines route's `SCOPE_REQUIREMENTS` binding — round-7 polish corrected an earlier `read:rulebook` declaration that would have produced SCOPE_INSUFFICIENT at runtime since the route checks read:brreg). For the per-obligation compliance verdict rather than the date calendar, use get_company_obligations instead. No API key? Self-serve in the sandbox: authenticate tools/call with `Authorization: Bearer apier_sandbox_test_<suffix>` (ALWAYS append a unique random suffix, e.g. a fresh UUID, for session isolation) and this tool answers from deterministic synthetic fixtures with `_meta.is_sandbox: true` — use the reserved MOD-11-valid sandbox org numbers from GET /api/v1/sandbox/fixtures (e.g. 999660088). Endpoint: https://www.apier.no/api/mcp
- get_company_obligations (Company regulatory obligations) - Evaluate the Apier Rulebook for a Norwegian organisation and return every applicable regulatory obligation with its current state and the legal reference it derives from. The response is one entry per obligation, each carrying: a stable obligation_id (e.g. `MVA_FILING_BIMONTHLY`, `A_MELDING_MONTHLY`, `ARSREGNSKAP_FILING`); the legal_reference citation pinning the obligation to lovdata.no (`Skatteforvaltningsloven § 8-3`, `Aksjeloven § 7-6`, etc.); the current state enum (`filed` / `pending` / `in_progress` / `failed` / `overdue` / `unknown`); the bokmål description (description_nb) inherited byte-for-byte from the Rulebook — agents must NEVER re-translate this string; and the freshness window the evaluation is valid until. Determinism (Rule 9): the same org_number plus rulebook_version always produces a byte-identical obligation list. The evaluation always runs against the CURRENT instant — there is no historical-instant input at v1. (The underlying /v1/company/{org}/obligations route does not parse `?as_of=` today; the PR-070-tools brief's proposed `as_of` parameter was dropped to match the route exactly. Historical-instant evaluation lands in a future PR once the route adds the parameter.) Choose this tool when the agent needs the full obligation menu rather than upcoming deadlines (use get_company_deadlines for the calendar view). Failure modes: 404 NOT_FOUND for unknown org_numbers; SCOPE_INSUFFICIENT if the API key is not scoped read:brreg; VALIDATION_FAILED on shape or mod-11. Required scope: `read:brreg` (matches the underlying /v1/company/{org}/obligations route's `SCOPE_REQUIREMENTS` binding — round-7 polish corrected an earlier `read:rulebook` declaration that would have produced SCOPE_INSUFFICIENT at runtime since the route checks read:brreg). For the upcoming filing calendar alone, use get_company_deadlines instead. No API key? Self-serve in the sandbox: authenticate tools/call with `Authorization: Bearer apier_sandbox_test_<suffix>` (ALWAYS append a unique random suffix, e.g. a fresh UUID, for session isolation) and this tool answers from deterministic synthetic fixtures with `_meta.is_sandbox: true` — use the reserved MOD-11-valid sandbox org numbers from GET /api/v1/sandbox/fixtures (e.g. 999660088). Endpoint: https://www.apier.no/api/mcp
- get_public_deadlines (Norwegian filing calendar) - Compute the universal Norwegian regulatory filing calendar — the set of deadlines that apply to every Norwegian business of the covered categories (MVA, A-melding, Årsregnskap), independent of any specific organisation. The response is the calendar for a single Europe/Oslo calendar year, one entry per (obligation, period) pair with: a stable obligation_id (e.g. `MVA_FILING_BIMONTHLY`, `A_MELDING_MONTHLY`, `ARSREGNSKAP_FILING`); the due_date as an ISO 8601 timestamp in Europe/Oslo (DST-aware — CET ↔ CEST transitions never shift due dates by a calendar day); the legal_reference citation pinning the deadline to lovdata.no; a recurring boolean; and a business_day_adjusted boolean. Choose this tool when an agent needs the universal calendar (questions like 'when is the next MVA filing deadline' that don't depend on a specific org_number) — it requires no organisasjonsnummer and no scope check beyond rulebook read access. Input: optional `year` (Europe/Oslo calendar year, integer between 2020 and 2100; defaults to the current Oslo year at the endpoint when omitted — a request at 23:30 UTC on 31 Dec is already 00:30 of the next year in Oslo during CET, and the route's default uses the Oslo wall-clock not UTC). Determinism (Rule 9): same input + same rulebook_version produces a byte-identical calendar. Failure modes: SCOPE_INSUFFICIENT if the API key is not scoped read:rulebook; VALIDATION_FAILED on year shape (non-integer, outside 2020–2100; the 2020 lower bound matches the underlying /v1/public/deadlines route's MIN_YEAR — older years aren't in the Rulebook's coverage window). Required scope: `read:rulebook`. For a specific company's filing calendar rather than the universal one, use get_company_deadlines instead. Endpoint: https://www.apier.no/api/mcp
- validate_action (Validate a regulatory action (dry-run)) - Run the Apier dry-run validator against a proposed regulatory action without producing ANY upstream side effect — no Maskinporten call, no Altinn / Skatteetaten / NAV submission. The response is the structured verdict from `src/lib/actions/dry-run.ts` carrying: the five check slots (`company_exists`, `system_user_authorised`, `scopes_delegated`, `deadline_in_future`, `data_format_valid`) each with pass / fail / skipped status and a human-readable reason; the overall valid boolean; and the DRY_RUN_DISCLAIMER constant — a passing dry-run is NOT a guarantee of upstream success, only a strong-but-not-guaranteed signal that the local prerequisites are satisfied. The dry-run response also echoes `would_be_payload` — the exact upstream-shaped payload a live execute would submit — plus a `preview_notice`, so you can preview precisely what would be filed without submitting anything. Checks short-circuit deterministically: `scopes_delegated` is skipped when `system_user_authorised` fails (no delegation to inspect); each skipped check carries an explanation. Use this tool BEFORE calling the live execute path to catch missing delegations, expired scopes, deadline misses, and payload-shape errors with zero upstream cost. Inputs match the underlying /v1/actions/execute body schema exactly: { org_number, action_type, period, payload }. action_type is the closed enum `mva_melding` (VAT return) | `a_melding` (employer report). period encoding depends on action_type — for mva_melding accept `YYYY-T1..T6` (bimonthly), `YYYY-A` (annual), or `YYYY-MM` (monthly); for a_melding only `YYYY-MM`. payload is the upstream-shaped JSON for the action; the per-action discriminated Zod (in `src/lib/actions/payload-schemas.ts`) owns shape validation — this tool only caps size at 64 KiB UTF-8 bytes (PAYLOAD_TOO_LARGE on exceedance). Failure modes: SCOPE_INSUFFICIENT if the API key is not scoped read:actions; VALIDATION_FAILED on shape / mod-11 / action_type enum / period-regex / payload-size; the dry-run validator itself NEVER throws — every failed check is reported via valid=false plus the breakdown fields. Required scope: `read:actions` (matches the underlying /v1/actions/execute endpoint — dry-run shares the live-execute scope vocabulary). To actually file a (sandbox) VAT return rather than dry-run-validate, use submit_vat_return instead. Endpoint: https://www.apier.no/api/mcp
- explain_compliance_error (Explain a compliance error) - Resolve a structured Apier compliance error code into a Norwegian-bokmål Explanation envelope sourced from the Apier Compliance Explainer (PR-049). The response carries a one-line summary, a 1–3 sentence why, an ordered list of fix_steps, an optional Apier / Altinn / Skatteetaten / Brønnøysund relevant documentation link, an optional Lovdata-style legal_basis citation when the error maps to a concrete regulatory provision, 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). Errors agents can resolve themselves (VALIDATION_FAILED, RATE_LIMIT_EXCEEDED, NOT_FOUND, IDEMPOTENCY_KEY_MISMATCH, IDEMPOTENCY_IN_PROGRESS, UPSTREAM_UNAVAILABLE) ship `handover: null`. The full catalogue of supported error codes mirrors `EXPLAINER_ERROR_CODES` (33 codes today across auth, validation, scope, upstream, idempotency, action-execute, government, and reliability domains); pass any code an Apier endpoint returned in an error envelope. The optional `context` object carries placeholder values (org_number, role, scope, field, upstream_system) that the explainer interpolates into the bokmål text — missing values fall back to a Norwegian 'ukjent <noun>' rather than leaking placeholder syntax. Required scope: `read:rulebook`. For a company's live obligations rather than an error explanation, use get_company_obligations instead. No API key? Self-serve in the sandbox: authenticate tools/call with `Authorization: Bearer apier_sandbox_test_<suffix>` (ALWAYS append a unique random suffix, e.g. a fresh UUID, for session isolation) and this tool answers from deterministic synthetic fixtures with `_meta.is_sandbox: true` — use the reserved MOD-11-valid sandbox org numbers from GET /api/v1/sandbox/fixtures (e.g. 999660088). Endpoint: https://www.apier.no/api/mcp
- search_companies (Search companies by name) - Resolve a Norwegian company NAME to its 9-digit organisasjonsnummer (organisation number). Use this as your FIRST call whenever you have a company's name but NOT its org_number — every other company tool (get_company_summary, get_company_context, get_company_obligations, get_company_deadlines) requires the 9-digit number up front, so guessing a MOD-11-valid number risks hitting the wrong company. This tool searches Brønnøysund's public Enhetsregisteret (Central Register of Legal Entities) by name and returns a deliberately token-efficient candidate list: up to ten matches, five fields each — name, org_number, org_form (AS / ENK / NUF …), municipality, and registry status (active / bankrupt / liquidating / forced_liquidation / deleted) — never the full registry payload. Follow-up pattern: read the candidates, pick the org_number of the right company (use org_form, municipality, and status to disambiguate — skip a deleted or bankrupt match unless you meant it), then call get_company_summary or get_company_context with that org_number. Input: { name } as 2–100 characters (trimmed; æ/ø/å supported). Guidance: if the search returns NOT_FOUND, broaden the name — use fewer or more distinctive words and drop the legal form (search `Nordic Widgets`, not `Nordic Widgets AS`); if several candidates look alike, prefer the active one in the expected municipality. Failure modes the agent must handle: VALIDATION_FAILED on a name shorter than 2 or longer than 100 characters; NOT_FOUND when nothing matches (broaden and retry, do not loop on the same name); SCOPE_INSUFFICIENT if the API key is not scoped read:brreg; UPSTREAM_TIMEOUT or UPSTREAM_UNAVAILABLE if Brønnøysund is slow or unreachable (retry after a short backoff). Endpoint: https://www.apier.no/api/mcp
- get_company_verification (Company verification verdict) - Get the deterministic verification verdict for a Norwegian organisation by its 9-digit organisasjonsnummer (organisation number, the public ID issued by the Brønnøysund Register Centre / Enhetsregisteret). Use this for a fast go / no-go trust check before acting on a company's behalf. The verdict is reduced from the SAME Tier 1 Brønnøysund data as get_company_context (no separate fetch) and keys ONLY off two facts: whether the entity is active, and whether signing authority — signaturrett, power of procuration (prokura), or a sole-proprietor innehaver (who legally signs alone for an ENK) — is visible in the open role data. The `verification_status` values: `pass` (active AND a signing-authority holder is visible), `fail` (NOT active — a bankrupt (konkurs), under-liquidation (under avvikling), or dissolved / compulsorily-dissolved (oppløst / tvangsoppløst) company reports a non-active Brønnøysund status and therefore verdicts `fail`), and `unknown` (the registry status is indeterminate, OR the company is active but no signing authority is visible in the open role data — the register routinely omits signing arrangements, so the verdict never claims an absence it cannot see; a human should confirm who can bind the company). `warn` remains in the vocabulary for contract stability but is not emitted today. Alongside the verdict you get seven signals — is_active, not_bankrupt, not_under_dissolution, not_forcibly_dissolved, has_signing_authority_defined, has_filed_annual_accounts, mva_registered — each `true` / `false` / `null` (`null` means genuinely unknown from the open registries, NEVER a silent `false`). These distress / MVA / filing signals are surfaced for TRANSPARENCY only and NEVER change the verdict. You also get a Norwegian-bokmål `summary`, the `signing_authority_summary`, `last_accounts_year`, the registry identity echo (name, entity_type, nace_codes, municipality), the `data_sources` provenance tags, and a `verification_timestamp`. Deterministic: same org_number + same rulebook version → byte-identical verdict. Call get_company_context for the raw identity slice, get_company_summary for the obligation-and-deadline compliance layer, or get_company_obligations for per-obligation drill-down. Input: { org_number } as 9 digits passing the Brønnøysund MOD-11 control-digit check. Failure modes the agent must handle: 404 NOT_FOUND if the org_number is well-formed but unknown to Brønnøysund; SCOPE_INSUFFICIENT if the API key is not scoped read:brreg; UPSTREAM_UNAVAILABLE if Brønnøysund is unreachable with no serviceable cache; VALIDATION_FAILED on a non-9-digit or mod-11-failing input. Required scope: `read:brreg`. No API key? Self-serve in the sandbox: authenticate tools/call with `Authorization: Bearer apier_sandbox_test_<suffix>` (ALWAYS append a unique random suffix, e.g. a fresh UUID, for session isolation) and this tool answers from deterministic synthetic fixtures with `_meta.is_sandbox: true` — use the reserved MOD-11-valid sandbox org numbers from GET /api/v1/sandbox/fixtures (e.g. 999660088). Endpoint: https://www.apier.no/api/mcp
- get_company_authority (Company signing-authority resolver) - Use this to answer "who can legally sign for this Norwegian company, and how?" before acting on its behalf. Given a 9-digit organisasjonsnummer (organisation number) it returns a deterministic signing-authority classification — `sole` (one role signs alone), `joint` (several roles must sign together), `by_role` (multiple alternative combinations; the valid path depends on which role you hold), `prokura_only` (no signaturrett, but prokura is defined), `no_authority` (neither registered), or `unknown` (the signing rule could not be determined). The answer is normalised from the open Brønnøysund Fullmakttjenesten signing combinations (Brønnøysund applies the statutory signing rules server-side and returns `signeringsKombinasjon`; Apier buckets that output — it does NOT re-encode statute) combined with the signaturrett / prokura role-holders already loaded from /roller. `data.combinations[]` carries each combination's Brønnøysund `kombinasjons_id`, a human `description`, and its role codes; the holders are listed once on `data.signaturrett_holders` / `data.prokura_holders`. `data.kombinasjon_available` is `false` when the live Fullmakt lookup was unreachable, in which case the classification degrades to the /roller holders plus any prokura combinations still fetched. No legal citation is asserted. Input: { org_number } as 9 digits passing the Brønnøysund MOD-11 control-digit check. Failure modes the agent must handle: 404 not_found for a well-formed but unknown org_number; SCOPE_INSUFFICIENT if the key is not scoped read:brreg; UPSTREAM_UNAVAILABLE if Brønnøysund is unreachable and no serviceable cache exists; VALIDATION_FAILED on a non-9-digit or mod-11-failing input. For a fast go/no-go trust verdict rather than the full signing breakdown, use get_company_verification instead. No API key? Self-serve in the sandbox: authenticate tools/call with `Authorization: Bearer apier_sandbox_test_<suffix>` (ALWAYS append a unique random suffix, e.g. a fresh UUID, for session isolation) and this tool answers from deterministic synthetic fixtures with `_meta.is_sandbox: true` — use the reserved MOD-11-valid sandbox org numbers from GET /api/v1/sandbox/fixtures (e.g. 999660088). Endpoint: https://www.apier.no/api/mcp
- get_company_accounts (Company annual accounts snapshot) - Use this for a current-snapshot read of a Norwegian company's annual accounts (årsregnskap) from the OPEN Regnskapsregisteret tier. Given a 9-digit organisasjonsnummer (organisation number) it returns `has_filed_annual_accounts` (a tri-state — `true` = at least one annual-accounts record on file, `false` = the register authoritatively reports none for a covered entity, `null` = unknown / the open tier does not cover the entity, e.g. banks & insurers filing via a separate oppstillingsplan), `last_accounts_year` (the most-recent accounting year in Europe/Oslo), and that year's minimal `key_figures`: currency, presentation basis, total assets, annual result, operating result, and total equity + liabilities. `currency` is always surfaced so the monetary figures are never silently read as NOK — large issuers report in USD/EUR. The upstream read never throws: an unreachable register, a 404, or any non-200 all degrade to the tri-state `null` (unknown), never to a fabricated `false`. v1 is current-snapshot only — no multi-year history and no closed/authenticated tier. Input: { org_number } as 9 digits passing the Brønnøysund MOD-11 control-digit check. Failure modes the agent must handle: SCOPE_INSUFFICIENT if the key is not scoped read:brreg; VALIDATION_FAILED on a non-9-digit or mod-11-failing input. Note a well-formed but unknown org_number does NOT 404 here — it returns 200 with `has_filed_annual_accounts: null`. For the filing status as one input to a go/no-go verdict, use get_company_verification; for the registry identity, use get_company_context. No API key? Self-serve in the sandbox: authenticate tools/call with `Authorization: Bearer apier_sandbox_test_<suffix>` (ALWAYS append a unique random suffix, e.g. a fresh UUID, for session isolation) and this tool answers from deterministic synthetic fixtures with `_meta.is_sandbox: true` — use the reserved MOD-11-valid sandbox org numbers from GET /api/v1/sandbox/fixtures (e.g. 999660088). Endpoint: https://www.apier.no/api/mcp
- get_company_filing_history (Company filing history (Altinn) + Apier audit trail) - Use this to reconcile a Norwegian company's Altinn 3 filing history against the filings YOUR consumer submitted through Apier — the accountant/auditor reconciliation wedge. Given a 9-digit organisasjonsnummer (organisation number) it returns the org's Altinn filing instances (Mva-melding, A-melding, Skattemelding, …) — form code, title, receiving agency, submitted_at (Europe/Oslo), status, and instance id — each PAIRED with its Apier audit-log entry where one exists: `filed_via_apier` is true with an `apier_record` (audit_log id + correlation_id) for filings Apier submitted, false for filings made directly in Altinn. Pairing is best-effort — a transient audit-read failure degrades every filing to `filed_via_apier: false` rather than failing the call. Offset-paginated via optional { limit } (1–100, default 20) and { offset } (≥ 0, default 0); the response carries a `pagination` block with `has_more` and `next_offset`. An org with no filings returns 200 with an empty list, never a 404. This is a MOCK-GATED build: deterministic synthetic fixtures today; the live Altinn path is dormant until the `altinn:instances.read` Maskinporten scope is approved. Input: { org_number, limit?, offset? }. Failure modes the agent must handle: SCOPE_INSUFFICIENT if the key is not scoped read:altinn; AUTH_NO_DELEGATION in live mode when the org has not delegated to your system user; VALIDATION_FAILED on a non-9-digit or mod-11-failing org_number or an out-of-range limit/offset. For a company's upcoming filing deadlines rather than its past filings, use get_company_deadlines instead. No API key? Self-serve in the sandbox: authenticate tools/call with `Authorization: Bearer apier_sandbox_test_<suffix>` (ALWAYS append a unique random suffix, e.g. a fresh UUID, for session isolation) and this tool answers from deterministic synthetic fixtures with `_meta.is_sandbox: true` — use the reserved MOD-11-valid sandbox org numbers from GET /api/v1/sandbox/fixtures (e.g. 999660088). Endpoint: https://www.apier.no/api/mcp
- list_changes (Query the cross-source change archive) - Use this to read Apier's cross-source change archive — every detected created / updated / deleted event across the upstreams Apier polls: Brønnøysund ingestion plus the multi-source pollers for Altinn schemas, DigDir policies, and Norges Bank rates. It answers "what changed, where, and when?" so an agent can drive an incremental sync instead of re-fetching whole entities. Filter by { source } (brreg / altinn / digdir / norges_bank …), { entity_type }, { entity_id } (e.g. a specific org number), { change_type } (created / updated / deleted), and a { from }–{ to } detected_at date range (ISO 8601 with a timezone offset — bare `Z` or `+02:00`, never a bare local time; `from` must be ≤ `to`). Results are keyset-paginated newest-first: pass { limit } (1–500, default 50) and carry the response's `next_cursor` back into { cursor } verbatim for the next page — cursors are HMAC-signed, so constructing or editing one is rejected as CURSOR_INVALID. The public projection strips the internal correlation_id but preserves `source_snapshot_id` (a consumer-facing receipt join). Input: { source?, entity_type?, entity_id?, change_type?, from?, to?, limit?, cursor? }. Failure modes the agent must handle: SCOPE_INSUFFICIENT if the key is not scoped read:changes; VALIDATION_FAILED on a malformed date, an out-of-range limit, or from > to; CURSOR_INVALID if the cursor was tampered or expired (start over without a cursor). This tool has no sandbox mirror — under the sandbox bearer it returns SANDBOX_TOOL_UNAVAILABLE; call it with a real read:changes key. Endpoint: https://www.apier.no/api/mcp
- get_altinn_migration_guidance (Altinn 2 → Altinn 3 migration guidance) - Use this to 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 now serves remediation for any integration still on Altinn 2 — not pre-deadline planning. Pass an Altinn 2 code in { altinn2_code } (alphanumeric, 1–10 characters, e.g. A0208) to resolve a single mapping, or omit it to retrieve the entire migration map. Every response also carries the deprecation status computed in Europe/Oslo — `deprecation_deadline` (the absolute 23:59:59 Oslo instant on 19 June 2026), `days_remaining` (whole Oslo calendar days, floored at 0 once the deadline passes — 0 now that it has, never negative), and `deadline_passed` (now `true`) — so an agent can sequence its migration work without doing the timezone math itself. Each map entry ships a `verified` flag: `true` means the mapping has been cross-checked against DigDir's authoritative documentation, `false` means it is a convenience reference only — gate any production migration action on `verified === true` and treat unverified entries as hints, not instructions. The underlying data is a deterministic static map (DigDir-sourced); no government system is contacted at call time, so the answer is stable and cache-friendly. Input: { altinn2_code? }. Failure modes the agent must handle: 404 not_found when a supplied code is not in the map (omit the code to see every known entry); VALIDATION_FAILED (INVALID_CODE) on a non-alphanumeric or over-length code. This tool has no sandbox mirror — under the sandbox bearer it returns SANDBOX_TOOL_UNAVAILABLE. Endpoint: https://www.apier.no/api/mcp

## Resources
- apier://rulebook/deadlines - Norwegian filing calendar (versioned Rulebook) The universal Norwegian regulatory filing calendar for the current Oslo year, evaluated from the versioned Apier Rulebook. Carries `_meta.rulebook_version`. Public — no API key required. MIME type: application/json

## Prompts
- obligations_sweep - Obligations Sweep Sweep a Norwegian company's full regulatory position — registry identity, every applicable obligation with its current state, and the upcoming filing calendar — in one guided pass. Arguments: org_number
- prepare_vat_return - Prepare VAT return Prepare and dry-run a Norwegian VAT return (MVA-melding) for a company and period — verifying authorisation and prerequisites against the company's REAL state — BEFORE any binding submission. Produces no upstream side effect. Arguments: org_number, period

## Metadata
- Owner: no.apier
- Version: 2026.6.0
- Runtime: Streamable Http
- Transports: HTTP
- License: Not captured
- Language: Not captured
- Stars: Not captured
- Updated: Jun 6, 2026
- Source: https://registry.modelcontextprotocol.io