Tools / Blog / Filesystem MCP reicht nicht: Lokale Transform-Patterns

Filesystem MCP reicht nicht: Lokale Transform-Patterns

· Antoine H.

Videozusammenfassung ansehen

Filesystem-Zugriff ist ein guter Start fuer KI-Agenten. Ein Agent kann Dateien lesen, schreiben und verschieben. Das loest die Grundlogik.

Aber es loest keine Datei-Transformation.

Wenn Ihr Agent nur Filesystem MCP hat, kann er weiterhin keine PDFs zusammenfuehren, keine EXIF-Daten entfernen, kein CSV in JSON konvertieren und keine grossen Konfigurationsstaende sauber vergleichen. Am Ende landen Sie wieder bei fragilen Skripten oder riesigen In-Context-Blocks.

Genau hier helfen pfadbasierte Transform-Tools. Mit dem VaultTools MCP-Server uebergibt der Agent Dateipfade an lokale Tools. Die Verarbeitung bleibt auf Ihrer Maschine. Der Agent bekommt kompakte, strukturierte Ergebnisse statt roher Dateibytes.

Filesystem MCP liefert den Ort. Transform MCP liefert die Faehigkeit.

Unten finden Sie 3 komplette Multi-Call-Workflows. Jeder Workflow enthaelt expected outputs und erklaert konkret, warum er Tokens und Zeit spart.

Workflow 1: Versandfertiges PDF-Paket in einem Durchlauf bauen

Sie haben einen Ordner mit Deckblatt, Vertrag, Anhaengen und Signaturen. Ziel ist ein finales PDF mit Seitennummern, DRAFT-Wasserzeichen und kleinerer Dateigroesse fuer E-Mail.

Operator Prompt

Merge these PDFs in order, add page numbers plus DRAFT watermark, then compress and strip metadata. Keep all outputs in /Users/me/deals/acme/.

Multi-Call Sequence

  1. Alle Quelldateien zusammenfuehren.
{
  "tool": "vaulttools_pdf_merge",
  "input": {
    "paths": [
      "/Users/me/deals/acme/cover.pdf",
      "/Users/me/deals/acme/contract.pdf",
      "/Users/me/deals/acme/annex-a.pdf",
      "/Users/me/deals/acme/signatures.pdf"
    ]
  }
}
  1. Seitennummern und Wasserzeichen hinzufuegen.
{
  "tool": "vaulttools_pdf_annotate",
  "input": {
    "path": "/Users/me/deals/acme/cover_merged.pdf",
    "add_page_numbers": true,
    "page_number_position": "bottom-center",
    "page_number_prefix": "Page ",
    "add_watermark": true,
    "watermark_text": "DRAFT",
    "watermark_opacity": 0.12
  }
}
  1. Fuer Versand komprimieren und Metadaten entfernen.
{
  "tool": "vaulttools_pdf_compress",
  "input": {
    "path": "/Users/me/deals/acme/cover_merged_annotated.pdf",
    "quality": 60,
    "max_dimension": 1600,
    "strip_metadata": true
  }
}

Expected outputs

  • /Users/me/deals/acme/cover_merged.pdf
  • /Users/me/deals/acme/cover_merged_annotated.pdf
  • /Users/me/deals/acme/cover_merged_annotated_compressed.pdf
  • Rueckgabefelder wie compressed_size, savings_percent und page_count

Why this saves tokens/time

  • PDF-Bytes gehen nie in den Modellkontext. Sie bekommen nur kleine JSON-Antworten mit Pfaden und Kennzahlen.
  • Der Agent muss nicht jede Seite als Text oder Bild analysieren. Er orchestriert Tool-Aufrufe.
  • Manuelle Wechsel entfallen: kein Upload-Tool, kein Export, kein ständiges Umbenennen.
  • Ein grosser PDF-Stack geht von mehreren manuellen Schritten auf einen Prompt mit lokaler Tool-Kette.

Workflow 2: Publishing-Bilder im Agenten aufbereiten

Sie haben Screenshots fuer Release oder Dokumentation. Die Dateien sind zu gross, enthalten Kamera-Metadaten und liegen nicht im Zielformat vor.

Operator Prompt

For all release screenshots, remove EXIF, resize to 1200x630, convert to WebP, then compress to around quality 75.

