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 für KI-Agenten. Ein Agent kann Dateien lesen, schreiben und verschieben. Das löst die Grundlogik.

Aber es löst keine Datei-Transformation.

Wenn Ihr Agent nur Filesystem MCP hat, kann er weiterhin keine PDFs zusammenführen, keine EXIF-Daten entfernen, kein CSV in JSON konvertieren und keine großen Konfigurationsstände 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 übergibt 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 Fähigkeit.

Unten finden Sie 3 komplette Multi-Call-Workflows. Jeder Workflow enthält expected outputs und erklärt konkret, warum er Tokens und Zeit spart.

Workflow 1: Versandfertiges PDF-Paket in einem Durchlauf bauen

Sie haben einen Ordner mit Deckblatt, Vertrag, Anhängen und Signaturen. Ziel ist ein finales PDF mit Seitennummern, DRAFT-Wasserzeichen und kleinerer Dateigröße für 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 zusammenführen.
{
  "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 hinzufügen.
{
  "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. Für 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
  • Rückgabefelder 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 großer PDF-Stack geht von mehreren manuellen Schritten auf einen Prompt mit lokaler Tool-Kette.

Workflow 2: Publishing-Bilder im Agenten aufbereiten

Sie haben Screenshots für Release oder Dokumentation. Die Dateien sind zu groß, 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 prüfen.
{
  "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. Für 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
  • Rückgabefelder 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-Blöcke im Kontext, die Tokens verbrauchen ohne echten Reasoning-Wert.
  • Dieselbe Sequenz läuft stabil über ganze Verzeichnisse.
  • Sie bekommen eine wiederverwendbare Pipeline für Docs, Blog-Assets und Social-Bilder.

Workflow 3: Konfigurationsdateien normalisieren und diff-fähig machen

Sie erhalten Vendor-Konfigurationen in gemischten Formaten. Sie brauchen normalisierte Dateien, eine klare Änderungssicht und einen Checksum-Nachweis für 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 für 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) für 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 für Triage.
  • Der Checksum liefert einen stabilen Fingerprint für 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 ausführen.
  3. Agent-Reasoning: Reihenfolge entscheiden, Outputs validieren, Fallbacks steuern.

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

Wenn Ihr Agent nur Dateien öffnen kann, kann er die Aufgabe nicht abschließen. Geben Sie ihm pfadbasierte Transformationen und lassen Sie ihn orchestrieren.

Für vollständige Schemas und Beispiele nutzen Sie die MCP Tool Reference. Für den Start nehmen Sie den MCP Quickstart.

← Zurück zu allen Beiträgen