Connecter Ollama aux bases de données et APIs via MCP : configuration d'agent local 2026

Faits rapides

• Protocole : JSON-RPC 2.0 sur stdio (sous-processus local) ou HTTP/SSE (distant). Les agents locaux utilisent presque exclusivement stdio.
• Maintenu par : Anthropic (spécification open source) ; serveurs de référence dans modelcontextprotocol/servers sur GitHub, plus un écosystème tiers en croissance.
• Clients locaux en 2026 : Goose (Block), Cline (extension VS Code), Continue.dev (VS Code/JetBrains), LM Studio (application desktop), plus plusieurs CLIs.
• Modèles Ollama compatibles : tout modèle entraîné nativement aux appels d'outils. En mai 2026 : Gemma 4 27B, GLM-5.1 32B, Qwen3 32B, Qwen3-Coder 30B, Llama 3.3 70B.
• Transports par défaut : stdio pour les processus locaux ; HTTP/SSE uniquement pour partager un serveur entre plusieurs machines ou agents.
• Configuration dans un seul fichier : ~/.config/goose/config.yaml (Goose), le bloc MCP de ~/.continue/config.json (Continue.dev) ou mcpServers dans l'UI de Cline. Même forme partout : nom du serveur, command, args, variables d'environnement.
• Pas besoin de Claude Desktop. Le protocole précède la stratégie d'exclusivité de Claude Desktop ; tous les serveurs de référence sont sous licence MIT/Apache et tournent contre n'importe quel client conforme.

Ce que MCP débloque pour un modèle local

• **« Trouve chaque TODO de ce dépôt, regroupe-les par fichier et écris un résumé Markdown dans notes/todos.md. »** — le serveur filesystem lit, le modèle regroupe, le même serveur écrit. Un seul aller-retour.
• « Montre-moi le top 10 des clients par chiffre d'affaires ce trimestre, puis trace un graphique. » — le serveur postgres exécute la requête (rôle en lecture seule), le modèle synthétise et écrit un CSV via filesystem pour votre outil de visualisation.
• « Ouvre la une de Hacker News, trouve les trois articles IA principaux, résume-les et ajoute-les à ma liste de lecture. » — le serveur puppeteer pilote un navigateur headless, le modèle extrait et résume, filesystem ajoute.
• **« Ouvre un PR draft chore: bump deps sur mon fork et lie l'exécution CI en échec. »** — le serveur github crée le PR, récupère l'exécution et écrit le lien dans la description.
• **« Regarde les 100 dernières lignes de events.db et dis-moi quels user IDs sont responsables du nouveau pic d'erreurs. »** — le serveur sqlite requête, le modèle raisonne, vous lisez la réponse dans le panneau de chat.
• Chacun de ces flux est un workflow phrase-vers-action qui demandait auparavant soit un modèle cloud avec des outils hébergés, soit un script à la main. MCP est la couche qui vous permet de réutiliser les mêmes serveurs entre clients et le même modèle entre serveurs.

Comparatif des quatre serveurs MCP les plus utilisés

Comment les pièces s'emboîtent

• Ollama tourne en service en arrière-plan sur 127.0.0.1:11434 et sert le modèle via une API compatible OpenAI. Il ne sait pas ce qu'est MCP — il répond simplement aux chat completions et émet des appels d'outils quand le modèle les demande.
• Le client MCP (Goose, Cline, Continue.dev, LM Studio) est le pont. Il parle à Ollama pour le modèle et aux serveurs MCP pour les outils. Quand le modèle émet un appel d'outil, le client le route vers le bon serveur, récupère le résultat et le réinjecte dans la conversation.
• Les serveurs MCP sont des sous-processus indépendants, un par capacité. Ils parlent JSON-RPC 2.0 sur stdio. Chaque serveur déclare une liste de Tools, Resources et Prompts ; le client fusionne tout en une surface d'outils unique présentée au modèle.
• Le transport stdio garde tout en local. Le serveur est lancé par le client, communique via stdin/stdout et se termine quand le client se termine. Rien ne passe par le réseau sauf si le serveur ouvre lui-même une connexion (le serveur navigateur le fait ; les serveurs filesystem et base ne le font pas).
• Le modèle voit une liste d'outils plate. Du point de vue du modèle, il n'y a pas de serveurs — juste une liste de noms comme filesystem.read_file, sqlite.query, puppeteer.navigate. Le client gère le routage.

Configuration : Ollama + Goose en 15 minutes

