11 min de lecture 16 août 2026

Serveur MCP pour Ollama : connecter outils, recherche Web et modèles locaux

Une présentation pratique de l'architecture et de la configuration pour relier un modèle Ollama local à des outils MCP sans masquer les permissions, le réseau ou les erreurs.

Équipe éditoriale d’Odysseus AI Wiki
Équipe éditoriale d’Odysseus AI Wiki
Documentation technique et vérification indépendantes

Réponse courte: Un serveur MCP pour Ollama n'est pas une commande unique intégrée à Ollama. Ollama exécute le modèle ; un hôte compatible MCP crée une connexion client vers un serveur MCP ; ce serveur expose des outils comme la recherche Web ou l'accès aux fichiers. Séparez clairement l'hôte, le modèle, les autorisations, les secrets et le réseau externe.

Un flux avec un serveur MCP pour Ollama relie un modèle local à des actions utiles sans prétendre que le modèle, le protocole et le fournisseur d'outils sont la même chose. Le modèle peut tourner localement avec Ollama, tandis qu'un hôte MCP gère les connexions client, les validations et les résultats. Ce guide explique cette frontière, la recherche Web et le contrôle des permissions.

Ce que signifie réellement serveur MCP pour Ollama

MCP, ou Model Context Protocol, est une méthode standard permettant à une application d'IA de découvrir et d'appeler des outils exposés par un serveur. Un outil peut rechercher sur le Web, lire un dossier autorisé ou interroger une base de données. Ollama est le runtime du modèle : il charge le modèle et génère la réponse, mais un modèle local ne transforme pas automatiquement Ollama en hôte MCP.

Le terme serveur MCP pour Ollama peut donc désigner plusieurs architectures. Il peut s'agir d'un serveur local qui parle à Ollama ou d'un hôte MCP qui utilise un modèle Ollama et se connecte à un serveur de recherche. C'est généralement l'hôte qui possède la découverte, l'approbation, l'exécution et le retour du résultat au modèle.

Séparer les couches

Ollama fournit l'inférence. MCP fournit le protocole d'outils. L'hôte décide quand appeler un outil, quels arguments accepter et quel résultat transmettre.


Frontière entre hôte, client, serveur et modèle

Une architecture MCP courante comporte quatre rôles. L'hôte est l'application d'IA et crée une connexion client pour chaque serveur. Le serveur MCP annonce des outils et exécute une demande approuvée. Ollama se trouve à côté de cette chaîne comme endpoint local d'inférence.

Le modèle n'obtient pas automatiquement un accès à tous les outils. L'hôte présente les schémas, le modèle peut demander un appel, puis l'hôte valide les arguments et exécute la demande. Il décide ensuite de la quantité de résultat renvoyée au modèle.

Couche Responsabilité Ne possède pas automatiquement
Ollama Chargement du modèle et inférence locale Découverte des serveurs MCP et permissions universelles
Hôte MCP Conversation, clients, validations et contexte L'implémentation interne de chaque serveur
Client MCP Connexion entre un hôte et un serveur Un runtime de modèle
Serveur MCP Schémas, validation et exécution des outils Le droit de contourner l'approbation

Préparer Ollama et un hôte compatible MCP

Commencez par vérifier qu'un modèle fonctionne déjà avec Ollama. Le daemon doit être actif, le modèle installé et l'API locale accessible avant d'ajouter MCP. Si une requête simple échoue, le protocole ne fera qu'ajouter du bruit au diagnostic.

Choisissez ensuite une application qui documente clairement le support des clients MCP. La configuration peut être un JSON, un écran de paramètres, un profil de bureau ou un SDK. Ne copiez pas un bloc venant d'un autre hôte sans vérifier la commande, le transport, les variables d'environnement et les permissions.

Local ne veut pas dire privé par défaut

L'inférence peut rester sur localhost tandis qu'un outil transmet une requête à une API externe. Documentez chaque flux de données.

Vérifier le runtime local
ollama list
Tester le modèle
ollama run <model-name> "Réponds seulement par prêt."
Inspecter l'endpoint
curl http://127.0.0.1:11434/api/tags

Connecter un modèle Ollama local en sécurité

Avant d'appeler un outil, vérifiez deux connexions. L'hôte doit atteindre l'endpoint Ollama configuré : localhost convient souvent sur un poste, alors qu'un conteneur peut nécessiter host.docker.internal ou un nom de service. Vérifiez aussi que le modèle et le chemin API prennent en charge le tool calling attendu par l'hôte.

L'API Ollama peut accepter des définitions d'outils et renvoyer des appels, mais cela ne constitue pas à lui seul une implémentation complète de MCP. Un hôte MCP traduit généralement le message du modèle vers les messages MCP de découverte ou d'appel. Testez séparément le fournisseur Ollama et la connexion MCP.

Exemple de vérification
curl http://127.0.0.1:11434/api/chat -H "Content-Type: application/json" -d "{\"model\":\"<model-name>\",\"messages\":[{\"role\":\"user\",\"content\":\"Vérifie l'état actuel de ce projet.\"}],\"tools\":[] }"

Ajouter une recherche Web MCP sans coder les secrets en dur

Un serveur MCP de recherche Web est un fournisseur d'outils, pas une promesse que chaque réponse sera exacte ou actuelle. Selon son implémentation, il peut appeler une API, un navigateur, un métamoteur ou un service hébergé. Consultez la documentation officielle pour le transport, les variables, la rétention et les versions nécessaires.

De nombreux hôtes utilisent une forme proche de l'exemple ci-dessous, mais les clés changent. Considérez-le comme un modèle conceptuel. Gardez les clés dans un gestionnaire de secrets ou l'environnement, limitez les outils autorisés et commencez par une recherche en lecture seule.

Un processus MCP local peut appeler Internet

