MCP et LLM local : connecter des serveurs MCP à Ollama

#C'est quoi MCP et pourquoi ça change les agents locaux

MCP (Model Context Protocol) est un protocole ouvert publié par Anthropic fin 2024. Son but : offrir une interface unique entre un modèle de langage et les outils qu'il peut utiliser. Au lieu de recoder une intégration maison pour chaque source de données, un « serveur MCP » expose des outils (tools), des ressources (resources) et des prompts selon un format standard. N'importe quel client compatible — Claude Desktop, un IDE, ou votre propre bridge — peut alors s'y connecter.

Concrètement, un serveur MCP « filesystem » expose des outils comme read_file, write_file ou list_directory. Un serveur « sqlite » expose query ou list_tables. Le LLM ne parle jamais directement au disque : il émet une demande d'appel d'outil, le client l'exécute via le serveur MCP, puis renvoie le résultat au modèle. Cette séparation client / serveur est ce qui rend le protocole réutilisable.

Pour les agents locaux, l'enjeu est double : réutiliser l'écosystème grandissant de serveurs MCP (des dizaines existent déjà), tout en gardant l'inférence 100 % sur votre machine grâce à Ollama. Vous obtenez un agent qui lit vos fichiers et interroge vos bases sans qu'un octet ne quitte votre réseau.

#Pourquoi brancher MCP sur Ollama

La plupart des démos MCP utilisent un modèle cloud (Claude, GPT). Faire du mcp ollama en local change la donne sur trois points : la confidentialité (vos fichiers et requêtes SQL ne sortent pas), le coût (zéro token facturé, quel que soit le volume d'appels d'outils) et le contrôle (vous choisissez le modèle, la quantification et les serveurs autorisés).

Confidentialité

Un serveur MCP filesystem donne au modèle l'accès à vos dossiers. En local, ce contenu ne transite jamais par un tiers.

Coût nul

Les agents multiplient les allers-retours d'outils. En cloud, chaque tour coûte des tokens ; avec Ollama, c'est gratuit.

Hors-ligne

Une fois le modèle téléchargé et les serveurs MCP installés, l'ensemble fonctionne sans connexion internet (hors serveurs web bien sûr).

Souveraineté

Vous décidez quels outils sont exposés et pouvez auditer chaque appel avant de l'exécuter.

#Prérequis

Ollama installé

Le daemon écoute par défaut sur http://localhost:11434. Vérifiez avec « ollama --version ».

Un modèle tool-use

Comptez au moins un 7B–8B, idéalement un 14B+ pour de la fiabilité (voir section suivante).

Python 3.10+

Le SDK MCP officiel et le client Ollama sont en Python.

Node.js (optionnel)

Beaucoup de serveurs MCP de référence se lancent via npx (@modelcontextprotocol/server-*).

# Vérifier Ollama
ollama --version
curl http://localhost:11434/api/tags

# Tirer un modèle capable de tool-use
ollama pull qwen2.5:14b

# Environnement Python
python -m venv .venv
source .venv/bin/activate
pip install mcp ollama

#Quels modèles locaux gèrent le tool-use correctement

Tous les modèles ne se valent pas pour le function calling. Un modèle qui « connaît » le format des tools mais choisit mal ses arguments rendra l'agent inutilisable. En pratique, la fiabilité grimpe nettement à partir de 14B. Voici les repères testables avec Ollama et leur empreinte VRAM en Q4_K_M.

Qwen2.5 7B / 14B

Excellent support du tool-use. Le 14B (≈9 Go VRAM en Q4) est le meilleur compromis fiabilité/matériel pour un agent local.

Llama 3.1 8B

Tool-use natif correct (≈5 Go en Q4), bon point d'entrée mais enchaînements multi-outils parfois hésitants.

Mistral Small / Nemo

Function calling solide, contexte large. À l'aise sur des schémas d'outils un peu complexes.

Qwen2.5 32B

Très fiable sur les chaînes d'appels (≈19 Go en Q4). À réserver aux GPU 24 Go type RTX 4090.

Modèles 3B

≈2 Go seulement, mais le tool-use décroche vite dès qu'il y a plusieurs outils. À éviter pour un vrai agent.

#Le bridge MCP-Ollama en Python, pas à pas

Ollama n'est pas un client MCP natif. Le rôle du bridge est de jouer les intermédiaires : démarrer un serveur MCP, convertir ses outils au format attendu par l'API Ollama, faire tourner la boucle d'appels d'outils, puis renvoyer les résultats au modèle. On utilise le SDK MCP officiel (paquet mcp) et le client ollama.

1. 01
   1. Démarrer un serveur MCP

   On lance un serveur MCP en sous-processus via stdio. Ici le serveur filesystem officiel, limité à un dossier de travail passé en argument.
2. 02
   2. Lister et convertir les outils

   session.list_tools() renvoie les outils MCP. On les transforme au format « tools » attendu par /api/chat d'Ollama (name, description, inputSchema → parameters).
