Apier MCP Server

Company verification verdict

get_company_verification

Read-onlyIdempotent

Check a Norwegian company's active status and visible signing authority by its 9-digit organisasjonsnummer to get a pass, fail, or unknown trust verdict, enabling go/no-go decisions before acting.

Instructions

Get the deterministic verification verdict for a Norwegian organisation by its 9-digit organisasjonsnummer — a fast go / no-go trust check before acting on a company's behalf. Keyed ONLY off entity activity plus visible signing authority (signaturrett, prokura, or an ENK innehaver). verification_status: pass (active AND visible signing authority), fail (not active — konkurs, under avvikling, or oppløst), unknown (indeterminate or none visible — never a claimed absence; warn reserved). Seven transparency signals never change the verdict. The breakdown is available from get_company_authority; call get_company_context for identity, get_company_summary for obligations-and-deadlines, or get_company_obligations for drill-down. Failure modes: NOT_FOUND, SCOPE_INSUFFICIENT (needs read:brreg), UPSTREAM_UNAVAILABLE, VALIDATION_FAILED. No API key? Bearer apier_sandbox_test_ (fresh suffix) serves synthetic fixtures; org numbers: GET /api/v1/sandbox/fixtures. Cost: 50 øre (NOK 0.50) per call, prepaid (prices: the get_pricing tool or GET /api/v1/pricing; a shortfall returns INSUFFICIENT_CREDITS with top_up_url). Docs: https://www.apier.no/docs/guides/norwegian-company-register-search

Input Schema

TableJSON Schema

Name	Required	Description	Default
`org_number`	Yes	9-digit Norwegian organisasjonsnummer (Brønnøysund ID); MOD-11-checked up-front — a failing value is rejected as VALIDATION_FAILED, so correct the number rather than retrying it.

Output Schema

TableJSON Schema

Name	Required	Description
`_meta`	No
`result`	Yes	The verdict: `verification_status` (pass / fail / unknown; `warn` reserved), the seven signals, Norwegian `summary`, `signing_authority_summary`, `last_accounts_year`, and the registry identity echo.
`metadata`	Yes
`justification`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.2.1Sep 26, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description goes well beyond these by explaining the deterministic nature, the exact input keying (entity activity + visible signing authority), the semantics of pass/fail/unknown, that 'warn' is reserved, and that transparency signals never change the verdict. It also discloses failure modes, authentication scope, cost, and sandbox behavior, providing comprehensive behavioral context without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-organized: it starts with the core purpose and verdict logic, then moves to alternatives, failure modes, cost, and sandbox details. Every sentence contributes unique information; however, the overall length is high, and some operational details (like sandbox URLs and pricing) could be moved to dedicated fields if available.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and the presence of an output schema and annotations, the description covers all essential aspects: purpose, input validation, verdict semantics, failure modes, required scope, cost, sandbox usage, and related tools. An agent has everything needed to call the tool correctly and handle errors, making it fully self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% — the org_number parameter is fully described with a pattern, example, and detailed note about MOD-11 validation. The description only reiterates the 9-digit format and does not add additional meaning beyond the schema, so the baseline of 3 for high coverage is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('get the deterministic verification verdict for a Norwegian organisation') and characterizes it as a fast go/no-go trust check. It distinguishes itself from related tools by explicitly naming get_company_authority for breakdown and other tools for context, summary, and obligations, so an agent can tell them apart without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit usage context: 'before acting on a company's behalf' and lists precise alternatives — get_company_authority for breakdown, get_company_context for identity, get_company_summary for obligations, get_company_obligations for drill-down. It clearly indicates when this tool is appropriate versus when to use siblings, making routing decisions trivial.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.