Which tools does an agent call to verify a Norwegian company?

Three cover the core run: search_companies resolves a company name to its 9-digit organisation number, get_company_verification returns the pass, warn, fail or unknown verdict with the registry signals behind it, and get_company_authority answers who is registered as able to sign. Each response names its sources and states how fresh the data is, so the agent can cite where every fact came from.

Does the agent need an API key?

Discovery does not; company data does. An MCP client can list the available tools without any credential, which is how an agent finds out what the server offers. The tools that answer questions about a specific named company require an API key, and the key's scopes bound what the agent can reach. That split is deliberate: discovery is free, data about real companies is accountable.

Can the agent act on the verdict automatically?

On the reading side, yes: it can record the verdict, flag a supplier, or block an onboarding flow, because those are decisions inside your own system acting on registered facts. What it cannot do is take binding action toward the government: no filing is submitted and nothing is written to any public register. Anything with legal effect stays with a human, and the agent's job is to arrive there with the evidence already gathered.

How does the agent avoid hallucinating company facts?

By never being asked to remember them. The verification flow routes every factual question through a tool call that reads the authoritative registers at that moment, and the tool's answer is schema-validated data with source and freshness attached. The model's role is orchestration: choosing which tool to call and what to do with the result. A fact that did not come back from a tool does not enter the verdict.

Can an agent verify who is allowed to sign for the company?

Yes, with an honest boundary. The authority tool returns the registered signing classification, from sole signing rights through joint arrangements, and it answers unknown when the open data cannot settle the question. An agent that treats unknown as a stop-and-ask signal, rather than rounding it to yes or no, is doing exactly what the check is designed for.

How does an AI agent verify a Norwegian company?

By Antony Richard Grov, founder of Apier

By calling deterministic tools instead of remembering. The agent receives a task in natural language, something like check this supplier before we pay. It resolves the company to its 9-digit organisation number, calls verification tools that read the Norwegian registers at that moment, and receives a schema-validated verdict: pass, warn, fail or unknown, with every signal named and every unknown stated rather than papered over. Then it acts on grounded facts, records the verdict, flags the counterparty, or hands over to a human when the answer is unknown or the next step is binding. The model orchestrates the flow, but the facts come from the registers through the tools, never from the model's memory, and nothing in the flow files or writes anything to a government system.

The division of labour that makes agent verification trustworthy. The model owns the two outer boxes, understanding the task and deciding what to do; the accented middle belongs to deterministic tools reading the registers.

What does verification mean for an agent?

Exactly what it means for a person running KYB: establish that the company exists, is active, is not bankrupt or deleted, check its VAT registration, and find out who is registered as able to sign for it. The questions do not change because an agent is asking. What changes is the mechanism. A person can eyeball a registry website and apply judgement to what they see; an agent needs every one of those answers as structured data it can branch on, from a source it is entitled to cite.

That requirement rules out the model's own training data from the start. Whatever a model absorbed about a company is months to years stale and cannot be cited as evidence for a payment decision. Verification is precisely the workflow where a plausible answer is worse than no answer, so the facts have to be fetched live, from the registers, at the moment the question is asked.

Walk through one verification run

Take the concrete case the diagram shows: an accounts-payable agent is asked to check a supplier before an invoice is paid. The supplier is known by name, so the run starts by resolving identity: search_companies turns the name into candidate organisation numbers, and the agent confirms the match on address or entity form rather than assuming the first hit. With the number fixed, get_company_verification returns the verdict and its signals, and because an invoice is about to be paid, get_company_authority adds who is registered as able to commit the company.

Each answer arrives as schema-validated data with source and freshness stated, so the agent's final report can say not just approved but approved because the register said active, no distress flags, VAT registered, checked at this timestamp. The whole run is reconstructable afterwards, which is what separates an audit trail from a chat log.