• Étape 1 — installer Ollama. Téléchargez depuis ollama.com/download (macOS/Windows/Linux). Vérifiez que le service tourne avec curl http://127.0.0.1:11434/api/tags.
• Étape 2 — récupérer un modèle compatible tool calling. Choisissez parmi Gemma 4 27B (gemma4:27b), GLM-5.1 32B (glm5:32b), Qwen3 32B (qwen3:32b) ou Llama 3.3 70B (llama3.3:70b). 16 Go de mémoire unifiée ou 12 Go de VRAM gèrent confortablement 27B–32B en Q4_K_M.
• Étape 3 — installer Goose. pipx install goose-ai (macOS, Linux) ou téléchargez l'installateur depuis la page Goose Releases. La CLI s'installe sous le nom goose.
• Étape 4 — configurer Ollama comme provider. Lancez goose configure, choisissez ollama comme provider, fixez le modèle sur celui que vous avez récupéré et le host sur http://127.0.0.1:11434. Goose écrit cela dans ~/.config/goose/config.yaml.
• Étape 5 — ajouter le serveur MCP filesystem. Éditez ~/.config/goose/config.yaml pour ajouter un bloc mcpServers (exemple ci-dessous). Relancez goose session et demandez la liste des fichiers dans votre répertoire de test. Le premier tour confirme que le serveur est bien câblé.
• Étape 6 — vérifier avec une vraie tâche. Essayez goose session et demandez « Fais une liste de chaque fichier Markdown dans notes/, avec titre et nombre de mots, et écris le résultat dans notes/index.md. » Si l'agent lit, résume et réécrit, la boucle fonctionne.

# 1. Pull a tool-calling model
ollama pull gemma4:27b

# 2. Install Goose
pipx install goose-ai

# 3. Configure Ollama as the provider
goose configure
# Provider: ollama
# Model:    gemma4:27b
# Host:     http://127.0.0.1:11434

# 4. Start a session — Goose reads ~/.config/goose/config.yaml
goose session

Serveur filesystem : lire et écrire dans un répertoire isolé

