MCP server for Danish company data, employment-law identity and financial figures. Retrieve legal company information and key financial metrics directly through your AI assistant.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 8 tools
Most tools have clearly distinct purposes: code lookup, exact company profile, financial analysis, ownership analysis, fuzzy entity resolution, risk profiling, bulk/geo screening, and sync status. Minor overlap exists between resolve_entity, screen_companies, and get_company for company lookup, and between ownership_network and risk_profile for relationship paths, but descriptions make the intended use reasonably clear.
All tool names use lowercase snake_case with a uniform cvr_ prefix. The grammatical mix of verb_noun and noun_phrase patterns is minor and does not reduce predictability or readability.
Eight tools is well-scoped for a CVR data and analysis server. Each tool covers a distinct capability without obvious redundancy or bloat.
The surface covers industry lookup, company profiles, financials, ownership networks, entity resolution, risk profiling, bulk/geo screening, and sync status. Minor gaps include no dedicated person or P-unit detail tool outside include[]/ownership paths, and no standalone document retrieval, but these are largely workable through existing tools.
Slår branchekoder op via fritekst i branchenavn eller kodepræfiks. Koderne er DB25 — CVR skiftede fra DB07 pr. 1.1.2025, og alle aktive virksomheder bærer DB25. Kald ALTID dette tool inden du bruger branche_kode i andre tools — gæt aldrig en kode. Returnerer matchende koder grupperet efter division (to første cifre) med antal aktive virksomheder.
| Name | Required | Description | Default |
|---|---|---|---|
| soeg | Yes | Søgeord i branchenavn (fx "transport", "rengøring", "detail") eller kodepræfiks (fx "49", "621"). En fuld DB07-kode (fx "620100") giver en henvisning til DB25-koden. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive safety, so the description's added value is the domain context: CVR moved from DB07 to DB25 as of 1.1.2025 and all active firms carry DB25. It also discloses the return shape (grouped by division, with active-company counts), which the annotations do not.
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?
Front-loaded with the core action, then the version context, then the usage mandate, then the return shape — a sensible order. Three compact sentences with little waste, though the DB07/DB25 background is slightly verbose for the value it carries.
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?
No output schema exists, but the description compensates by describing the return grouping and counts. Combined with 100% schema coverage and full annotation coverage, an agent has enough to invoke it correctly; pagination/limits are the only untold detail.
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?
Schema coverage is 100%, so the single param 'soeg' is already fully documented in the schema, including the DB07-code-to-DB25 cross-reference. The description only restates the accepted input forms, adding no syntax or format detail beyond what the schema provides. Baseline 3 applies.
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?
Specific verb + resource ('Slår branchekoder op') plus the input mode (fritekst i branchenavn eller kodepræfiks). It is clearly distinguishable from every sibling, none of which look up industry codes. The DB25/DB07 provenance statement sharpens what resource is being resolved.
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?
Gives an explicit trigger: 'Kald ALTID dette tool inden du bruger branche_kode i andre tools — gæt aldrig en kode.' That is strong, specific guidance for workflow ordering and a clear prohibition on guessing. It lacks any when-not or alternative-tool mention, so it falls short of the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Henter beregnede nøgletal + væksttrend for en virksomhed (default seneste 5 år). Auto-syncer fra CVR hvis ingen lokale data findes. Brug include[] for ekstra: raw_xbrl (alle felter fra årsrapport, live), benchmark (branche-median for samme år), documents (live URLs til PDF/XBRL).
| Name | Required | Description | Default |
|---|---|---|---|
| include | No | Ekstra sektioner: raw_xbrl (live XBRL-felter), benchmark (branche-median), documents (live dokument-URLs) | |
| xbrl_aar | No | Specifikt år for raw_xbrl include. Default: seneste tilgængelige. | |
| antal_aar | No | Antal år tilbage at vise (1–10). Default: 5 | |
| cvr_nummer | Yes | CVR-nummer (8 cifre) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and open-world, so the safety profile is covered. The description adds genuinely non-annotated behavior: auto-sync from CVR when no local data exists, a default 5-year window, and which include sections are 'live' (raw_xbrl, documents). It omits only return shape and error handling.
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?
Three compact sentences with the core purpose and default scope front-loaded, followed by the optional extension mechanism. Dense and largely waste-free, though the include list partially duplicates the schema enum.
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?
For a read-only tool with full schema coverage and no output schema, the description adequately covers purpose, defaults, auto-sync behavior, and optional sections. It stops short of describing the returned metrics or growth-trend format, which is a minor gap given no output schema exists.
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?
Schema description coverage is 100%, so the schema already documents all four parameters including the include enum. The description mostly restates the include values and the 5-year default rather than adding syntax or edge-case guidance, keeping it at the baseline.
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?
Starts with a specific verb ('Henter') and resource ('beregnede nøgletal + væksttrend for en virksomhed'), which clearly distinguishes it from data-retrieval siblings like cvr_get_company or cvr_risk_profile. However, it never explicitly names a sibling or states what it is not, so an agent must infer the boundary.
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?
It explains how to extend results ('Brug include[] for ekstra') and notes auto-sync behavior when local data is absent, which implies usage context. But there is no explicit when-to-use versus alternatives and no guidance on when the extra sections are warranted beyond listing them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Henter standardprofil for 1–20 virksomheder via CVR-nummer. Default for 1 CVR: fuld standardprofil (grunddata + ledelse + ejere + P-enhed resumé + regnskabs-snapshot). Default for 2–20 CVR: kompakte sammenligningsrækker. Brug include[] til at hente ekstra data (produktionsenheder, events, historik, nabopar) — kun ved ÉT CVR. nabopar finder P-enheder fra samme CVR der ligger tæt på hinanden (overenskomstsmitte). Styr antal events med events_antal (default 10, max 100).
| Name | Required | Description | Default |
|---|---|---|---|
| include | No | Ekstra sektioner — KUN gyldig med ÉT cvr_nummer; med 2-20 afvises kaldet. produktionsenheder (fuld liste), events (live begivenheder), historik (tidligere ledelse/ejere), kvartalsbeskaeftigelse (CVR's kvartalstal; falder tilbage til årstal hvis selskabet ikke har kvartalstal), binavne (no-op — binavne vises altid), nabopar (P-enheder fra samme CVR der ligger tæt på hinanden — overenskomstsmitte). P-enhed-listen omfatter også OVERDRAGNE enheder (mærket [OVERDRAGET → CVR …]) — samme afgrænsning som datacvr.virk.dk, og et direkte spor efter virksomhedsoverdragelse | |
| cvr_numre | Yes | Liste af CVR-numre (1–20) | |
| events_antal | No | Antal registreringsbegivenheder ved include: events (default 10, max 100) | |
| penhed_region | No | Filtrer P-enheder på region (konverteres til postnummerinterval) | |
| nabopar_max_meter | No | Max afstand i meter for nabopar-søgning (default 300, max 1000). Kræver include: nabopar. | |
| penhed_postnummer_fra | No | Filtrer P-enheder: fra og med dette postnummer. Kan bruges alene (åben øvre ende). | |
| penhed_postnummer_til | No | Filtrer P-enheder: til og med dette postnummer. Kan bruges alene (åben nedre ende). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/openWorld, but the description adds real behavioral detail beyond them: the compact comparison-row default for multi-CVR calls, the kvartalsbeskaeftigelse fallback to yearly figures, that binavne is a no-op, and that P-enhed lists include overdragne enheder. Auth needs and rate limits remain unstated.
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?
Front-loaded with the core action and default behaviors, then parameter-relevant caveats. Dense but every sentence carries useful information; slightly heavy on parenthetical explanation.
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?
With no output schema and seven parameters, the description does the work of describing default payload contents and mode-dependent behavior, which is what an agent needs to call it correctly. Coverage of error/permission behavior is thin but not essential here.
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?
Schema description coverage is 100%, so all seven parameters are already documented in the schema itself. The description largely restates the include/events_antal semantics rather than adding new meaning, so baseline 3 applies.
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?
States a specific verb and resource ('Henter standardprofil for 1–20 virksomheder via CVR-nummer') and spells out what the default payload contains. It never names or routes against siblings like cvr_financial_analysis or cvr_ownership_network, so differentiation is left to inference.
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?
Gives clear operational context: default shape for 1 CVR vs 2–20 CVR, and that include[] is valid only with a single CVR (2–20 rejects the call). It lacks explicit when-to-use-this-vs-alternatives guidance against the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Op- og nedstrøms ejerskabsanalyse. For virksomhed (cvr_nummer): direkte og indirekte ejere (op til dybde 4), ejet-følgende, søstre, holding-klassifikation. For person (enhedsnummer): hierarkisk portefølje (ledende indflydelse, ejerandele, øvrige roller) prioriteret efter selskabets værdi.
| Name | Required | Description | Default |
|---|---|---|---|
| dybde | No | Antal niveauer opad/nedad i ejergrafen (1–4). Default: 1 | |
| cvr_nummer | No | CVR-nummer for virksomheds-analyse (8 cifre) | |
| kun_aktive | No | Kun aktive ejer-relationer (default: true) | |
| enhedsnummer | No | Enhedsnummer for person-analyse (heltal eller streng — fra cvr_resolve_entity) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds meaningful behavioral context beyond that: traversal is capped at depth 4, ownership chains include indirect and sister/holding relations, and person results are ranked by company value. No auth, rate-limit, or freshness caveats are given, keeping it at a strong 4.
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?
Two sentences, front-loaded with the core concept before mode-specific detail, with effectively no filler. The second sentence compresses a lot of clauses, which slightly hurts scanability, but nothing is redundant.
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?
With no output schema, the description carries the burden of signalling what comes back, and it does list the main result categories (owners, følgende, søstre, holding-klassifikation; influence, shares, roles). Annotations cover the safety profile and params are fully documented. Minor gaps remain around ordering/return shape and behavior when only some parameters are supplied.
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?
Schema description coverage is 100%, so all four parameters (dybde, cvr_nummer, kun_aktive, enhedsnummer) are already documented at field level. The description restates that cvr_nummer drives company mode and enhedsnummer drives person mode, and references the depth-4 ceiling, but adds little syntax or format detail the schema lacks.
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?
Names a specific resource and operation (op- og nedstrøms ejerskabsanalyse) and splits it cleanly into two analyzable domains: company ownership (direct/indirect owners, holdings, sisters) and person portfolio (roles, shares, influence). An agent can distinguish this graph-traversal tool from siblings like cvr_risk_profile or cvr_financial_analysis without opening the schema.
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?
Gives clear routing guidance for the two usage modes: pass cvr_nummer for company analysis, enhedsnummer for person analysis. It states context but no exclusions or named alternative tools for overlapping cases (e.g. when to prefer cvr_get_company instead), so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bred fuzzy-søgning på virksomhedsnavn, personnavn eller CVR-nummer. Returnerer en sektioneret liste: bedste virksomheder, personer med aktive roller, og øvrige match (ophørte/inaktive mv.). Virksomheder returnerer cvr_nummer; personer returnerer enhedsnummer.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Begræns søgning til virksomheder, personer eller begge (auto). Default: auto | auto |
| antal | No | Maks antal i top-sektionerne (virksomheder og aktive personer hver). 1-25, default 10. | |
| query | Yes | Søgeord — virksomhedsnavn, personnavn eller 8-cifret CVR-nummer. Eksempel: "Frode Laursen" eller "Maersk" | |
| status | No | Filtrer virksomheder på status. Default: NORMAL (kun aktive) | NORMAL |
| antal_ovrige | No | Maks antal i "Øvrige match"-sektionen. 0-50, default 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it a safe, idempotent read (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the safety profile is covered. The description adds genuinely new behavior: results are returned in sections (best companies, persons with active roles, other matches) and each entity type yields a different identifier. With no output schema, this return-shape disclosure is the main value-add.
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?
Two sentences, no padding, and the search scope is front-loaded before the return-behavior sentence. Every clause carries information an agent can act on.
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?
With no output schema, the description does the heavy lifting by describing the sectioned result structure and the identifiers returned, which is what an agent needs to chain into cvr_get_company. It stops short of describing result counts per section or the behavior of status/antal filters on the returned list, leaving a small gap for a 5-parameter resolver.
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?
Schema description coverage is 100%, so the schema already documents type, antal, query, status, and antal_ovrige including defaults and ranges. The description only restates that the query accepts a company name, person name, or 8-digit CVR number, adding no syntax or formatting detail beyond the schema. Baseline 3 applies.
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?
States a specific verb and scope: broad fuzzy search over company name, person name, or CVR number, which clearly separates it from exact-lookup siblings like cvr_get_company. The title ('Identificér virksomhed eller person') reinforces the intent. It does not name a sibling explicitly, so it falls just short of the top band.
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 word 'fuzzy' implies this is the entry-point resolver used before exact lookups, and its multi-entity scope implies when it beats company-only siblings. However, no sentence states when to prefer it over cvr_get_company or cvr_screen_companies, and no exclusions or prerequisites are given. Usage is only inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Arbejdsretslig identitet for 2–5 CVR i 6 sektioner (kontakt, delte personer, P-enhed-adresseoverlap, P-enhed-overdragelse mellem selskaberne, fusion/spaltning, ejerskabsstier) — returneres som rå data uden forudindtaget vurdering. Bemærk: enkelt-selskabs KYC/stabilitets-score er deaktiveret (kreditoplysningsvirksomhed kræver tilladelse).
| Name | Required | Description | Default |
|---|---|---|---|
| include | No | Ekstra: events (live fusion/spaltning). network_scan hørte til den deaktiverede 1-CVR KYC-profil. | |
| cvr_numre | Yes | Liste af 2-5 CVR-numre til identitets-sammenligning. (1 CVR / KYC-profil er deaktiveret.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely new context: results are raw data without a biased assessment, and the single-company KYC score is deactivated because credit-information activity requires a permit. It does not describe pagination or latency, keeping it below 5.
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?
Front-loads the purpose and section list in one dense sentence, then appends a clearly marked 'Bemærk:' caveat. No filler, though the single very long sentence is slightly heavy.
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?
With no output schema, the description carries the return-value burden and does so by naming the six sections and the raw-data framing. It omits any detail on result shape per section or ordering, so it is complete enough to call but not fully specified.
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?
Schema description coverage is 100%, so both parameters (cvr_numre, include) are already documented in the schema, including the enum note that network_scan belonged to the disabled 1-CVR profile. The description reinforces the 2–5 constraint and the KYC deactivation but adds no syntax beyond the schema, making 3 the correct baseline.
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?
States a specific resource (arbejdsretslig identitet) and scope (2–5 CVR i 6 sektioner), enumerating the six sections so the agent knows exactly what comes back. It does not explicitly differentiate itself from close siblings like cvr_ownership_network or cvr_screen_companies, so it stops short of a 5.
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?
Implies usage via the 2–5 CVR range and the note that the single-company KYC/stability profile is disabled, which hints the agent should not reach here for one-CVR scoring. However it names no alternative tool and gives no explicit 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.
Bulk-screening og radius-søgning (geo) af virksomheder og P-enheder. For geo-søgning: angiv geo_lat + geo_lon + geo_radius_meter — returnerer virksomheder og P-enheder inden for X meter, sorteret efter afstand. Brug count_only: true for at tjekke antal matches. Brug groupBy for aggregerede buckets (antal pr. branche/kommune). Brug similar_to_cvr for lookalike-søgning. Brug changed_since for at finde virksomheder med ændringer siden en dato (Early Warning).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maks antal resultater (1-500). Default: 50. I geo-mode gælder pr. sektion. | |
| offset | No | Offset til paginering. I geo-mode gælder det begge sektioner (virksomheder og P-enheder). | |
| geo_lat | No | Breddegrad for radius-søgning (kræver også geo_lon og geo_radius_meter) | |
| geo_lon | No | Længdegrad for radius-søgning (kræver også geo_lat og geo_radius_meter) | |
| groupBy | No | Aggregér resultater i buckets frem for at vise individuelle virksomheder (kun virksomheder-sektionen i geo-mode) | |
| kommune | No | Kommunenavn, fx "Aarhus" | |
| count_only | No | Returnér KUN antal matches — hurtig sanity-check inden tunge kald | |
| postnummer | No | Postnummer, fx 8000 | |
| ansatte_max | No | Maximum antal ansatte | |
| ansatte_min | No | Minimum antal ansatte | |
| branche_kode | No | DB25-branchekode (CVR har brugt DB25 siden 1.1.2025), fx "621000" for computerprogrammering. En DB07-kode (fx "620100") oversættes automatisk til DB25, og svaret forklarer oversættelsen. Slå koden op med cvr_branche_lookup. | |
| branche_soeg | No | Fritekst i branchenavn, fx "detail" | |
| loenom_trend | No | Lønomkostningstend (kræver noegletal-data) | alle |
| stiftet_foer | No | Stiftet før dato, ISO YYYY-MM-DD | |
| changed_since | No | Kun virksomheder opdateret siden denne dato (ISO YYYY-MM-DD) — Early Warning | |
| geo_soeg_type | No | Hvilke enheder geo-søgningen dækker: alle (default), kun virksomheder eller kun P-enheder | alle |
| stiftet_efter | No | Stiftet efter dato, ISO YYYY-MM-DD | |
| similar_to_cvr | No | Find virksomheder der ligner dette CVR: samme branche, ansatte i intervallet 0,3x–3x, og samme landsdel (udledt af referencens postnummer). Referencevirksomheden er selv udeladt af resultatet. Sætter du kommune eller postnummer, vinder dit filter over landsdelen. | |
| virksomhedsform | No | Virksomhedsform — angiv enten kode ("APS", "A/S", "ENK") eller navn ("Anpartsselskab", "Aktieselskab"). Se resource cvr://reference/virksomhedsform for hele kodelisten. | |
| geo_radius_meter | No | Søgeradius i meter (100–50.000). Returnerer virksomheder og P-enheder inden for denne radius, sorteret efter afstand. | |
| include_inactive | No | Inkludér ophørte virksomheder i ikke-geo søgning (default: false). Brug inkluder_ophorte i geo-søgning. | |
| inkluder_ophorte | No | Inkludér ophørte virksomheder og P-enheder i geo-søgning (default: false = kun aktive) | |
| medarbejder_stabilitet | No | Medarbejderstabilitet ±10% YoY = stabil, >10% = vaekst, <-10% = fald | alle |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavioral context on top: geo mode returns both virksomheder and P-enheder sorted by distance, similar_to_cvr excludes the reference company, and inkluder_ophorte/inactive handling differs between geo and non-geo. It still doesn't describe result shape or pagination in geo mode.
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?
Front-loads the purpose in sentence one, then dedicates one clause each to geo mode, count_only, groupBy, similar_to_cvr, and changed_since. Dense but every sentence carries actionable information; slightly long but no filler.
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?
For a 23-parameter tool with no output schema, the description covers the main operating modes (geo, aggregation, count-only, lookalike, change-tracking). It omits how results are structured/paginated outside geo mode and doesn't spell out the two-section return of geo mode beyond 'sorteret efter afstand', leaving minor gaps.
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?
Schema coverage is 100%, so the baseline is 3, but the description genuinely adds workflow semantics beyond the field docs: geo_lat/geo_lon/geo_radius_meter must be combined, count_only returns only counts, groupBy aggregates instead of listing entities, and similar_to_cvr defines the lookalike logic. These relationships are the value-add over the schema.
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 first sentence states a specific verb+resource: 'Bulk-screening og radius-søgning (geo) af virksomheder og P-enheder'. The 'bulk'/'geo' framing separates it at a glance from single-entity siblings like cvr_get_company and cvr_branche_lookup without needing to open any schema.
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?
Gives explicit per-feature usage instructions: count_only for a sanity check before heavy calls, groupBy for aggregated buckets, similar_to_cvr for lookalike search, changed_since for Early Warning. It does not name a sibling to avoid or state when-not to use it (e.g. vs cvr_get_company for single lookups), so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Viser status for seneste CVR-synkronisering: antal records, freshness og eventuelle fejl. Inkluderer friskheds-flag og ADVARSEL hvis delta-sync er mere end 24 timer gammel.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds useful behavior beyond that: it names the returned fields (record count, freshness, errors) and a concrete threshold – a WARNING when delta-sync exceeds 24 hours – which is real context an agent can act on.
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?
Two sentences with zero waste, front-loaded with the core purpose followed by the warning condition. Every clause earns its place.
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?
With no output schema and no parameters, the description carries the burden of explaining return content, and it does so adequately (counts, freshness, errors, warning flag). It is complete enough for a read-only status check, though it could note expected data sources or refresh cadence.
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 tool takes zero parameters, so the baseline is 4. There is nothing parameter-wise to clarify, and the description correctly adds no misleading parameter detail.
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?
States a specific verb ("Viser") and resource (status for the latest CVR sync), enumerating exactly what it reports: record count, freshness, and errors. This is clearly distinguishable from the data-lookup siblings (cvr_get_company, cvr_financial_analysis, etc.) since it is a system/health meta-tool.
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?
Usage is only implied – an agent can infer it is for checking sync health, but the description never says when to call it or what to do with the warning. No alternatives or exclusions are named, and no prerequisites are given.
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.
cvr_branche_lookupcvr_financial_analysiscvr_get_companycvr_ownership_networkcvr_resolve_entitycvr_risk_profilecvr_screen_companiescvr_sync_status
Add one secure layer between your agents and this server.