no.apier/mcp

skills: {'id': 'get_company_summary', 'name': 'get_company_summary', 'description': '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).', 'tags': [], 'examples': None, 'input_modes': None, 'output_modes': None}, {'id': 'get_public_obligations', 'name': 'get_public_obligations', 'description': "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 / ASA / ENK / DA / ANS / SAMVIRKE / STIFTELSE / NUF / OFFENTLIG. 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.", 'tags': [], 'examples': None, 'input_modes': None, 'output_modes': None}, {'id': 'get_exchange_rate', 'name': 'get_exchange_rate', 'description': "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.", 'tags': [], 'examples': None, 'input_modes': None, 'output_modes': None}, {'id': 'list_acting_capacity', 'name': 'list_acting_capacity', 'description': "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.", 'tags': [], 'examples': None, 'input_modes': None, 'output_modes': None}, {'id': 'get_company_profile', 'name': 'get_company_profile', 'description': "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.", 'tags': [], 'examples': None, 'input_modes': None, 'output_modes': None}, {'id': 'check_authorization', 'name': 'check_authorization', 'description': '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.', 'tags': [], 'examples': None, 'input_modes': None, 'output_modes': None}, {'id': 'get_company_context', 'name': 'get_company_context', 'description': '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).', 'tags': [], 'examples': None, 'input_modes': None, 'output_modes': None}, {'id': 'get_company_deadlines', 'name': 'get_company_deadlines', 'description': "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).", 'tags': [], 'examples': None, 'input_modes': None, 'output_modes': None}; uptime_30d 1.0%; p95 841.8ms; conformance: pass

How to connect

https://www.apier.no/api/mcp

curl -X POST https://www.apier.no/api/mcp \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}'