• Installation : le serveur de référence est @modelcontextprotocol/server-filesystem, exécuté via npx -y (pas besoin d'install globale). Goose, Cline et Continue.dev le lancent automatiquement depuis le bloc de configuration.
• Allow-lister les chemins : le serveur prend un ou plusieurs arguments de répertoire et refuse toute opération en dehors. Donnez toujours un chemin explicite et étroit — jamais ~ ni /.
• Outils exposés : read_file, read_multiple_files, write_file, edit_file (remplacements ligne par ligne), list_directory, search_files, move_file, create_directory, directory_tree. Le modèle les voit comme filesystem.read_file et ainsi de suite.
• Confort : directory_tree retourne un arbre JSON ; idéal pour que le modèle s'oriente avant de lire des fichiers précis. search_files fait une recherche récursive façon grep.
• Surface de risque : le serveur respecte l'allow-list, mais à l'intérieur il a tous les droits lecture/écriture. Traitez l'allow-list comme la seule barrière et choisissez un répertoire workspace dédié plutôt que votre home.

# ~/.config/goose/config.yaml
mcpServers:
  filesystem:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-filesystem"
      - "/Users/you/agent-workspace"
    env: {}

Serveurs SQLite et Postgres : interroger de vraies données

• **Serveur SQLite (@modelcontextprotocol/server-sqlite)** prend un chemin vers un fichier .db. Utile pour l'analyse de logs, le prototypage de schémas et l'exploration d'exports sans monter une base.
• **Serveur Postgres (@modelcontextprotocol/server-postgres)** prend une connection string. Le pattern recommandé est de créer un rôle dédié en lecture seule pour l'agent et d'utiliser sa connection string.
• Outils exposés : query (SELECT uniquement si configuré en lecture seule), list_tables, describe_table. Le serveur Postgres ajoute list_schemas. Certains forks ajoutent write_query — laissez-le désactivé sauf si vous faites confiance au modèle sur cette base.
• Connaissance du schéma : demandez à l'agent « liste les tables et décris les cinq plus utilisées » avant les questions analytiques — le modèle est bien plus précis quand il a appelé describe_table que quand il devine les noms de colonnes.
• Coût : les requêtes touchent votre base directement. Un SELECT * mal formé sur une table de 100 M de lignes est le même incident ici qu'avec un humain — gardez le rôle dans un pool de connexions séparé avec un statement timeout.

# ~/.config/goose/config.yaml
mcpServers:
  sqlite:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-sqlite"
      - "--db-path"
      - "/Users/you/data/events.db"
    env: {}

  postgres:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-postgres"
      - "postgresql://agent_ro@127.0.0.1:5432/analytics"
    env:
      PGPASSWORD: "${PG_AGENT_PASSWORD}"

Serveur navigateur : piloter Chromium avec Puppeteer ou Playwright

• Serveurs de référence : @modelcontextprotocol/server-puppeteer (plus léger, headless par défaut) et @modelcontextprotocol/server-playwright (plus lourd, supporte plusieurs navigateurs). Pour des agents locaux, Puppeteer suffit.
• Outils exposés : navigate, screenshot, click, fill, select, evaluate (exécuter du JavaScript), get_page_content. Le modèle utilise get_page_content pour lire le texte structuré et screenshot pour vérifier visuellement.
• Latence : une vraie session navigateur prend 1 à 5 secondes par action. Une navigation multi-étapes consomme facilement 30 à 60 secondes et des dizaines de milliers de tokens parce que le contenu des pages est volumineux. Visez une fenêtre de contexte de 32K+.
• Sélecteurs : le modèle doit choisir des sélecteurs CSS. Les petits modèles se trompent souvent ; un modèle 27B+ entraîné aux outils gère les patterns courants de manière fiable. Cadrez les tâches — « extrais le titre et le premier paragraphe de cette URL » est bien plus fiable que « navigue le site et trouve la page contact ».
• Bons cas d'usage : recherche (ouvrir la page, résumer, ajouter aux notes), tests de régression (naviguer, cliquer, screenshot) et remplissage de formulaires sur des pages que vous contrôlez. Mauvais cas : tout ce où un mauvais clic sur le web live a des conséquences.

# ~/.config/goose/config.yaml
mcpServers:
  puppeteer:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-puppeteer"
    env:
      PUPPETEER_HEADLESS: "true"
      # Block obviously dangerous endpoints at the OS firewall level
      # rather than relying on the agent to refuse them.

Serveur GitHub : dépôts, issues et PRs depuis un modèle local

• Installation : @modelcontextprotocol/server-github, exécuté avec un PAT dans la variable d'environnement GITHUB_PERSONAL_ACCESS_TOKEN. Le token est la seule auth — le serveur lui-même n'a pas de configuration séparée.
• Outils exposés : search_repositories, get_file_contents, create_or_update_file, create_pull_request, list_issues, create_issue, add_issue_comment, merge_pull_request, plus des dizaines d'autres. La surface complète est large ; la plupart des tâches utilisent 5 à 10 outils.
• Restreignez le PAT. Utilisez un PAT fine-grained scopé à des dépôts précis avec les permissions minimales nécessaires (Read pour la navigation, Write pour la création de PR/issues). N'utilisez pas un PAT classique avec repo pour un agent expérimental.
• Workflows réels : triage (« lis les 20 dernières issues ouvertes, regroupe-les, propose des labels »), brouillonnage (« lis le README et ouvre un PR corrigeant les fautes »), reporting (« quels PRs sont stale cette semaine »).
• Surface de risque : l'agent peut créer des issues et des PRs, commenter et (avec les droits d'écriture) pousser des commits. Désactivez les outils de merge sauf si vous faites confiance au modèle ET au workflow — un merge raté dans un dépôt avec PAT fine-grained est récupérable, mais seulement si vous le voyez vite.

# ~/.config/goose/config.yaml
mcpServers:
  github:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-github"
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "${GH_AGENT_PAT}"
      # Fine-grained PAT scoped to one or two test repos,
      # not your personal account-wide classic token.

Un modèle de sécurité qui ne fait pas confiance au modèle

• Limitez le serveur filesystem à un répertoire. Jamais ~ ni /. Choisissez un dossier agent-workspace/ et mettez-y des copies des fichiers que l'agent doit toucher. Si l'agent dérape, le pire cas est un dossier.
• Faites tourner les serveurs base en lecture seule par défaut. Un rôle dédié agent_ro avec uniquement des grants SELECT et un statement timeout de 30 secondes élimine toute une classe d'incidents.
• Mettez chaque outil d'écriture ou de shell derrière une approbation explicite. Goose, Cline et Continue.dev supportent tous des règles d'approbation par outil. Auto-approuvez les outils de lecture par défaut ; exigez une approbation pour write_file, edit_file, execute_command, create_pull_request et toute action navigateur qui soumet un formulaire.
• Utilisez le journal d'audit. Chaque client MCP loggue les appels d'outils et leurs résultats. Après une session longue, parcourez le log : vous attraperez le modèle en train d'essayer des choses inattendues (parfois inoffensives, parfois justifiant un resserrement des permissions).
• Restreignez étroitement l'accès aux services tiers. PATs GitHub limités à deux dépôts de test. Rôles Postgres en lecture seule. Sessions navigateur sans identifiants. Le modèle finira par essayer des choses que vous n'avez pas anticipées ; les limites de ce qu'il peut faire ne doivent pas dépendre de sa bonne volonté.
• Air-gap l'agent pour les données sensibles. Désactivez l'accès réseau sur l'host pendant l'exécution de l'agent (ou utilisez un network namespace) pour les données privées. La pile locale n'envoie déjà rien dehors, mais la défense en profondeur rattrape les erreurs des serveurs tiers.
• Traitez le choix d'un serveur MCP comme tout choix de dépendance. Les serveurs de référence sont bien maintenus ; beaucoup de serveurs tiers ne le sont pas. Lisez le code d'un serveur avant d'en installer un qui demande des identifiants.

