"Norwegian" matching MCP tools:

• firmaradar_start_aml_report

  Firmaradar

  Start generating an AML risk report ASYNCHRONOUSLY for a Norwegian company. Returns immediately with a report_id and status 'pending' — the report is built in the background. Poll `get_aml_report` with the report_id until status is 'done' (then read score/level/factors) or 'failed'. Use this instead of `get_aml_score` for large/complex ownership structures that may otherwise time out, or to start many screenings in parallel. Generates an auditable report stored for 60 months per Hvitvaskingsloven §35.

  Connector

• firmaradar_subscribe_nace

  Firmaradar

  Subscribe to industry (NACE) monitoring: when any Norwegian company in the chosen industry triggers a monitored event (new announcement, status change such as bankruptcy/dissolution, or ownership update), Firmaradar delivers a webhook to your URL. Use list_nace_codes first to resolve the exact code. A subscription on a parent code matches all child codes. Restrict `events` (e.g. ['status_changed']) and use geographic/size filters to cut volume in large industries, or pick a digest `aggregation_mode`. Idempotent — upserted on (user, nace_code), so re-subscribing the same code updates it. Requires a user whose plan has Firmaovervakning enabled. Call only when the user has asked to set up industry monitoring.

  Connector

• firmaradar_add_company_monitoring

  Firmaradar

  Add a Norwegian company (by 9-digit orgnr) to the user's company-monitoring list. The user is then alerted when announcements, status changes (bankruptcy/dissolution), ownership changes or new public grants are registered for that company. New targets monitor ALL announcement categories by default; keep ip_alerts=true (default) to also turn on IP-change alerts when the account has the IP-monitoring add-on, or set ip_alerts=false to skip them. 409 if already monitored (idempotent — no duplicate). 403 (monitoring_cap_reached) if the account's company has hit its per-company monitoring cap — tell the user to contact Firmaradar to expand it. Requires a user whose plan has Firmaovervakning enabled. Call only when the user has asked to monitor a specific company.

  Connector

• search_filings

  Nordic Financial MCP

  Search the Nordic financial database for company filings, press releases and macroeconomic summaries. Use this as the primary tool for any question about Nordic listed companies, markets or macro conditions. Do not use to retrieve a full document — results are chunked text excerpts; use parse_pdf_to_text for the full original document. Do not use for Swedish company registration data — use get_company_info instead. The database contains ~1 million vectors across four Nordic markets (NO/SE/DK/FI). COMPANY FILINGS Annual reports (XBRL/ESEF) and quarterly reports from ~1 500 listed companies across Oslo Børs, Nasdaq Stockholm, Nasdaq Helsinki, Nasdaq Copenhagen and First North markets. Covers 2020–present. Strong coverage for NO and SE; growing coverage for DK and FI. EXCHANGE ANNOUNCEMENTS & PRESS RELEASES Regulatory filings, exchange announcements and press releases from listed companies in NO, SE, DK and FI. Covers 2020–present. MACROECONOMIC SUMMARIES Quarterly macro summaries covering key indicators per country: Norway (NO): policy rate, FX rates, CPI, house prices, credit growth, electricity price, salmon price, GDP components Sweden (SE): policy rate, house price index, household credit Denmark (DK): policy rate, house price index, household loans, electricity price Finland (FI): house price index, household debt-to-income ratio, electricity price Use report_type='macro_summary' and country='NO'/'SE'/'DK'/'FI' to filter. Use fiscal_year and a quarter reference in your query, e.g. "Norwegian housing market Q1 2024". Args: query: What you are looking for, e.g. 'net interest margin outlook', 'salmon price Q3', 'dividend policy', 'fleet utilization', 'Norwegian housing market 2024 Q1', 'Swedish policy rate inflation 2023' ticker: Optional — filter by company ticker, e.g. 'SALM', 'EQNR', 'NDA' fiscal_year: Optional — filter by year, e.g. 2024 report_type: Optional — one of: 'annual_report' – Nordic XBRL/ESEF annual reports 'quarterly_report' – Quarterly/interim reports 'press_release' – Exchange announcements and press releases 'macro_summary' – Quarterly macroeconomic summaries sector: Optional — filter by sector: 'seafood' – seafood companies 'energy' – energy / oil & gas 'shipping' – shipping companies country: Optional — filter by country code: 'NO', 'SE', 'DK' or 'FI' limit: Number of results after reranking (default 5, max 20) Returns: List of relevant text excerpts with metadata, reranked by relevance. Each result includes rerank_score, hybrid_score, vector_score, company, ticker, country, fiscal_year, report_type, period, filing_date and the full text chunk. Returns an empty list if no relevant results are found or if the Qdrant database is temporarily unreachable.

  Connector

