agentic-firmenbuch

Overview Schema Source Related Servers Discussions Admin

Export companies to CSV

export_companies_csv

Read-only

Export the full result set of a company search as one downloadable, ready-to-open CSV list for Excel or import, instead of paging through 25 rows at a time.

Instructions

Export a whole search result set as ONE downloadable CSV file (a lead list) instead of paging through search_companies 25 rows at a time. Read-only over company data; each call writes a new short-lived export file (auto-deleted after ~1 day).

    Use this when the user wants a list to open in Excel / import elsewhere ("exportiere",
    "als CSV/Liste", "alle GmbHs in … herunterladen"). For browsing or ranking on screen use
    search_companies; for one company's full profile use get_company_details.

    Parameters:
    - filters (optional): a SearchFilters object — EXACTLY the same filters as search_companies
      (name; legal_form; bundesland/city/postal_code; near radius; oenace_division/group /
      geschaeftszweig; size_gkl; bilanzsumme / revenue / equity_ratio / employees ranges
      (equity_ratio as a fraction, 0.35 = 35 %; percent values auto-converted);
      growth_profile; founded/last-filing years; gf_age_min; manager_name; status). AND-joined.
    - sort (optional): {field, descending}, same fields as search_companies (default bilanzsumme
      descending; "distance" with a near filter).
    - max_rows (optional, default 1000, hard maximum 10000): row ceiling. Free plan is capped at
      100 rows with basic columns only. For a set larger than 10000, refine the filters
      (Bundesland/Branche/Größe) and export in parts.

    CSV format: semicolon-separated, UTF-8 with BOM (opens cleanly in Excel-DE, umlauts intact).
    Columns are exactly the search card fields: fnr, name, legal_form, street, postal_code,
    city, bundesland, industry_section, oenace_division(+label), geschaeftszweig, size_gkl,
    bilanzsumme_latest, equity_ratio_latest, revenue_latest, growth_profile, manager_name, and
    distance_km when a near filter is used. Empty values are blank cells. No fields beyond the
    card — the same personal-data gating applies.

    Returns {rows, download_url, expires_minutes (60), columns, truncated, note}. The
    download_url is a signed link valid for 60 minutes (3600 s; exact expiry in
    `download.expires_at` — open it promptly, don't expect bytes inline); the underlying
    file is deleted after about one day. When the result was capped (truncated=true), the
    note says so and asks you to refine.
    Field reference: https://www.agentic-firmenbuch.at/felder.html

Input Schema

TableJSON Schema

Name	Required	Description	Default
`sort`	No
`filters`	No
`max_rows`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Oct 3, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false), but the description adds substantial context beyond them: each call creates a new short-lived export file auto-deleted after ~1 day, the download_url is a signed link valid 60 minutes (with exact expiry in download.expires_at), bytes are not returned inline, the free plan is capped at 100 rows with basic columns, and truncated=true signals a capped result. It also reconciles the read-only hint with the file-writing side effect ("Read-only over company data; each call writes a new short-lived export file"), which is exactly the nuance idempotentHint=false implies.

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

Conciseness5/5

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

Despite its length, the text is front-loaded (purpose and side effects first, then usage, parameters, CSV format, returns) and every block earns its place given the 0% schema coverage and the non-obvious signed-URL/expiry behavior. No filler or repetition.

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?

Complete for a complex export tool: it documents filters, sort, row limits, plan caps, CSV encoding/columns, truncation behavior, and the download-link lifecycle, even though an output schema exists. It also notes the personal-data gating and provides a field-reference URL, leaving no material gap for correct invocation.

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?

Top-level schema description coverage is 0%, so the description carries the full burden and does: filters is documented as an AND-joined SearchFilters with the same semantics as search_companies (including the equity_ratio-as-fraction rule and auto-conversion of percent values), sort is described with its default (bilanzsumme descending) and the "distance" option, and max_rows is given its default 1000, hard maximum 10000, and the free-plan 100-row cap. This adds meaning well beyond the bare object schema.

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+resource+scope: exporting a whole search result set as ONE downloadable CSV instead of paging through search_companies. It explicitly contrasts itself with two named siblings (search_companies for browsing, get_company_details for a profile), so an agent can disambiguate without opening schemas.

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 when-to-use triggers, including multilingual user phrasings ("exportiere", "als CSV/Liste", "alle GmbHs in … herunterladen"), plus when-not: use search_companies for on-screen browsing/ranking, get_company_details for a single profile. Also states the workaround when the set exceeds 10,000 rows (refine filters and export in parts).

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

Deploy Server