3. 03
   3. Boucle d'appel d'outils

   On envoie le message utilisateur + la liste des outils. Si le modèle répond par un tool_call, on l'exécute côté MCP, on réinjecte le résultat, et on reboucle jusqu'à obtenir une réponse finale.
4. 04
   4. Renvoyer la réponse

   Quand le modèle ne demande plus d'outil, sa dernière réponse texte est le résultat final présenté à l'utilisateur.

import asyncio
import ollama
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

MODEL = "qwen2.5:14b"

# Serveur MCP filesystem limité au dossier ./workspace
server = StdioServerParameters(
    command="npx",
    args=["-y", "@modelcontextprotocol/server-filesystem", "./workspace"],
)

def to_ollama_tools(mcp_tools):
    return [{
        "type": "function",
        "function": {
            "name": t.name,
            "description": t.description,
            "parameters": t.inputSchema,
        },
    } for t in mcp_tools]

async def run(prompt: str):
    async with stdio_client(server) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()
            tools = (await session.list_tools()).tools
            ollama_tools = to_ollama_tools(tools)
            messages = [{"role": "user", "content": prompt}]

            while True:
                resp = ollama.chat(
                    model=MODEL,
                    messages=messages,
                    tools=ollama_tools,
                )
                msg = resp["message"]
                messages.append(msg)

                if not msg.get("tool_calls"):
                    return msg["content"]

                for call in msg["tool_calls"]:
                    fn = call["function"]
                    result = await session.call_tool(
                        fn["name"], fn.get("arguments", {}),
                    )
                    text = "".join(c.text for c in result.content
                                    if getattr(c, "text", None))
                    messages.append({
                        "role": "tool",
                        "content": text,
                    })

if __name__ == "__main__":
    print(asyncio.run(run("Liste les fichiers du dossier et résume leur contenu.")))

#Exemples de serveurs MCP utiles en self-host

L'intérêt de MCP vient du catalogue de serveurs prêts à l'emploi. Voici ceux qui apportent le plus de valeur à un agent local, tous lançables via npx ou pip.

filesystem

Lecture / écriture de fichiers dans un dossier racine imposé. Le plus utile pour un agent qui travaille sur vos documents.

sqlite / postgres

Interroger une base locale en langage naturel. Passez la connexion en lecture seule pour éviter toute modification.

fetch

Récupérer et convertir une page web en texte. Le seul qui suppose une connexion internet.

git

Explorer un dépôt : log, diff, statut. Pratique pour un agent de revue ou de documentation de code.

memory

Un magasin clé-valeur persistant qui donne une mémoire longue durée à l'agent entre les sessions.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "./workspace"]
    },
    "sqlite": {
      "command": "uvx",
      "args": ["mcp-server-sqlite", "--db-path", "./data/app.db"]
    }
  }
}

#Les limites réelles des petits modèles

Un bridge fonctionnel ne garantit pas un bon agent. Le maillon faible reste le modèle. Sous 14B, plusieurs problèmes reviennent systématiquement dès que la tâche se complique.

Choix d'outil erroné

Le modèle appelle read_file quand il faut list_directory, ou invente un nom d'outil. Fréquent en dessous de 7B.

Arguments mal formés

Chemins relatifs incorrects, JSON invalide dans les arguments. Un bon prompt système et des descriptions d'outils claires atténuent le problème.

Enchaînements courts

Les petits modèles peinent au-delà de 2-3 appels successifs et perdent le fil de l'objectif.

Ignorer le résultat

Le modèle appelle un outil puis répond sans tenir compte de ce qu'il a reçu. Symptôme classique d'un modèle trop léger.

#Dépannage

Le modèle ne fait aucun tool_call

Vérifiez qu'il supporte le tool-use (Qwen2.5, Llama 3.1) et que le paramètre « tools » est bien passé à /api/chat. Un modèle non compatible ignore les outils.

« connection refused » sur 11434

Le daemon Ollama n'est pas lancé. Démarrez-le (« ollama serve ») et retestez « curl http://localhost:11434/api/tags ».

Le serveur MCP ne démarre pas

Testez la commande npx / uvx seule dans un terminal. Un serveur Node manquant se corrige avec « npm i -g » du paquet concerné.

Boucle infinie d'outils

Ajoutez un plafond d'itérations dans la boucle et loggez chaque tool_call pour repérer le modèle qui répète le même appel.

#Pour aller plus loin

MCP s'appuie sur les briques de base de l'écosystème local. Ces guides connexes du site complètent celui-ci :

Créer un agent IA local avec LangChain et Ollama

L'approche agent classique via LangChain, complémentaire de MCP pour orchestrer des outils.

Intégrer Ollama via l'API REST en Python

Comprendre l'endpoint OpenAI-compatible et le function calling qui sous-tendent le bridge.

Choisir sa quantification (Q4, Q5, Q8, FP16)

Faire tenir un modèle 14B+ tool-use sur votre GPU sans sacrifier la fiabilité.