• get_company_summary

  mcp

  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). Cost: 50 øre (NOK 0.50) per call, debited from the API key's prepaid credit balance when credit enforcement is live. Current prices for every metered tool are discoverable without authentication via the get_pricing tool (or GET /api/v1/pricing for REST clients). A call with insufficient balance returns INSUFFICIENT_CREDITS with top_up_url, balance_ore and cost_ore for self-recovery; while enforcement is live, every successful metered call reports its remaining balance on metadata.credits.

  Connector

• get_public_obligations

  mcp

  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.

  Connector

• get_exchange_rate

  mcp

  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.

  Connector

• get_company_profile

  mcp

  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. Cost: 50 øre (NOK 0.50) per call, debited from the API key's prepaid credit balance when credit enforcement is live. Current prices for every metered tool are discoverable without authentication via the get_pricing tool (or GET /api/v1/pricing for REST clients). A call with insufficient balance returns INSUFFICIENT_CREDITS with top_up_url, balance_ore and cost_ore for self-recovery; while enforcement is live, every successful metered call reports its remaining balance on metadata.credits.

  Connector

• get_public_deadlines

  mcp

  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.

  Connector

• explain_compliance_error

  mcp

  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` (40 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).

  Connector

• request_fullmakt

  mcp

  Broker a fullmakt — a legally-grounded, scoped, revocable company→agent authority delegated through an Altinn systembruker (system user). Use this to turn an agent IDENTITY (an agent principal you created via PR-A1) into an ACTOR that may act on behalf of a specific Norwegian company. Given the agent principal, a 9-digit customer org_number, and the Altinn scopes to carry, the tool brokers a systembruker delegation, persists it, and binds the returned system_user_id onto the principal (write-once — a `pending` principal becomes `active`). Altinn returns a `delegation_url` the company's signing authority must approve before the delegation is usable, so a fresh delegation typically starts `pending`. The response `data` carries system_user_id, status, scopes, valid_until, delegation_url, the echoed label, an agent_principal snapshot, and a `warnings[]` array that is ALWAYS present (empty on the clean path): a non-empty array on a 201 means the delegation EXISTS upstream but a local follow-up write degraded — reconcile, never blind-retry. Inputs: { agent_principal_id (uuid, one of YOUR OWN principals), org_number (9 digits), scopes (non-empty string[]), validity_days? (1–3650), label? }. Failure modes: FULLMAKT_PRINCIPAL_NOT_FOUND (404 — wrong id or another consumer's principal; the two are deliberately indistinguishable), FULLMAKT_PRINCIPAL_NOT_ELIGIBLE (409 — a revoked/suspended principal cannot request), FULLMAKT_UPSTREAM_FAILED (502 — Altinn brokering failed; on the ack-unconfirmed variant do NOT blind-retry, reconcile in Altinn), SCOPE_INSUFFICIENT if the key is not scoped read:altinn, VALIDATION_FAILED on a malformed input. Required scope: `read:altinn` (the ACTIVE per-data-source Altinn scope — deliberately NOT the reserved delegate:* that keeps the raw system-user delegate route 403-gated). This tool is part of AGT-02 Fullmakt Rails; its read-side twin is check_fullmakt and its revocation leg is revoke_fullmakt. Mock-adapter-backed pending live partner validation; the response shape is identical in both modes.

  Connector

• get_company_context

  mcp

  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). Cost: 50 øre (NOK 0.50) per call, debited from the API key's prepaid credit balance when credit enforcement is live. Current prices for every metered tool are discoverable without authentication via the get_pricing tool (or GET /api/v1/pricing for REST clients). A call with insufficient balance returns INSUFFICIENT_CREDITS with top_up_url, balance_ore and cost_ore for self-recovery; while enforcement is live, every successful metered call reports its remaining balance on metadata.credits.

  Connector

• get_company_deadlines

  mcp

  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). Cost: 50 øre (NOK 0.50) per call, debited from the API key's prepaid credit balance when credit enforcement is live. Current prices for every metered tool are discoverable without authentication via the get_pricing tool (or GET /api/v1/pricing for REST clients). A call with insufficient balance returns INSUFFICIENT_CREDITS with top_up_url, balance_ore and cost_ore for self-recovery; while enforcement is live, every successful metered call reports its remaining balance on metadata.credits.

  Connector

• get_company_obligations

  mcp

  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). Cost: 50 øre (NOK 0.50) per call, debited from the API key's prepaid credit balance when credit enforcement is live. Current prices for every metered tool are discoverable without authentication via the get_pricing tool (or GET /api/v1/pricing for REST clients). A call with insufficient balance returns INSUFFICIENT_CREDITS with top_up_url, balance_ore and cost_ore for self-recovery; while enforcement is live, every successful metered call reports its remaining balance on metadata.credits.

  Connector

• get_company_verification

  mcp

  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). Cost: 50 øre (NOK 0.50) per call, debited from the API key's prepaid credit balance when credit enforcement is live. Current prices for every metered tool are discoverable without authentication via the get_pricing tool (or GET /api/v1/pricing for REST clients). A call with insufficient balance returns INSUFFICIENT_CREDITS with top_up_url, balance_ore and cost_ore for self-recovery; while enforcement is live, every successful metered call reports its remaining balance on metadata.credits.

  Connector

• get_company_accounts

  mcp

  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). Cost: 50 øre (NOK 0.50) per call, debited from the API key's prepaid credit balance when credit enforcement is live. Current prices for every metered tool are discoverable without authentication via the get_pricing tool (or GET /api/v1/pricing for REST clients). A call with insufficient balance returns INSUFFICIENT_CREDITS with top_up_url, balance_ore and cost_ore for self-recovery; while enforcement is live, every successful metered call reports its remaining balance on metadata.credits.

  Connector

• get_company_filing_history

  mcp

  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). Cost: 50 øre (NOK 0.50) per call, debited from the API key's prepaid credit balance when credit enforcement is live. Current prices for every metered tool are discoverable without authentication via the get_pricing tool (or GET /api/v1/pricing for REST clients). A call with insufficient balance returns INSUFFICIENT_CREDITS with top_up_url, balance_ore and cost_ore for self-recovery; while enforcement is live, every successful metered call reports its remaining balance on metadata.credits.

  Connector

• search_recipes

  food-recipe-mcp

  Search a database of recipes using hybrid semantic search (dense + sparse) with reranking. The database contains ~50,000 recipes from Food.com covering a wide range of cuisines, meal types, and cooking styles. Recipes include nutritional information, difficulty ratings, and user ratings. Use natural language in the query to describe what you are looking for — cuisine, style, main ingredient, occasion, or mood all work well. Norwegian and English are both supported natively. Examples: 'quick Italian pasta for weeknight dinner' 'Swedish meatballs with gravy' 'healthy high-protein chicken bowl' 'easy chocolate cake for beginners' 'something with salmon and lemon' 'Indian curry chicken' 'traditional Norwegian kjøttkaker' 'hurtig pasta med kylling' 'enkel sjokoladekake' Args: query: What you are looking for — describe the dish, cuisine, main ingredient, cooking style or mood freely. Any language is supported. diet: Optional — filter by dietary requirement: 'vegetarian', 'vegan', 'gluten-free', 'dairy-free', 'low-carb', 'keto', 'paleo' max_minutes: Optional — maximum total time in minutes, e.g. 30 difficulty: Optional — 'easy', 'medium' or 'hard' servings: Optional — not used for filtering (servings vary), but include in query for scaling context, e.g. 'pasta dish for 6 people' limit: Number of results to return after reranking (default 5, max 20) Returns: List of recipes ranked by relevance. Each result includes rerank_score, rrf_score (hybrid fusion), title, total_time, difficulty, diet labels, ingredients, instructions, nutrition, rating, and source URL context.

  Connector

• firmaradar_compare_companies

  Firmaradar

  Compare key financial metrics of up to 5 Norwegian companies side-by-side across the last N years (default 5). Use for competitor analysis, benchmark research or 'which of these three companies is the strongest?' Amounts are in each company's reporting currency (see the `currencies` field; NOK for most Norwegian companies) — check it before comparing absolute amounts. `antall_ansatte` is a CURRENT-value register attribute with no per-year history: read it from the top-level `antall_ansatte` field ({orgnr: headcount}); its rows in `comparison` are always null.

  Connector

• firmaradar_get_risk_score_bulk

  Firmaradar

  Bulk-endpoint for portfolio-screening of risikoscore (0-100 with named level lav/moderat/høy/kritisk + component breakdown) on up to 50 Norwegian companies in one call. Each orgnr counts as one unit against your quota. Compliance-gates (ENK/NUF blocking, customer-confirmation required, extension disabled) are returned per orgnr in the result list instead of failing the whole call — check each result's `error` field. Use for credit-decision screening, supplier-portfolio review, and KYC risk triage at scale.

  Connector