One supplier check, step by step: what the agent does, the tool it calls, and what comes back.
Step	Tool call	What comes back
Resolve the company	search_companies with the supplier's name	Candidate org numbers with name, form and address to confirm the match.
Verify status	get_company_verification with the org number	A pass, warn, fail or unknown verdict, with each registry signal listed.
Check signing authority	get_company_authority with the org number	The registered signing classification, unknown stated when open data cannot settle it.
Conclude	No tool: the agent's own logic	Approve, flag or escalate, citing the sources and timestamps it collected.

Why deterministic tools instead of model knowledge?

Because the same question must produce the same answer for as long as the register has not changed, and because every answer must trace to a source. Tool calls give the agent both properties for free: the tool reads the register, the response carries source and freshness, and nothing depends on what the model happens to recall. The reasoning behind this split is a topic of its own, and the guide on agents getting Norwegian facts without hallucinating owns it; this page is the workflow that reasoning makes safe.

The practical wiring is MCP, the open protocol that lets Claude, Cursor and other clients discover and call these tools. The guide on connecting a client to Norwegian company data over MCP covers setup, the keyless discovery surface and the key handling; here it is enough that the tools appear in the agent's tool list and answer deterministically.

What happens on unknown or an error?

The flow branches instead of guessing. An unknown verdict, say on signing authority where the open data cannot settle the question, is a first-class outcome the agent is expected to handle: flag it, ask a human, or proceed under a policy that explicitly accepts the gap. What the agent must never do is round unknown to a pass, because a check whose gaps are invisible stops being a check.

Failures are structured the same way. An error response carries a machine-readable code, an explanation and concrete fix steps, so the agent can distinguish a typo in the organisation number from a missing credential and react accordingly. A failed run surfaces as a failed run, never as a fabricated verdict.

What can the agent not do?

Anything binding toward the government. The surface this workflow runs on is read-and-validate: the agent reads registers, evaluates rules and validates payloads, and no filing is submitted to Altinn or any other public system. Where a real submission would come next, the flow ends in a handover that names what a human must do and where. Keeping the boundary explicit is what lets the reading side run autonomously with a clear conscience: the agent gathers and grounds the evidence, and the decisions with legal effect stay with people.

Make the first call

The discovery call below needs no key and returns the live tool list, including the three tools this page walked through. Point an MCP client at the same endpoint and the tools appear in the model's tool list by themselves.

# Keyless discovery: the same call an MCP client makes on startup.
curl -s -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":"tools/list"}'

Frequently asked questions

Which tools does an agent call to verify a Norwegian company?: Three cover the core run: search_companies resolves a company name to its 9-digit organisation number, get_company_verification returns the pass, warn, fail or unknown verdict with the registry signals behind it, and get_company_authority answers who is registered as able to sign. Each response names its sources and states how fresh the data is, so the agent can cite where every fact came from.
Does the agent need an API key?: Discovery does not; company data does. An MCP client can list the available tools without any credential, which is how an agent finds out what the server offers. The tools that answer questions about a specific named company require an API key, and the key's scopes bound what the agent can reach. That split is deliberate: discovery is free, data about real companies is accountable.
Can the agent act on the verdict automatically?: On the reading side, yes: it can record the verdict, flag a supplier, or block an onboarding flow, because those are decisions inside your own system acting on registered facts. What it cannot do is take binding action toward the government: no filing is submitted and nothing is written to any public register. Anything with legal effect stays with a human, and the agent's job is to arrive there with the evidence already gathered.
How does the agent avoid hallucinating company facts?: By never being asked to remember them. The verification flow routes every factual question through a tool call that reads the authoritative registers at that moment, and the tool's answer is schema-validated data with source and freshness attached. The model's role is orchestration: choosing which tool to call and what to do with the result. A fact that did not come back from a tool does not enter the verdict.
Can an agent verify who is allowed to sign for the company?: Yes, with an honest boundary. The authority tool returns the registered signing classification, from sole signing rights through joint arrangements, and it answers unknown when the open data cannot settle the question. An agent that treats unknown as a stop-and-ask signal, rather than rounding it to yes or no, is doing exactly what the check is designed for.