Le lieu de démarrage du processus ne dit pas où vont les requêtes. Identifiez le fournisseur externe et supprimez les données sensibles.

  1. Vérifier la source

    Utilisez le dépôt ou la documentation officielle et contrôlez licence, activité, runtime et transport.

  2. Réduire les permissions

    Autorisez d'abord search ou fetch, sans écriture de fichiers, shell ou réseau privé étendu.

  3. Lancer une requête contrôlée

    Vérifiez le nom de l'outil, ses arguments et les URL retournées avec une requête sans risque.

Entrée MCP illustrative
{ "mcpServers": { "web-search": { "command": "npx", "args": ["-y", "<paquet-mcp-recherche-web>"], "env": { "SEARCH_API_KEY": "${SEARCH_API_KEY}" } } } }

Rendre les appels d’outils observables et vérifiables

Un workflow Ollama MCP fiable laisse une trace d’audit utile sans enregistrer de contenu sensible. Notez le nom du serveur, l’outil, l’heure de début, la durée, le résultat, la classe d’erreur et les domaines sources. Masquez les clés API, les en-têtes d’autorisation, le contenu des fichiers privés et les secrets utilisateur. Pour une recherche, conservez les URL finales et un bref nombre de résultats afin qu’un contrôleur voie les éléments transmis au modèle.

L’hôte doit aussi rendre l’approbation visible. Un argument produit par le modèle est une entrée non fiable. Validez les URL, chemins de fichiers, longueur de requête, listes de domaines autorisés, délais et nombre maximal de résultats avant exécution. Traitez les pages récupérées comme du texte non fiable, car elles peuvent contenir des instructions d’injection de prompt opposées à la demande.

À observer Pourquoi c’est utile Valeur sûre par défaut
Nom de l’outil et du serveur Montre quelle capacité a réellement été exécutée Autoriser les noms connus
Arguments Rend le comportement caché du modèle vérifiable Masquer les secrets et limiter la taille
Durée et statut Sépare un délai dépassé d’un contenu incorrect Utiliser des délais et reprises bornés
Sources ou identifiants de résultats Permet à une personne de vérifier les éléments Garder les URL, pas les données privées

Dépanner dans le bon ordre

Testez une couche après l'autre : Ollama sans MCP, puis la liste des outils sans exécution, puis un seul appel à faible risque. Cette séquence sépare les erreurs de modèle, de transport, de permission et de fournisseur.

Si le modèle répond de mémoire sans appeler l'outil, vérifiez d'abord la liste des outils de l'hôte et la prise en charge du tool calling. Si l'outil fonctionne mais que la réponse est mauvaise, inspectez le résultat brut, les sources, la troncature du contexte et les instructions injectées dans les pages.

Symptôme Couche probable Prochaine vérification
Connexion Ollama refusée Runtime ou endpoint Lancer ollama list et vérifier URL et port 11434
Serveur MCP ne démarre pas Commande ou environnement Exécuter la commande hors de l'hôte et lire stderr
Aucun outil affiché Transport ou configuration Vérifier le transport MCP et le schéma de l'hôte
Le modèle ignore l'outil Modèle ou boucle Confirmer le tool calling et le message brut
Recherche vide Fournisseur ou limite Vérifier clé, requête, état et payload
La réponse suit une page Contenu non fiable Traiter la page comme donnée et appliquer les politiques

API Ollama Web Search et recherche Web MCP

Ollama Web Search peut désigner deux parcours. L'API officielle est un service hébergé avec ses propres clés, limites et frontière de confidentialité. Un serveur MCP de recherche Web est un outil appelé par un hôte MCP ; il peut être local, auto-hébergé ou adossé à un autre fournisseur. Les deux peuvent fournir de l'information récente, mais les étapes de configuration diffèrent.

Consultez le guide Ollama Web Search existant pour l'API officielle, web_fetch, la confidentialité, les limites et SearXNG. Cette page couvre les hôtes MCP, les schémas d'outils, les permissions et les connexions de clients locaux.

Point Ollama Web Search Recherche MCP
Responsable Service hébergé Ollama Serveur MCP et fournisseur choisi
Intégration L'application appelle l'API L'hôte crée un client et appelle les outils
Usage Parcours de recherche hébergé Outils composables et contrôle d'infrastructure
Attention La requête sort du runtime local Il faut examiner le serveur et les résultats

Questions fréquentes du serveur MCP pour Ollama

Pas automatiquement. Ollama fournit le runtime et ses API ; un hôte compatible gère la connexion MCP, la configuration et les validations.

Non. L'hôte doit exposer et exécuter l'outil, et le modèle peut ne pas l'appeler. Le résultat peut aussi être incomplet ou non fiable.

Seulement s'il doit appeler l'API locale Ollama. Le transport MCP et l'endpoint HTTP Ollama sont séparés.

Pas nécessairement. Elle peut transférer les requêtes vers une API externe. Vérifiez fournisseur, logs, rétention et réseau.

Dans le gestionnaire de secrets ou l'environnement de l'hôte, jamais dans un fichier versionné, un prompt, une capture ou un log.

Conservez-la dans le gestionnaire de secrets ou l’environnement de l’hôte, jamais dans une configuration versionnée ou un prompt. Ne journalisez pas les en-têtes de requête et faites tourner la clé si elle apparaît dans l’historique du terminal, une capture, un artefact de build ou un rapport d’erreur.

Références officielles

  1. Documentation des appels d’outils Ollama - Définitions et flux d'appel d'outils
  2. Architecture MCP - Concepts officiels d'hôte, client et serveur
  3. Spécification MCP - Référence du protocole
  4. Introduction à l'API Ollama - API locale et endpoints

Ressources IA locale associées

Dernière mise à jour : 16 août 2026

Retour à l'accueil