L’intégration du Model Context Protocol (MCP) avec Ollama, vLLM et Open WebUI

Le Model Context Protocol (MCP) est un protocole ouvert initié par Anthropic en novembre 2024, actuellement en voie de standardisation dans l’écosystème LLM. Il vise à résoudre le problème de l’isolement des modèles en offrant une interface unifiée pour connecter les agents IA à des sources de données et des outils tiers (systèmes de fichiers, bases de données, API).

Dans une infrastructure locale, l’enjeu est de faire cohabiter la puissance d’inférence d’Ollama ou de vLLM avec la flexibilité de MCP, le tout orchestré par une interface robuste comme Open WebUI.

Architecture d’une stack MCP locale

Pour comprendre l’intégration, il faut visualiser le flux d’exécution. Contrairement à une idée reçue, ce n’est pas le moteur d’inférence qui « parle » au protocole, mais l’interface qui joue le rôle de client.

Le flux logique :

1. Utilisateur : Envoie une requête via l’interface.
2. Open WebUI (Client MCP) : Identifie les outils disponibles via les serveurs MCP configurés.
3. Ollama ou vLLM (Inférence) : Reçoit la question et les définitions des outils. Il décide s’il doit utiliser un outil (Tool Calling).
4. Serveur MCP : Si le modèle sollicite un outil, Open WebUI exécute l’action via le serveur MCP dédié.
5. Outil externe : Accès au Filesystem, DB, ou API, puis retour du résultat vers le modèle pour la réponse finale.

Configuration d’Open WebUI : Le hub de coordination

Open WebUI est l’élément central de cette stack. Pour activer MCP, la configuration ne se situe plus dans les fonctions classiques mais dans les outils externes.

Étapes de configuration

Pour intégrer vos serveurs, rendez-vous dans : Admin Panel → Settings → External Tools

Plusieurs méthodes d’intégration sont disponibles :

• Import JSON MCP : Permet de définir manuellement les schémas d’outils.
• Utilisation de MCPO Proxy : Pour agréger plusieurs serveurs.
• Variables d’environnement Docker : Il est recommandé d’ajouter MCP_ENABLE=true dans votre fichier docker-compose.yaml pour garantir le support natif.

Note : La distinction entre une installation Docker et Bare Metal est cruciale. En Docker, assurez-vous que le conteneur a les permissions nécessaires pour exécuter des commandes npx ou accéder aux sockets locaux si vos serveurs MCP tournent sur l’hôte.

Moteurs d’inférence : Ollama vs vLLM face au Tool Calling

Le succès d’une implémentation MCP dépend de la capacité du modèle à générer un JSON valide pour le « Function Calling ».

Ollama et la précision

Ollama facilite l’usage du Tool Calling, mais la fiabilité dépend fortement de la quantification. Par exemple, l’utilisation du Q4 par défaut peut entraîner des erreurs de syntaxe dans l’appel des outils MCP. Pour une orchestration complexe, privilégiez des modèles en BF16 ou FP16.

A noter : Avec Ollama, il est possible d’utiliser des modèles en FP16 de deux manières : soit via les tags *fp16 disponibles dans la librairie officielle, soit en important un modèle FP16 ou FP32 personnalisé puis en choisissant de le quantifier — ou non — lors de sa création avec la commande ollama create. Cette approche permet de conserver une précision élevée si l’on évite les quantifications agressives (Q4, Q8).

Concernant le BF16, Ollama accepte l’import de poids au format BF16. Toutefois, à l’exécution, ces poids sont automatiquement convertis en FP16. Il n’existe pas, à ce jour, de véritable runtime BF16 natif dans Ollama, même pour les modèles explicitement marqués bf16. Le BF16 est donc pris en charge au niveau des fichiers de poids, mais pas au niveau du moteur d’inférence lui-même.

vLLM et le throughput

