Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@aria-mcp-cvr-dk Look up company by CVR 24256790"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that looks up Danish companies in CVR (Det Centrale Virksomhedsregister) via cvrapi.dk. Built for ARIA and shareable with the community.
Use-case: ARIA resolves a company from an invoice, email, or contract — "hvem er CVR 12345678" or "find firmaet Netcompany".
Source | What | Attribution |
Danish company data from CVR (Det Centrale Virksomhedsregister) | cvrapi.dk / CVR (Erhvervsstyrelsen). Free tier: ~50 lookups/day. |
Important: A descriptive User-Agent header is required by cvrapi.dk's terms of service. This server sets it automatically:
aria-mcp-cvr-dk/1.0.0 (https://github.com/kimhjort/aria-mcp-cvr-dk)The free tier allows approximately 50 requests per day. For higher volume, see cvrapi.dk for commercial options.
Related MCP server: Brreg MCP Server
npx aria-mcp-cvr-dkOr install globally:
npm install -g aria-mcp-cvr-dk
aria-mcp-cvr-dkRequires Node.js 20 or later.
lookup_company({ query })Look up a Danish company by CVR number, company name, or phone number.
Parameters:
Name | Type | Required | Description |
| string | Yes | Company name, CVR number (8 digits), or phone number. |
Returns (found):
{
"found": true,
"query": "Novo Nordisk",
"company": {
"cvr": "24256790",
"name": "NOVO NORDISK A/S",
"address": "Novo Alle 1",
"zipcode": "2880",
"city": "Bagsværd",
"phone": "44448888",
"email": null,
"industry_code": 212000,
"industry_description": "Fremstilling af farmaceutiske præparater",
"company_type_code": 60,
"company_type": "Aktieselskab",
"active": true,
"start_date": "28/11 - 1931",
"end_date": null,
"employees": 30074,
"credit_bankrupt": false
}
}Returns (not found):
{
"found": false,
"query": "nonexistent company",
"message": "No company found for query \"nonexistent company\" in CVR. Try an exact CVR number (8 digits) or a different spelling."
}search_companies({ name })Search for Danish companies by name.
Note: cvrapi.dk returns a single best match per query, not a paginated list of results. This tool returns that one match and documents this behaviour explicitly. For an exact lookup by CVR number, use lookup_company instead.
Parameters:
Name | Type | Required | Description |
| string | Yes | Company name or partial name to search for. |
Returns:
{
"found": true,
"query": "Netcompany",
"note": "cvrapi.dk returns a single best match per query, not a paginated list. This is that best match.",
"match_count": 1,
"companies": [{ "cvr": "...", "name": "...", "..." : "..." }]
}Field | Type | Description |
| string | CVR number (8 digits) |
| string | Legal company name |
| string | null | Street address |
| string | null | Postal code |
| string | null | City |
| string | null | Phone number |
| string | null | Email address |
| number | null | Danish industry code (DB07) |
| string | null | Danish industry description |
| number | null | CVR company type code |
| string | null | Company type (e.g. "Aktieselskab", "Anpartsselskab") |
| boolean |
|
| string | null | Registration start date |
| string | null | Registration end date (null = still active) |
| number | null | Number of employees (if available) |
| boolean | null | Whether the company is bankrupt |
Add to your ARIA credentials / MCP config to use with ARIA:
{
"Name": "CVR",
"Command": "npx",
"Args": ["-y", "aria-mcp-cvr-dk"]
}No environment variables required — cvrapi.dk is keyless.
git clone https://github.com/kimhjort/aria-mcp-cvr-dk
cd aria-mcp-cvr-dk
npm install
npm run build
npm testMIT — see LICENSE.
Company data is sourced from CVR (Det Centrale Virksomhedsregister) via cvrapi.dk. Please respect cvrapi.dk's terms of service and the ~50 requests/day free-tier limit.
Look up a Danish company in CVR (Det Centrale Virksomhedsregister) by CVR number, company name, or phone number. Returns structured fields: cvr, name, address, zipcode, city, phone, email, industry_code, industry_description, company_type, active status, start_date, end_date, employees, credit_bankrupt. Use this when you need to identify a company from an invoice, email, or contract, e.g. "hvem er CVR 12345678" or "find Netcompany". Data source: cvrapi.dk (free tier, ~50 lookups/day).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Company name, CVR number (8 digits), or phone number to search for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully discloses behavior: it states the data source (cvrapi.dk), rate limit (~50 lookups/day), and lists the return fields. This transparency is excellent for a lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and well-structured. The first sentence states the action and search keys, the second provides usage context and data source. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool, the description covers all necessary aspects: purpose, usage, return fields, data source, and rate limit. No output schema exists, but the description lists the fields, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'query' parameter, but the description adds valuable meaning by specifying that it can be a company name, CVR number, or phone number, which is not in the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Look up'), the resource ('Danish company in CVR'), and the search keys (CVR number, company name, or phone number). It distinguishes itself from the sibling 'search_companies' by being a direct lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use context: 'Use this when you need to identify a company from an invoice, email, or contract.' It gives concrete examples. It does not explicitly state when not to use, but the context is strong enough to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Danish companies by name in CVR (Det Centrale Virksomhedsregister). Note: cvrapi.dk returns a single best match per query, not a list of results. This tool returns that one match along with a note about this behaviour. For an exact lookup by CVR number use lookup_company instead. Data source: cvrapi.dk (free tier, ~50 lookups/day).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Company name (or partial name) to search for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a single best match with a note, and mentions data source and rate limit. However, it does not describe error handling or output format in detail, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing four sentences that each add value: purpose, behavioral note, alternative tool, and data source/limit. No wasted words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description is fairly complete. It explains the data source, behavior, rate limit, and alternative. It lacks details on the response format (e.g., structure of the match object), but the note about returning 'a note about this behaviour' adds some context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a clear description for the single parameter 'name' ('Company name (or partial name) to search for.'). The description does not add additional semantic value beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for Danish companies by name in the CVR register, and distinguishes from the sibling tool lookup_company for exact CVR lookups. The verb 'search' and resource 'Danish companies by name' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (search by name) and when to use the alternative (exact lookup_company). It also notes the behavioral quirk (single best match) and rate limit, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0lookup_companysearch_companiesScored across 2 tools
Both tools interact with the CVR register, but descriptions clearly differentiate: lookup_company accepts CVR number, name, or phone, while search_companies is specifically for name search and warns it returns only one match. Minor overlap exists since both can search by name, but the descriptions help agents choose correctly.
Both tool names follow the consistent verb_noun snake_case pattern: lookup_company and search_companies. No deviations or mixed conventions.
With only 2 tools, the server feels thin for a dedicated CVR lookup service. While the domain is narrow, a typical minimal set might include more variations (e.g., search by address or industry), so the count is borderline.
The server covers basic lookup and name search, but lacks other common operations like industry code lookup, paginated search, or filtering. Core functionality is present, but there are notable gaps for a comprehensive company registry tool.
Nordic company intelligence: look up companies, AI summaries, scores and signals via MCP.
Danish address & property lookup: BBR, Matriklen, DAR, CVR. A DAWA/Datafordeler-compatible source.
Official company and director data: search, profiles, filings, and name normalization.
Agent-native API for Finnish public company data via YTJ. Pay-per-call $0.01 USDC over x402.
