Handelsregister

Export companies to CSV (AT + DE)

export_companies_csv

Read-only

Export a matched company set as downloadable CSV files (lead lists). Read-only over company data; each call writes new short-lived export files (auto-deleted after ~1 day).

    Parameters:
    - filters (optional): EXACTLY the same unified filters as search_companies.
    - sort (optional): same as search_companies (applies where the country supports
      the field).
    - max_rows (optional, default 1000, max 10000): per-country row ceiling.
    - country (optional, default "all"): "AT" | "DE" | "all".

    Returns {countries: {<code>: {download_url, rows, columns, ...}}, notices}. ONE
    CSV per country (semicolon-separated, UTF-8 BOM, Excel-ready): each register
    exports its own column set - DE files have no financial columns yet (blank would
    wrongly read as zero). Download links are signed and valid ~60 minutes. A filter a
    country does not support excludes that country with a notice, like
    search_companies. For browsing/ranking on screen use search_companies instead.

Input Schema

TableJSON Schema

Name	Required	Default
`sort`	No
`country`	No	all
`filters`	No
`max_rows`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 20, 2026

addedInput schema / $defs / UnifiedSearchFilters / properties / nace_class

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Nace Class"
+}

addedInput schema / $defs / UnifiedSearchFilters / properties / oenace_class

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Oenace Class"
+}

addedInput schema / $defs / UnifiedSearchFilters / properties / wz_confidence_min

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Wz Confidence Min"
+}

First observedAug 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations declare readOnlyHint=true and destructiveHint=false, and the description enriches this by explaining the nuance: 'Read-only over company data; each call writes new short-lived export files (auto-deleted after ~1 day).' It also discloses download link expiry (~60 minutes), country-specific column differences (DE lacks financial columns to avoid falsely reading blanks as zero), and the notice behavior for unsupported filters. This is substantial behavioral context beyond the annotations, with no contradiction.

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 longer than average but well organized: a one-sentence purpose summary, a bulleted parameter list, then return format and behavioral caveats. Every sentence adds value, and the sibling distinction is placed at the end as a natural conclusion. Slightly verbose but justifiably so for a tool with nuanced export behavior.

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?

Covers purpose, parameters, return structure (per-country objects with download_url, rows, columns, notices), file format details (semicolon-separated, UTF-8 BOM, Excel-ready), deletion/expiry timelines, and country-specific column differences. Given the complexity of the underlying filters and the presence of an output schema, nothing critical is missing for an agent to select and invoke the tool correctly.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must carry the burden—and it does. Each parameter gets a meaningful explanation: filters are 'EXACTLY the same unified filters as search_companies,' sort applies 'where the country supports the field,' max_rows is a 'per-country row ceiling' with default/max stated, and country enumerates its allowed values. This goes well beyond the bare schema properties and defaults.

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?

States a specific verb and resource: 'Export a matched company set as downloadable CSV files (lead lists).' The title also clarifies scope (AT + DE), and the description clearly differentiates from search_companies by adding 'For browsing/ranking on screen use search_companies instead.' This leaves no ambiguity about what the tool does or how it differs from its closest sibling.

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?

Provides explicit usage context: the tool is for obtaining downloadable CSV lead lists, while on-screen browsing/ranking is explicitly routed to search_companies. It also notes that filters and sort behave 'exactly the same' as search_companies, giving the agent clear conditions for reuse and the boundary between the two tools.

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

All Handelsregister tools Inspect

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.