vLLM est privilégié pour les environnements à haute performance. Contrairement à certaines idées reçues, il n’utilise pas de flag d’auto-choix global, mais s’appuie sur une API OpenAI-compatible. L’orchestration MCP est gérée par Open WebUI, tandis que vLLM s’occupe du parsing des tools (via –tool-call-parser ou –tool-parser-plugin sur les versions récentes supportées). Pour plus de détails, consultez le dépôt officiel vLLM.

Modèles recommandés pour MCP

Pour garantir une robustesse maximale dans la génération de JSON conforme aux schémas MCP (tools calling local), les modèles suivants sont recommandés :

Modèles éprouvés

• Qwen2.5 (7B / 72B) : Référence actuelle pour le respect strict des schémas structurés et des arguments d’outils.
• Llama 3.1 / 3.2 : Standard “gold” pour le tool calling ; les variantes 3.2 (notamment lightweight/vision) offrent un excellent équilibre performance/cohérence.
• Mistral-Nemo : Compromis validé entre taille, précision logique et stabilité des sorties JSON.
• Gorilla LLM : Spécifiquement entraîné pour les appels d’API et l’usage d’outils.

Modèles récents à surveiller (fin 2025 / début 2026)

• Qwen3 : Successeur direct de Qwen2.5, très prometteur pour le tool use structuré.
• WizardLM-2 et OpenHermes 2.5 (Mixtral-7B) : Fine-tunés pour le function calling et les sorties structurées.
• Phi-3 / Phi-4 (Microsoft) : Modèles légers mais performants en structured outputs.
• DeepSeek-Coder-V2 : Particulièrement solide pour les scénarios code + tools.
• Sans oublier : Qwen3-Coder-Next, Nemotron-3-nano, Gpt-oss

Quel que soit le modèle retenu, la fiabilité du tool calling dépend également du niveau de quantification (éviter Q4 agressif si la précision des arguments est critique) et du prompt système encadrant strictement le schéma JSON attendu.

Comparatif technique des solutions

Critère	Ollama	vLLM	Open WebUI
Support MCP natif	Non	Non	Oui (Client)
Tool calling	Dépend du modèle	Dépend du modèle	Orchestration
Throughput	Moyen	Élevé	N/A
Latence ajoutée MCP	+100–300 ms	+80–200 ms	+ roundtrip
Complexité setup	Faible	Moyenne	Moyenne

Tutoriel : exposer une base PostgreSQL via MCP

Un cas d’usage courant consiste à permettre au modèle d’interroger une base de données locale (analytics, logs, CRM interne, etc.).

1. Lancer un serveur MCP PostgreSQL

Exemple avec un serveur MCP dédié PostgreSQL :

npx -y @modelcontextprotocol/server-postgres 
  postgresql://user:password@localhost:5432/ma_base

Ce serveur :

• expose des outils de requêtage SQL,
• limite l’accès à la base spécifiée,
• permet au modèle de générer des requêtes structurées via tool calling.

2. Proxy via MCPO

Comme Open WebUI consomme OpenAPI, il faut utiliser le proxy MCPO :

mcpo --port 8000 -- 
npx -y @modelcontextprotocol/server-postgres 
postgresql://user:password@localhost:5432/ma_base

3. Ajouter le serveur dans Open WebUI

Dans Open WebUI :

Admin → Settings → External Tools → Add Server/Connection

Puis :

http://localhost:8000

Pour plus d’informations, consulter la page d’exemple dans la documentation d’Open WebUI. L’exemple concerne une intégration MCP avec Notion.

Note : la bonne pratique consiste à imposer le mode lecture seule au niveau PostgreSQL, pas uniquement côté MCP. La création d’un rôle en lecture seule sur la base de donnée dans PostgreSQL, avec accès limité à un schéma ou à des vues spécifiques, est donc conseillée.

Sécurité des serveurs MCP locaux

L’exécution d’outils locaux présente des risques. Un agent IA, via une mauvaise interprétation ou une injection de prompt, pourrait exécuter des commandes destructrices.

