Skip to main content
Glama
Sign In
csv2zugferd

csv2zugferd

by rillsoft
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Save configuration file

csv2zugferd_config_file_create
DestructiveIdempotent

Validates a CSV-to-ZUGFeRD mapping configuration and saves it as UTF-8 without BOM to a target path, replacing files only with overwrite enabled. Returns the path, size, and CLI command.

Instructions

Validates configYaml (it must deserialize as a csv2zugferd configuration) and writes it to configPath as UTF-8 without BOM. An existing file is replaced only with overwrite: true; otherwise the call is rejected with file_exists and nothing is written. Returns the full path, the size and the csv2zugferd CLI command that uses the saved file for production runs. Does not run the mapping (use csv2zugferd_invoice_get first) and does not create XML or PDF files.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "configYaml": "<configYaml>",
      "configPath": "<configPath>"
    },
    "name": "csv2zugferd_config_file_create"
  }
}

Input Schema

NameRequiredDescriptionDefault
csvPathNoOptional CSV path inserted into the returned CLI command instead of a placeholder.
overwriteNoTrue replaces an existing file at configPath. Default false: an existing file is never touched (file_exists).
configPathYesTarget file path, for example C:/invoices/config.yml. The directory must exist.
configYamlYesThe YAML configuration to save (content of the file).

Output Schema

NameRequiredDescriptionDefault
bytesYesSize of the written file in bytes (UTF-8 without BOM).
cliCommandYesComplete csv2zugferd CLI command for a production run with this configuration; placeholders in angle brackets mark paths that were not given.
configPathYesFull path of the written file.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is partly covered. The description adds real value beyond them: encoding (UTF-8, no BOM), the file_exists rejection with nothing written, and the fact that an existing file is only replaced with overwrite:true. It doesn't discuss permissions or failure modes for invalid YAML beyond the validation mention, which keeps it below a 5.

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 front-loaded with the core action and validation, then covers overwrite behavior, return values and exclusions in compact sentences. It is somewhat dense but every sentence carries information; only the return-value sentence is arguably redundant given the output schema exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a file-writing tool with an output schema and full annotation coverage, the description covers validation, encoding, overwrite behavior, error signaling and return contents. The output schema means return values needn't be explained in detail, though the description repeats them anyway; permissions and directory-missing behavior are left to the schema.

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%, so the schema already documents all four parameters, including overwrite's default-false behavior and csvPath's role. The description reinforces the overwrite semantics and the configYaml validation requirement but adds little syntax or format detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 states a specific verb and resource: validates a configYaml and writes it to configPath as UTF-8 without BOM. It also explicitly names what it does not do (run the mapping, create XML/PDF) and points to csv2zugferd_invoice_get, distinguishing it from siblings like csv2zugferd_config_get and csv2zugferd_config_schema_get.

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?

It gives explicit when-not guidance ('Does not run the mapping (use csv2zugferd_invoice_get first)') and states the precondition that configYaml must deserialize as a csv2zugferd configuration. The overwrite:true requirement is spelled out as the condition under which an existing file is replaced, so the agent knows when the call will be rejected.

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

Deploy Server

Other Tools