Skip to main content
Glama

Export companies to CSV (AT + DE)

export_companies_csv
Read-only

Beispiel: „Alle Steuerberatungskanzleien in Wien als CSV exportieren?“

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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "export_companies_csv"
  }
}

Input Schema

NameRequiredDescriptionDefault
sortNo
countryNoall
filtersNo
max_rowsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • 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"
      +}
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Goes well past the annotations: discloses that each call creates new short-lived export files auto-deleted after ~1 day, that download links are signed and valid ~60 minutes, that output is one CSV per country with semicolon separators and UTF-8 BOM, and that DE files omit financial columns to avoid false zeros. It also proactively resolves the apparent tension with readOnlyHint=true by stating it is read-only over company data while writing only ephemeral export artifacts.

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 motivating example, then purpose, then parameters, then return shape — a clean progression with no filler sentences. However, the block explaining the return payload overlaps with the tool's output schema, and the multi-paragraph layout is longer than strictly necessary for four optional parameters.

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 a fan-out export tool with a large nested filter object, the description covers scope, filtering equivalences, row ceilings, output layout, link lifetime, and degradation notices. An agent has everything needed to call it correctly and to interpret the result without further discovery.

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 load, and it does: all four top-level parameters are explained with defaults and constraints (max_rows default 1000 / max 10000, country AT|DE|all, filters and sort identical to search_companies semantics). The per-country sort limitation and filter-exclusion behavior add meaning the bare schema cannot express.

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 artifact: 'Export a matched company set as downloadable CSV files (lead lists)', scoped to AT + DE via the title. It explicitly contrasts with the sibling search_companies ('For browsing/ranking on screen use search_companies instead'), so an agent can separate export from search without reading either 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 a concrete triggering scenario (a lead-list style question in the opening example), names the alternative tool and the condition that selects it ('browsing/ranking on screen'). It also explains the fallback behavior when a filter is unsupported per country, so the agent knows what to expect rather than guessing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.