MCP local vs Claude Desktop : ce qui change, ce qui reste

Choisir un modèle compatible tool calling pour MCP local

• **Gemma 4 27B (gemma4:27b)** — l'entraînement tool calling de Google est best-in-class pour la taille. Tient en 16 Go de mémoire unifiée ou 24 Go de VRAM en Q4_K_M. Bon raisonnement général ; un peu conservateur sur les chaînes d'appels d'outils.
• **GLM-5.1 32B (glm5:32b)** — le modèle de Zhipu a une fiabilité tool calling très forte et une fenêtre de contexte 128K d'origine. Légèrement plus lourd que Gemma 4 ; tient confortablement sur un GPU 24 Go.
• **Qwen3 32B (qwen3:32b) — bien équilibré ; le 32B dense gère MCP proprement et se sent à l'aise dans une boucle d'agent longue. Qwen3-Coder 30B (qwen3-coder:30b)** est le meilleur choix si votre travail d'agent est code.
• **Llama 3.3 70B (llama3.3:70b)** — le plafond le plus haut, mais le plus lourd. 48 Go+ de mémoire unifiée ou 2× 24 Go de GPUs en Q4_K_M. À utiliser seulement si votre matériel suit ; les modèles plus petits suffisent généralement.
• À éviter pour MCP : tout ce qui est sous 7B et tout modèle généraliste sans entraînement explicite tool calling. Ils émettent des appels malformés, la boucle bloque, et vous accuserez le harness — mais le harness va bien.
• Pour des techniques de prompting structuré qui améliorent la qualité des appels d'outils sur n'importe quel modèle, voir Chain-of-Thought Prompting.
• Pour les benchmarks tête-à-tête, voir Meilleurs modèles locaux pour tool calling 2026.

MCP vs function calling classique : quelle différence

• Le function calling est la capacité côté LLM : le modèle émet un objet JSON structuré décrivant le nom de l'outil et ses arguments. Les Tools OpenAI, les Tools Anthropic et l'API tool call d'Ollama partagent la même idée avec des formats wire légèrement différents.
• MCP s'ajoute au-dessus : il standardise la façon dont les outils sont décrits, découverts, invoqués et retournés, à travers les processus. Un modèle function calling seul ne sait rien de votre filesystem ; un serveur MCP rend les opérations filesystem disponibles, le client les mappe à l'API function calling du modèle, et le modèle peut alors les appeler.
• Le bénéfice est l'interop. Écrivez le serveur filesystem une fois ; Claude Desktop, Goose, Cline, Continue.dev et LM Studio l'utilisent tous sans modification. Changez de modèle Claude vers Gemma 4 ; le serveur ne change pas.
• Vous pouvez faire des agents avec du function calling brut. Vous réimplémenterez les handlers filesystem, base et navigateur par projet. Avec MCP, ce sont des dépendances out-of-the-box.
• Pour des scripts ponctuels, le function calling brut est plus simple. Pour tout ce que vous voulez réutiliser entre projets ou modèles, MCP devient le chemin moins coûteux en quelques jours.

Considérations pour les utilisateurs francophones

