Skip to main content
Glama

nordic-data

by io.github.Mnymann
OverviewDiscussionsAdmin

lookup_company

Read-onlyIdempotent

Call before onboarding a supplier or customer to confirm the legal entity exists and is active. Look up basic company data (name, address, status, industry, VAT registration, founding date) from official European business registries. Supports 15 countries: DK (CVR), NO (Brønnøysund), SE (Bolagsverket), FI (YTJ/PRH), IE (CRO), UK (Companies House), FR (INSEE Sirene), DE (Handelsregister), CZ (ARES), PL (KAS+KRS), LV (Uzņēmumu reģistrs), EE (Ariregister), NL (KvK), BE (KBO), LU (RCSL). Tier note: NL and DE use paid upstream registries (KvK and Handelsregister). Free-tier API keys will receive HTTP 402 with error 'upgrade_required' — do NOT retry on 402; the error message includes an upgrade URL. On paid tiers, NL calls cost 5x quota units and DE calls cost 3x; all other countries cost 1x.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesNational company identifier. DK=CVR (8 digits), NO=orgnr (9), SE=orgnr (10), FI=Y-tunnus (NNNNNNN-D), IE=CRO (1-7), UK=8 chars, FR=SIREN (9), DE=HRB number, CZ=IČO (8), PL=NIP (10) or KRS (10), LV=11 digits, EE=8 digits, NL=KvK (8 digits), BE=BCE/KBO (10 digits), LU=RCSL (B + digits).
countryYesISO 3166-1 alpha-2 country code, lowercase. One of: dk, no, se, fi, ie, uk, fr, de, cz, pl, lv, ee, nl, be, lu.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoNational company identifier.
nameNoRegistered legal name.
sourceNoUpstream registry name (CVR, Brønnøysund, etc.).
statusNoRegistry status, e.g. active, dissolved, bankrupt.
addressNoRegistered address: an object ({street, city, zip}) or a single formatted string, depending on the registry.
countryNoCountry code or name as returned by the source registry.
foundedNoISO-8601 founding date, if known.
industryNoIndustry classification ({code, description}; NACE or national code).
fetchedAtNoISO-8601 timestamp when the data was fetched upstream.
legalFormNoLegal form: an object ({code, description}) or a string, depending on the registry.
vatRegisteredNoWhether the company is VAT-registered, where the registry reports it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed17 schema fields changed
    • changedOutput schema / properties / address / description
      Previous value: -"Registered address as returned by the source registry."New value: +"Registered address: an object ({street, city, zip}) or a single formatted string, depending on the registry."
    • changedOutput schema / properties / address / type
      Previous value: -"object"New value: +[
+  "object",
+  "string",
+  "null"
+]
    • changedOutput schema / properties / country / description
      Previous value: -"ISO 3166-1 alpha-2 country code (lowercase)."New value: +"Country code or name as returned by the source registry."
    • changedOutput schema / properties / country / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • addedOutput schema / properties / fetchedAt
      Added value: +{
+  "description": "ISO-8601 timestamp when the data was fetched upstream.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • changedOutput schema / properties / founded / description
      Previous value: -"ISO-8601 founding date."New value: +"ISO-8601 founding date, if known."
    • changedOutput schema / properties / founded / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedOutput schema / properties / id / description
      Previous value: -"National company identifier as supplied."New value: +"National company identifier."
    • changedOutput schema / properties / id / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedOutput schema / properties / industry / description
      Previous value: -"Industry classification (NACE / national code + label)."New value: +"Industry classification ({code, description}; NACE or national code)."
    • changedOutput schema / properties / industry / type
      Previous value: -"object"New value: +[
+  "object",
+  "null"
+]
    • addedOutput schema / properties / legalForm
      Added value: +{
+  "additionalProperties": true,
+  "description": "Legal form: an object ({code, description}) or a string, depending on the registry.",
+  "type": [
+    "object",
+    "string",
+    "null"
+  ]
+}
    • changedOutput schema / properties / name / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedOutput schema / properties / source / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • changedOutput schema / properties / status / type
      Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
    • removedOutput schema / properties / vat
      Removed value: -{
-  "additionalProperties": true,
-  "description": "VAT registration metadata (number, registered flag).",
-  "type": "object"
-}
    • addedOutput schema / properties / vatRegistered
      Added value: +{
+  "description": "Whether the company is VAT-registered, where the registry reports it.",
+  "type": [
+    "boolean",
+    "null"
+  ]
+}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses the 402 'upgrade_required' failure mode, instructs not to retry on 402, and quantifies quota consumption (NL 5x, DE 3x, others 1x). This is actionable behavioral detail the schema and annotations don't provide.

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 front-loaded with the trigger and then lays out countries, then tier/error behavior in a logical order. The country list partly repeats the schema enum, but it's not padded; every section adds operational context.

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?

With an output schema present and read-only/idempotent annotations, the description covers the key operational aspects: use case, country coverage, failure/retry behavior, and quota impact. No essential information for calling the tool correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description adds the country-specific quota costs (NL/DE premium tiers), which is meaningful semantics for choosing among country values. It doesn't add id-format detail, but that's already in the schema.

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?

The description names a specific verb ('look up'), a concrete resource ('legal entity ... from official European business registries'), and a clear purpose ('confirm the legal entity exists and is active'). It also scopes to basic company data, which distinguishes it from sibling enrichment/validation tools like company_enriched and validate_vat.

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

Usage Guidelines4/5

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

It gives a clear trigger: 'Call before onboarding a supplier or customer...' This is explicit context, though it doesn't name alternatives or when-not-to-use relative to siblings.

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

All nordic-data toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources