Skip to main content
Glama

nordic-data

by io.github.Mnymann

kyb_full

Read-onlyIdempotent

Run before a consequential decision — onboarding a counterparty, approving a payment, extending credit, or signing a contract. Full Know-Your-Business master report for a company across 15 EU countries (DK, NO, SE, FI, IE, UK, FR, DE, CZ, PL, LV, EE, NL, BE, LU). Aggregates 9 sections: identity, registered address (geocoded), key persons & directors, financial statements, official filings, LEI + corporate ownership, VAT registration, sanctions + PEP screening, adverse media (GDELT 2.0), and a composite risk score. Single call. Cold cache typically completes in 10-15s; warm cache returns in <100ms. Cached 6h on success, 60s when partial. Partial responses: if any of the 9 sections time out, the report still returns with 'truncated: true' and 'sectionsUnavailable: [{section, reason}]' — caller can retry in 60s for a complete report. Tier note: NL and DE use paid upstream registries — free-tier API keys receive HTTP 402 'upgrade_required'; do NOT retry on 402. On paid tiers, NL costs 5x quota and DE costs 3x. Disclaimer: this report is informational decision-support aggregated from official and public sources — NOT legal, compliance, or financial advice and not a definitive determination. The risk score and findings indicate areas to verify, not verdicts; the response includes a 'disclaimer' field stating this.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesNational company identifier — same format as lookup_company (e.g. DK CVR 8 digits, NO orgnr 9 digits).
countryYesISO 3166-1 alpha-2 country code, lowercase.

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already establish readOnly/idempotent/non-destructive, and the description dramatically extends this with rich behavioral disclosures: cold vs warm cache timing, 6h/60s cache policies, partial response structure ('truncated: true', 'sectionsUnavailable'), the 402 upgrade_required retry warning, and quota costs for NL/DE. It also adds a legal disclaimer clarifying the report is informational, not a definitive determination.

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

Conciseness3/5

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

The content is information-dense and valuable, but it's a single large paragraph covering many distinct concerns (purpose, performance, caching, partial responses, tier caveats, legal disclaimer) with no structural separation. Front-loading is good (opens with use cases), but a long block of text is harder for an agent to parse than a structured or bulleted layout.

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?

This is a complex, high-consequence tool with no output schema, so the description carries the full burden — and it meets it comprehensively: 9 sections enumerated, country list, performance expectations, partial-response handling, retry semantics, tier-specific costs, and legal framing. Every ambiguity an agent might face is addressed.

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% — both id and country already carry descriptive text (with format hints like 'CVR 8 digits' and enum values). The description adds the reference to lookup_company for the id format, which adds a small cross-tool tie-in, but mostly the schema handles parameters. Baseline 3 is appropriate since the description doesn't add significant param semantics beyond schema coverage.

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 opens with a concrete use-case framing ('Run before a consequential decision...') and specifies the exact output ('Full Know-Your-Business master report') with country scope and a detailed list of the 9 aggregated sections. It clearly distinguishes from siblings like lookup_company, screen_sanctions, and validate_vat by covering the full composite report across 15 countries.

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?

The description explicitly states when to use ('before onboarding a counterparty, approving a payment, extending credit, signing a contract'), covers caching behavior, partial-response retry semantics, and includes a crucial tier note (NL/DE paid registries, do NOT retry on 402). This gives the agent strong decision guidance on when the tool is appropriate and what pitfalls to avoid.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation5/5

Each tool targets a clearly distinct function: address autocomplete, company lookup, enriched company data, KYB report, LEI lookup, sanctions screening, VAT validation, French history, and three discovery meta-tools. The discovery tools (list_endpoints, get_endpoint_schema, call_endpoint) form a clean trio with distinct roles. There is minor overlap between company_enriched, kyb_full, and lookup_company, but their scopes are well-differentiated in the descriptions.

Naming Consistency4/5

The naming pattern is largely consistent with noun-based descriptive names (company_enriched, lookup_company, lookup_lei, validate_vat, screen_sanctions, autocomplete_address). Three discovery tools use verb-based names (list_endpoints, get_endpoint_schema, call_endpoint), and fr_history breaks the pattern as a country-specific tool. Minor inconsistency but readable and predictable overall.

Tool Count4/5

11 tools is within a reasonable range for a data-provider server that covers 15 countries and multiple data domains (entities, sanctions, VAT, addresses, LEI). Each tool addresses a distinct need. Slightly heavy given some overlap, but the count is justified by the breadth of coverage.

Completeness4/5

The core business-intelligence surface is well covered: company lookup, enriched data, full KYB, LEI, sanctions, VAT, address autocomplete, and French history. The discovery meta-tools (list_endpoints, get_endpoint_schema, call_endpoint) elegantly bridge gaps by exposing 230+ additional endpoints. Minor gaps: no dedicated UK-specific or non-French history tool, and screening is limited to sanctions/PEP without a dedicated adverse-media tool separate from kyb_full.

Resources