1. Principe du moindre privilège : accès en lecture seule par défaut
2. Sandbox : Utilisez des environnements virtuels (venv) isolés pour chaque serveur MCP.
3. Audit : Vérifiez toujours le code des serveurs lancés via npx.
4. Isolation Docker : Séparez les volumes de données des volumes système.

MCP vs Function Calling natif et agents classiques

Pourquoi choisir MCP plutôt que l’API tools d’OpenAI ou des frameworks comme LangChain ?

• Interopérabilité : Un serveur MCP écrit une fois fonctionne avec n’importe quel client (Claude Desktop, Open WebUI, etc.).
• Abstraction : MCP sépare la logique de l’outil de la logique du modèle.
• Modularité : Vous pouvez brancher/débrancher des capacités sans modifier le code de votre orchestrateur.

Note explicative — MCP vs tool calling

Il est important de distinguer deux notions souvent confondues : le tool calling et le Model Context Protocol (MCP).

Le tool calling est une capacité du modèle de langage. Il permet au modèle de générer un appel structuré (souvent en JSON) vers une fonction ou un outil défini par l’application. Cette mécanique peut fonctionner sans MCP, par exemple via une API compatible OpenAI.

Le MCP, initié par Anthropic, est un protocole d’interopérabilité. Il standardise la manière dont les outils sont décrits, exposés et découverts par un client. Il ne remplace pas le tool calling, mais organise l’écosystème d’outils autour du modèle.

En pratique :

• Le modèle (via Ollama ou vLLM) effectue le tool calling.
• Un client comme Open WebUI orchestre l’exécution.
• Les outils sont exposés via des serveurs MCP.

En résumé : Le tool calling est une capacité du modèle. Le MCP est un standard pour connecter proprement ces outils. Les deux sont complémentaires, mais indépendants.

Vers une architecture agentique modulaire

L’adoption du Model Context Protocol marque un tournant dans l’ingénierie des LLM locaux. En séparant la logique métier (les serveurs MCP) de l’interface utilisateur (Open WebUI) et du moteur d’exécution (Ollama ou vLLM), vous construisez une infrastructure évolutive. Cette approche réduit la dette technique : changer de modèle ou de fournisseur d’inférence n’implique plus de réécrire vos connecteurs de données.

Le futur de cette stack réside dans l’optimisation de la latence de l’orchestration. L’ajout de couches de décision (agents) au-dessus de MCP permet de traiter des workflows complexes, où le modèle ne se contente plus de répondre, mais planifie une suite d’actions sur votre infrastructure locale en toute autonomie.

Pour plus d’informations, retrouvez notre guide complet sur Cosmo-Edge.com et d’autres articles plus approfondis sur l’IA et son usage, que ce soit en locale ou avec des API Cloud.

---

FAQ

Est-il possible d’utiliser MCP avec Ollama (Open WebUI plus précisement) sans passer par Docker ?

Oui, il est possible de faire tourner Open WebUI et vos serveurs MCP en « bare metal » (installation directe via Python/Node.js). Cela facilite l’accès aux ressources locales (GPU, fichiers) mais complexifie la gestion des dépendances et la sécurité de l’hôte.

Pourquoi mon modèle ignore-t-il les outils MCP configurés ?

Cela est généralement dû à deux facteurs : soit le modèle utilisé n’est pas optimisé pour le « Tool Calling » (privilégiez les versions Instruct), soit la quantification est trop agressive (Q2 ou Q3), ce qui dégrade la capacité du modèle à respecter le format JSON rigide requis par le protocole.

Comment déboguer la communication entre Open WebUI et un serveur MCP ?

Consultez les logs de votre conteneur Open WebUI ou de votre terminal. Si le serveur MCP est lancé via npx, une erreur de permission ou une absence de bibliothèque Node.js sur l’hôte empêchera l’initialisation de l’outil dans l’interface.

---