Multi-Call Sequence

  1. Metadaten vorab pruefen.
{
  "tool": "vaulttools_image_exif_read",
  "input": {
    "path": "/Users/me/releases/v2/screenshot-01.jpg"
  }
}
  1. EXIF entfernen.
{
  "tool": "vaulttools_image_exif_strip",
  "input": {
    "path": "/Users/me/releases/v2/screenshot-01.jpg",
    "quality": 90
  }
}
  1. Fuer OG und Social auf 1200x630 bringen.
{
  "tool": "vaulttools_image_resize",
  "input": {
    "path": "/Users/me/releases/v2/screenshot-01_no_exif.jpg",
    "width": 1200,
    "height": 630,
    "maintain_aspect": true,
    "quality": 90
  }
}
  1. In WebP konvertieren.
{
  "tool": "vaulttools_image_convert",
  "input": {
    "path": "/Users/me/releases/v2/screenshot-01_no_exif_resized.jpg",
    "output_format": "webp",
    "quality": 82
  }
}
  1. Finale Kompression anwenden.
{
  "tool": "vaulttools_image_compress",
  "input": {
    "path": "/Users/me/releases/v2/screenshot-01_no_exif_resized_converted.webp",
    "quality": 75
  }
}

Expected outputs

  • /Users/me/releases/v2/screenshot-01_no_exif.jpg
  • /Users/me/releases/v2/screenshot-01_no_exif_resized.jpg
  • /Users/me/releases/v2/screenshot-01_no_exif_resized_converted.webp
  • /Users/me/releases/v2/screenshot-01_no_exif_resized_converted_compressed.webp
  • Rueckgabefelder wie savings_percent, output_size, width und height

Why this saves tokens/time

  • Das Modell sieht keine Pixeldaten. Es sieht nur Prozessmetadaten und Ausgabepfade.
  • Sie vermeiden Base64-Bloecke im Kontext, die Tokens verbrauchen ohne echten Reasoning-Wert.
  • Dieselbe Sequenz laeuft stabil ueber ganze Verzeichnisse.
  • Sie bekommen eine wiederverwendbare Pipeline fuer Docs, Blog-Assets und Social-Bilder.

Workflow 3: Konfigurationsdateien normalisieren und diff-faehig machen

Sie erhalten Vendor-Konfigurationen in gemischten Formaten. Sie brauchen normalisierte Dateien, eine klare Aenderungssicht und einen Checksum-Nachweis fuer Release-Notes.

Operator Prompt

Convert this YAML config to JSON, then to TOML, compare it with last week's TOML, and return a diff summary plus checksum.

Multi-Call Sequence

  1. YAML nach JSON konvertieren.
{
  "tool": "vaulttools_text_convert_format",
  "input": {
    "path": "/Users/me/configs/vendor-a.yaml",
    "from_format": "yaml",
    "to_format": "json"
  }
}
  1. Das normalisierte JSON nach TOML konvertieren.
{
  "tool": "vaulttools_text_convert_format",
  "input": {
    "path": "/Users/me/configs/vendor-a_converted.json",
    "from_format": "json",
    "to_format": "toml"
  }
}
  1. Altes und neues TOML vergleichen.
{
  "tool": "vaulttools_text_diff",
  "input": {
    "original_path": "/Users/me/configs/vendor-a-lastweek.toml",
    "modified_path": "/Users/me/configs/vendor-a_converted.toml"
  }
}
  1. Checksum fuer das erzeugte Artefakt berechnen.
{
  "tool": "vaulttools_file_checksum",
  "input": {
    "path": "/Users/me/configs/vendor-a_converted.toml"
  }
}

Expected outputs

  • /Users/me/configs/vendor-a_converted.json
  • /Users/me/configs/vendor-a_converted.toml
  • /Users/me/configs/vendor-a-lastweek_diff.json
  • Hash-Felder (md5, sha1, sha256, sha512) fuer Release-Notes oder CI-Logs

Why this saves tokens/time

  • Der Agent muss keine kompletten Konfigurationsdateien in den Kontext laden, nur um Versionen zu vergleichen.
  • Diff-Statistiken (added_lines, removed_lines, changed_lines) reichen fuer Triage.
  • Der Checksum liefert einen stabilen Fingerprint fuer Handoff und Audit.
  • Sie vermeiden manuelle Copy-Paste-Fehler zwischen mehreren Tools.

Das wiederverwendbare Pattern

Wenn Sie Agent-Workflows designen, trennen Sie die Rollen klar:

  1. Filesystem MCP: Dateien finden und Pfade koordinieren.
  2. Transform MCP Tools: deterministische lokale Verarbeitung ausfuehren.
  3. Agent-Reasoning: Reihenfolge entscheiden, Outputs validieren, Fallbacks steuern.

Diese Trennung macht lokale Automatisierung sicher und skalierbar. Filesystem-Zugriff ist notwendig, aber fuer produktive Transformationen nicht ausreichend.

Wenn Ihr Agent nur Dateien oeffnen kann, kann er die Aufgabe nicht abschliessen. Geben Sie ihm pfadbasierte Transformationen und lassen Sie ihn orchestrieren.

Fuer vollstaendige Schemas und Beispiele nutzen Sie die MCP Tool Reference. Fuer den Start nehmen Sie den MCP Quickstart.

← Zurück zu allen Beiträgen