Filesystem MCP ne suffit pas : patterns de transforms locaux
Regarder le résumé vidéo
L’acces au systeme de fichiers est un bon debut pour un agent IA. Il peut lire des fichiers, en ecrire, les deplacer. C’est utile pour la plomberie de base.
Mais cela ne suffit pas pour le traitement de fichiers.
Si votre agent n’a que Filesystem MCP, il ne peut toujours pas fusionner des PDF, supprimer des EXIF, convertir du CSV en JSON, ou comparer proprement des snapshots de configuration. Vous retombez vite sur des scripts fragiles ou sur des blobs geants dans le contexte du modele.
C’est la qu’interviennent les outils de transformation par chemins. Avec le serveur MCP VaultTools, l’agent passe des chemins de fichiers aux outils locaux. Le traitement se fait sur votre machine. L’agent recoit des sorties structurees compactes, pas les octets bruts des fichiers.
Filesystem MCP donne la localisation. Transform MCP donne la capacite.
Voici 3 workflows complets en multi-calls que vous pouvez appliquer immediatement. Chacun inclut les sorties attendues et la raison concrete pour laquelle il economise des tokens et du temps.
Workflow 1 : Assembler un packet PDF pret a l’envoi en un seul flux
Vous avez un dossier avec page de garde, contrat, annexes et signatures. Vous voulez un PDF final avec numerotation, filigrane DRAFT, puis compression pour l’email.
Prompt operateur
Fusionne ces PDF dans l'ordre, ajoute les numeros de page plus un filigrane DRAFT, puis compresse et supprime les metadonnees. Garde toutes les sorties dans /Users/me/deals/acme/.
Sequence multi-calls
- Fusionner tous les fichiers source.
{
"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"
]
}
}
- Ajouter numerotation et filigrane.
{
"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
}
}
- Compresser pour l’envoi et supprimer les metadonnees.
{
"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- Champs de reponse comme
compressed_size,savings_percentetpage_count
Why this saves tokens/time
- Les octets PDF n’entrent jamais dans le contexte du modele. Vous recevez de petites reponses JSON avec chemins et metriques.
- L’agent n’a pas besoin d’inspecter chaque page comme texte ou image. Il orchestre des appels d’outils.
- Vous eliminez les aller-retours manuels : aucun site d’upload, aucun export, aucun renommage repetitif.
- Un gros dossier passe d’une succession d’actions manuelles a un prompt unique avec des appels locaux en chaine.
Workflow 2 : Preparer des images de publication sans quitter l’agent
Vous avez des captures pour docs ou release. Elles sont trop lourdes, contiennent des metadonnees camera et ne sont pas au bon format final.
Prompt operateur
Pour toutes les captures de release, supprime EXIF, redimensionne en 1200x630, convertis en WebP, puis compresse vers une qualite autour de 75.
Sequence multi-calls
- Inspecter les metadonnees avant traitement.
{
"tool": "vaulttools_image_exif_read",
"input": {
"path": "/Users/me/releases/v2/screenshot-01.jpg"
}
}
- Supprimer EXIF.
{
"tool": "vaulttools_image_exif_strip",
"input": {
"path": "/Users/me/releases/v2/screenshot-01.jpg",
"quality": 90
}
}
- Redimensionner pour OG et reseaux sociaux.
{
"tool": "vaulttools_image_resize",
"input": {
"path": "/Users/me/releases/v2/screenshot-01_no_exif.jpg",
"width": 1200,
"height": 630,
"maintain_aspect": true,
"quality": 90
}
}
- Convertir en WebP.
{
"tool": "vaulttools_image_convert",
"input": {
"path": "/Users/me/releases/v2/screenshot-01_no_exif_resized.jpg",
"output_format": "webp",
"quality": 82
}
}
- Passer une compression finale.
{
"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- Champs de reponse comme
savings_percent,output_size,widthetheight
Why this saves tokens/time
- Le modele ne recoit jamais les pixels. Il recoit seulement metadonnees de traitement et chemins de sortie.
- Vous evitez les blobs base64 dans le contexte, qui font exploser les tokens sans valeur de raisonnement.
- La meme sequence se rejoue sur un dossier complet. L’agent peut boucler de facon previsible.
- Vous obtenez un pipeline unique et reutilisable pour docs, blog, et assets social media.
Workflow 3 : Normaliser des configs texte et produire un diff exploitable
Vous recevez des configurations fournisseur dans des formats melanges. Vous avez besoin de fichiers normalises, d’une vision claire des changements et d’un checksum pour la release.
Prompt operateur
Convertis ce fichier YAML en JSON, puis en TOML, compare avec le TOML de la semaine derniere, et renvoie un resume du diff plus le checksum.
Sequence multi-calls
- Convertir YAML vers JSON.
{
"tool": "vaulttools_text_convert_format",
"input": {
"path": "/Users/me/configs/vendor-a.yaml",
"from_format": "yaml",
"to_format": "json"
}
}
- Convertir le JSON normalise vers TOML.
{
"tool": "vaulttools_text_convert_format",
"input": {
"path": "/Users/me/configs/vendor-a_converted.json",
"from_format": "json",
"to_format": "toml"
}
}
- Comparer ancien et nouveau TOML.
{
"tool": "vaulttools_text_diff",
"input": {
"original_path": "/Users/me/configs/vendor-a-lastweek.toml",
"modified_path": "/Users/me/configs/vendor-a_converted.toml"
}
}
- Calculer le checksum de l’artefact genere.
{
"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- Champs de hash (
md5,sha1,sha256,sha512) pour release notes ou logs CI
Why this saves tokens/time
- L’agent n’a pas besoin de charger des fichiers entiers dans le contexte pour comparer des versions.
- Les statistiques de diff (
added_lines,removed_lines,changed_lines) suffisent pour le triage. - Le checksum fournit une empreinte stable pour les handoffs et les audits.
- Vous reduisez les erreurs manuelles liees aux copier-coller entre outils.
Le pattern a reutiliser sur toutes les categories
Quand vous concevez des workflows agentiques, separez les responsabilites clairement :
- Filesystem MCP : decouverte des fichiers et coordination des chemins.
- Outils Transform MCP : traitement local deterministe.
- Raisonnement agent : choix de sequence, validation des sorties, fallback.
Cette separation rend l’automatisation locale a la fois sure et scalable. L’acces filesystem est necessaire, mais il ne suffit pas pour des transformations de production.
Si votre agent sait seulement ouvrir des fichiers, il ne peut pas finir le travail. Donnez-lui des transformations par chemins, puis laissez-le orchestrer.
Pour les schemas complets et exemples, consultez la reference des outils MCP. Pour l’installation, commencez par le quickstart MCP.