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.
Sur cette page
- Ce que signifie réellement serveur MCP pour Ollama
- Frontière entre hôte, client, serveur et modèle
- Préparer Ollama et un hôte compatible MCP
- Connecter un modèle Ollama local
- Ajouter une recherche Web sans exposer les secrets
- Rendre les appels d’outils observables et vérifiables
- Dépanner dans le bon ordre
- API Ollama Web Search et recherche MCP
- Questions fréquentes du serveur MCP pour Ollama
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.
ollama list
ollama run <model-name> "Réponds seulement par prêt."
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.
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.
-
Vérifier la source
Utilisez le dépôt ou la documentation officielle et contrôlez licence, activité, runtime et transport.
-
Réduire les permissions
Autorisez d'abord search ou fetch, sans écriture de fichiers, shell ou réseau privé étendu.
-
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.
{ "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
Références officielles
- Documentation des appels d’outils Ollama - Définitions et flux d'appel d'outils
- Architecture MCP - Concepts officiels d'hôte, client et serveur
- Spécification MCP - Référence du protocole
- Introduction à l'API Ollama - API locale et endpoints
Ressources IA locale associées
- Documentation de l'API Ollama Web Search - API hébergée, confidentialité, limites et SearXNG.
- Configuration Odysseus AI avec Ollama - Vérifier le runtime local avant les outils.
- Cursor et agent de code Ollama - Flux spécifique à l'éditeur et aux permissions.
- Configuration OpenCode avec Ollama - Autre exemple de client local.
- Ressource sur les agents de code IA locaux - Architecture des agents locaux, limites du dépôt et approbations.
Dernière mise à jour : 16 août 2026
Retour à l'accueil