• RGPD et sous-traitance (Article 28) : un agent cloud fait du fournisseur un sous-traitant — DPA, mesures techniques et organisationnelles, évaluation de transfert hors UE, tout le dossier. Une pile MCP locale supprime ce lien contractuel pour la couche LLM, parce qu'aucune donnée à caractère personnel n'est transmise à un tiers.
• Recommandation CNIL : la CNIL a publiquement encouragé l'inférence locale pour le traitement de données sensibles dans les secteurs santé, juridique et financier. Un agent MCP local sur une station Apple M5 ou un PC RTX 4090 répond aux exigences sans engager un fournisseur cloud.
• Cabinets et PME francophones : expertise comptable, notariat, cabinets médicaux, ingénierie, RH — partout où des données client, patient ou salarié ne peuvent pas partir vers OpenAI, Anthropic ou Google. Un Mac mini M5 ou un PC workstation avec RTX 4090 fait tourner un modèle 27B–32B qui résume des dossiers, vérifie des contrats ou teste du code contre des bases internes.
• Belgique et Suisse : le RGPD belge et la nLPD suisse (en vigueur depuis septembre 2023) suivent la même logique de résidence des données. L'inférence locale satisfait les exigences sans contrat additionnel avec des fournisseurs américains.
• Québec (Loi 25) : la Loi modernisant les dispositions législatives en matière de protection des renseignements personnels impose une évaluation de facteurs relatifs à la vie privée pour tout transfert hors province. Une pile MCP locale élimine ce transfert pour la couche LLM.
• Audit et journalisation : le journal d'audit du client MCP (Goose, Cline, Continue.dev) est votre preuve principale que l'agent n'a fait que ce qui était attendu. Conservez-le sur un stockage WORM ou au minimum dans un dépôt Git que l'agent ne peut pas écraser depuis ses propres outils.

Erreurs fréquentes lors de la mise en place de MCP local

• Erreur 1 : utiliser un petit modèle généraliste. Les modèles sous 7B (et la plupart des 7B–13B généralistes sans fine-tuning tool calling) émettent des appels malformés. Utilisez un modèle 27B+ entraîné aux outils et arrêtez de vous battre contre le harness.
• Erreur 2 : allow-lister votre répertoire home. Les allow-listings « juste pour tester » de ~ survivent en production. Créez un agent-workspace dédié dès le début.
• Erreur 3 : laisser le serveur base en lecture/écriture. Une requête DELETE rédigée par un agent sûr de lui sur une vraie table est exactement l'incident qu'on évite ici. Faites de agent_ro votre défaut ; lancez un rôle écriture séparé uniquement pour les tâches qui en ont explicitement besoin, et seulement pour leur durée.
• Erreur 4 : auto-approuver chaque outil. Le bouton « tout approuver » est pratique et dangereux. Auto-approuvez les outils de lecture (read_file, list_directory, query) ; exigez toujours une approbation pour les outils écriture/shell/PR.
• Erreur 5 : un modèle 32K contexte pour du travail navigateur multi-étapes. Le contenu des pages est volumineux ; un agent qui navigue trois pages peut épuiser 32K tokens avant même de raisonner. Utilisez un modèle 128K pour les tâches navigateur lourdes.
• Erreur 6 : supposer que l'agent a du jugement. Il n'en a pas. Le modèle n'a aucun concept de « c'est la base de production » ou « ce PR va déployer ». Les permissions sont votre seule barrière.
• Erreur 7 : installer tous les serveurs de référence dès le départ. Plus d'outils = plus gros system prompt = sélection d'outil plus lente et moins fiable. Commencez par filesystem. Ajoutez les autres seulement quand vous avez un workflow qui les justifie.

Sources

• Spécification Model Context Protocol — Spécification officielle, schéma JSON-RPC, définitions de transport et de cycle de vie.
• Dépôt GitHub modelcontextprotocol/servers — Serveurs de référence (filesystem, sqlite, postgres, github, puppeteer, etc.) et documentation de configuration.
• Documentation du projet Goose — Installation CLI, configuration du provider Ollama, syntaxe de configuration des serveurs MCP.
• Bibliothèque de modèles Ollama — Modèles locaux disponibles, indicateurs de support tool calling et niveaux de quantification référencés dans ce guide.
• Dépôt GitHub Cline — Implémentation du client MCP pour VS Code, panneau MCP servers.
• Documentation Continue.dev — Référence du bloc de configuration mcpServers pour le client Continue.dev.

FAQ

Lectures complémentaires

• Meilleurs modèles locaux pour tool calling 2026 — benchmarks tête-à-tête pour les modèles recommandés ci-dessus (Gemma 4, GLM-5.1, Qwen3, Llama 3.3).
• Les agents locaux autonomes fonctionnent vraiment — un retour terrain sur ce qu'un agent MCP local peut et ne peut pas faire de manière fiable sur une tâche longue.
• Continue.dev vs Cline vs Aider : meilleur agent de code local 2026 — contexte agent adjacent pour le travail orienté code ; Cline et Continue.dev sont aussi des clients MCP.
• Meilleurs LLMs locaux en 2026 — autorité modèle pour le paysage open-weights plus large.
• Remplacer Zapier par des agents IA locaux — cadrage automatisation de workflows pour la même pile MCP.
• Hub Power Local LLM — bibliothèque complète des guides.