Skip to main content
Glama
Sign In

SelskabsInfo — Danish company data

by dk.selskabsinfo
OverviewDiscussionsAdmin

Search Danish companies

search_companies
Read-only

Search Danish companies by name or CVR number, or list every active company in an industry and place. With query alone it searches CVR by name, ceased companies included; an 8-digit query is an exact CVR lookup and returns at most one company. Use this first when the user names a company but gives no CVR number. With industry_code, industry, city or postal_code it lists active companies only, alphabetically, and "total" is the full count, so "how many" takes one call; query then narrows the list to names containing it, and legal_form to one company form. Results carry identity and registration details only (name, CVR, city, postcode, industry and its code, company form, and reklamebeskyttet: true when the company has opted out of direct marketing); call get_company for financials, ownership or risk data. Costs 1 credit per page on every plan.

Input Schema

NameRequiredDescriptionDefault
cityNoPostal district, matched from its start and ignoring case: "Aarhus" finds Aarhus C, N and V. A suburb with a district of its own, such as Viby J, needs its own call.
pageNoPage of results, starting at 1. page × per_page may be at most 10000. A CVR lookup has its one result on page 1.
queryNoCompany name or 8-digit CVR number. Together with a filter, part of the name instead, matched anywhere in it and ignoring case.
industryNoPart of the Danish industry name, e.g. "restaurant", "tømrer" or "revision", matched anywhere in it and ignoring case. The industries it matched come back in "brancher".
per_pageNoResults per page (max 100). Keep this small unless the user asked for a long list.
legal_formNoCompany form as results show it in virksomhedsform, e.g. "APS", "A/S" or "ENK"; the full name ("Anpartsselskab") works too. It narrows a list, so it needs one of the filters above.
postal_codeNoDanish 4-digit postcode, e.g. "8000".
industry_codeNoDB25 industry code (branchekode): all 6 digits for one industry ("561110", restaurants and cafés), or the first 2 or 4 for its whole group ("62", software and IT consultancy).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • addedInput schema / properties / city
      Added value: +{
+  "description": "Postal district, matched from its start and ignoring case: \"Aarhus\" finds Aarhus C, N and V. A suburb with a district of its own, such as Viby J, needs its own call.",
+  "maxLength": 200,
+  "minLength": 2,
+  "type": "string"
+}
    • addedInput schema / properties / industry
      Added value: +{
+  "description": "Part of the Danish industry name, e.g. \"restaurant\", \"tømrer\" or \"revision\", matched anywhere in it and ignoring case. The industries it matched come back in \"brancher\".",
+  "maxLength": 200,
+  "minLength": 3,
+  "type": "string"
+}
    • addedInput schema / properties / industry_code
      Added value: +{
+  "description": "DB25 industry code (branchekode): all 6 digits for one industry (\"561110\", restaurants and cafés), or the first 2 or 4 for its whole group (\"62\", software and IT consultancy).",
+  "pattern": "^(\\d{2}|\\d{4}|\\d{6})$",
+  "type": "string"
+}
    • addedInput schema / properties / legal_form
      Added value: +{
+  "description": "Company form as results show it in virksomhedsform, e.g. \"APS\", \"A/S\" or \"ENK\"; the full name (\"Anpartsselskab\") works too. It narrows a list, so it needs one of the filters above.",
+  "maxLength": 200,
+  "type": "string"
+}
    • changedInput schema / properties / page / description
      Previous value: -"Page of results, starting at 1. A CVR lookup has its one result on page 1."New value: +"Page of results, starting at 1. page × per_page may be at most 10000. A CVR lookup has its one result on page 1."
    • addedInput schema / properties / postal_code
      Added value: +{
+  "description": "Danish 4-digit postcode, e.g. \"8000\".",
+  "pattern": "^\\d{4}$",
+  "type": "string"
+}
    • changedInput schema / properties / query / description
      Previous value: -"Company name or 8-digit CVR number."New value: +"Company name or 8-digit CVR number. Together with a filter, part of the name instead, matched anywhere in it and ignoring case."
    • addedInput schema / properties / query / maxLength
      Added value: +200
    • removedInput schema / required
      Removed value: -[
-  "query"
-]
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, openWorld), yet the description still adds non-obvious behavior: query-only search includes ceased companies, an 8-digit query is an exact lookup capped at one result, filter mode returns active companies only and alphabetically, and 'total' is the full count. It also discloses cost ('1 credit per page on every plan') and the exact result fields returned. Only pagination limits are left to the schema.

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?

Front-loaded with the core action and the two modes before any detail, and every clause carries information. It is dense and clause-heavy (long compound sentences with semicolons), which slightly hurts scannability, but there is no filler.

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?

For an 8-parameter, all-optional search tool with no output schema, the description covers mode selection, filter interaction, result shape (listing the returned fields and the meaning of reklamebeskyttet), counting behavior, and cost. Nothing an agent needs in order to call it 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, but the description adds semantics the schema does not state as a whole: query changes meaning depending on mode ('query then narrows the list to names containing it'), and legal_form only works in combination with a filter. That cross-parameter interaction is genuine added value.

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?

Names a specific verb and resource ('Search Danish companies') and immediately splits the tool into its two distinct modes: name/CVR lookup and filtered list mode. It also names the sibling it is not ('call get_company for financials'), so an agent can distinguish it from the get_* family without opening any schema.

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?

Gives explicit routing guidance: 'Use this first when the user names a company but gives no CVR number', plus a rule for the alternative ('call get_company for financials, ownership or risk data'). It also states which argument combinations are required for list mode ('legal_form ... needs one of the filters above'), which is real when/when-not guidance.

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

All SelskabsInfo — Danish company 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