Connecter Claude Code, Cursor ou Codex à une infra Linux avec MCP

Guide DevOps / IA

MCP permet à un agent IA de dialoguer avec des outils internes sans copier-coller de logs, d’inventaires ou de sorties de supervision dans un chat. Claude Code, Cursor et Codex sont des exemples courants, mais l’approche vaut pour tout agent compatible MCP. Bien conçu, un serveur MCP devient une passerelle contrôlée entre l’assistant IA et l’infrastructure Linux : accès limités, commandes explicites, journalisation et révocation simple.

Ce que MCP apporte à Claude Code, Cursor et Codex

Le Model Context Protocol est un standard ouvert qui permet à une application IA de se connecter à des systèmes externes : outils, APIs, bases, fichiers ou workflows. Si tu veux d’abord le contexte général, l’article Model Context Protocol : guide complet pour Devs et Ops pose les bases ; ici, on se concentre sur l’usage concret côté infra Linux, avec Claude Code, Cursor et Codex comme exemples de clients MCP.

Dans un contexte DevOps, l’intérêt est concret : l’assistant peut lire un inventaire, vérifier l’état d’un service, interroger une métrique ou récupérer un runbook sans que l’utilisateur colle manuellement des sorties terminal dans la conversation.

Les docs officielles convergent sur les mêmes bases : MCP utilise JSON-RPC encodé en UTF-8, expose notamment des tools, des resources et des prompts, et s’appuie aujourd’hui surtout sur deux transports standards : stdio et Streamable HTTP. SSE existe encore dans certains clients, mais doit être considéré comme legacy pour les nouveaux déploiements.

Architecture recommandée pour une infra Linux

Le piège consiste à brancher un agent IA directement sur SSH ou sur une API d’administration trop permissive. La bonne approche est de placer MCP comme une couche de contrôle.

Pour une première version, je recommande :

• transport stdio : le client lance le serveur localement, sans port réseau ouvert ;
• outils read-only : inventaire, statut de services, lecture de runbooks, requêtes métriques ;
• allowlist stricte : pas de commande arbitraire fournie par le modèle ;
• logs sur stderr ou fichier : en stdio, stdout est réservé aux messages MCP ;
• secrets hors code : variables d’environnement, fichier local protégé, ou intégration secret manager.

Mini-lab : serveur MCP read-only en Python

Ce mini-lab montre une base volontairement limitée : un serveur MCP expose deux outils, l’un pour lire un inventaire statique, l’autre pour vérifier l’état de quelques services autorisés sur la machine locale. Il ne donne jamais de shell libre à l’agent IA.

Pré-requis

mkdir mcp-infra-readonly
cd mcp-infra-readonly
uv init
uv add "mcp[cli]"

Créer le serveur MCP

Crée un fichier infra_mcp.py :

import json
import logging
import subprocess
from pathlib import Path

from mcp.server.fastmcp import FastMCP

logging.basicConfig(level=logging.INFO)
mcp = FastMCP("infra-readonly")

ALLOWED_SERVICES = {"ssh", "nginx", "docker", "cron"}
INVENTORY_FILE = Path(__file__).with_name("inventory.json")


@mcp.tool()
def get_inventory() -> str:
    """Retourne l'inventaire Linux de test au format JSON."""
    if not INVENTORY_FILE.exists():
        return json.dumps({"hosts": [], "warning": "inventory.json absent"})
    return INVENTORY_FILE.read_text(encoding="utf-8")


@mcp.tool()
def get_service_status(service: str) -> str:
    """Vérifie l'état read-only d'un service systemd autorisé.

    Args:
        service: Nom du service parmi ssh, nginx, docker ou cron.
    """
    if service not in ALLOWED_SERVICES:
        return json.dumps({
            "service": service,
            "allowed": False,
            "error": "service non autorisé"
        })

    result = subprocess.run(
        ["systemctl", "is-active", service],
        text=True,
        capture_output=True,
        timeout=5,
        check=False,
    )
    return json.dumps({
        "service": service,
        "allowed": True,
        "active_state": result.stdout.strip() or result.stderr.strip(),
        "returncode": result.returncode,
    })


if __name__ == "__main__":
    mcp.run(transport="stdio")

Ajoute un inventaire de test :

cat > inventory.json <<'JSON'
{
  "hosts": [
    {
      "name": "dev-linux",
      "role": "test",
      "os": "Debian",
      "environment": "sandbox",
      "criticality": "low"
    }
  ]
}
JSON

Test local sans client IA

Le serveur MCP parle sur stdin/stdout, donc le test manuel brut n’est pas pratique. Le test minimal consiste d’abord à vérifier qu’il démarre sans écrire de logs sur stdout :

uv run infra_mcp.py

Résultat attendu : le processus attend des messages MCP. Aucun texte applicatif ne doit s’afficher sur stdout. Arrête avec Ctrl+C.

Configuration Claude Code, Cursor et Codex

Claude Code, Cursor et Codex supportent MCP, mais leur configuration diffère. Ce ne sont pas les seuls : le même principe s’applique à tout agent IA ou IDE capable de consommer un serveur MCP. Les références utiles sont les docs officielles Claude Code MCP, Cursor MCP et Codex MCP. Garde le même serveur Python et adapte seulement la déclaration côté client.

claude mcp add --transport stdio infra-readonly -- \
  uv --directory /chemin/absolu/mcp-infra-readonly run infra_mcp.py

/mcp

Utilise le serveur MCP infra-readonly pour lire l'inventaire, puis vérifie l'état du service ssh. Ne tente aucune action corrective.

{
  "mcpServers": {
    "infra-readonly": {
      "type": "stdio",
      "command": "uv",
      "args": [
        "--directory",
        "/chemin/absolu/mcp-infra-readonly",
        "run",
        "infra_mcp.py"
      ]
    }
  }
}

[mcp_servers.infra-readonly]
command = "uv"
args = [
  "--directory",
  "/chemin/absolu/mcp-infra-readonly",
  "run",
  "infra_mcp.py"
]
startup_timeout_sec = 10
tool_timeout_sec = 30
enabled = true
default_tools_approval_mode = "prompt"

Sécurité, vérification et rollback

Un serveur MCP infra doit être traité comme une interface d’administration. Même read-only, il peut exposer des informations sensibles : noms de serveurs, topologie, versions, erreurs, chemins internes.

Checklist sécurité avant usage équipe

• Pas d’outil “run_command” ou “exec shell” générique ;
• allowlist de services, hôtes, fichiers ou requêtes ;
• timeouts courts sur les appels système et réseau ;
• sorties bornées pour éviter de renvoyer 50 000 lignes de logs ;
• pas de secret dans les réponses MCP ;
• validation des paramètres côté serveur, jamais seulement dans le prompt ;
• journalisation des appels outil : nom, paramètres filtrés, durée, statut ;
• approbation manuelle côté client pour les outils sensibles.

Et si on veut du HTTP ?

Streamable HTTP devient utile pour un serveur MCP partagé par plusieurs utilisateurs ou hébergé sur une plateforme interne. Dans ce cas, applique au minimum :

• bind local ou exposition derrière reverse proxy authentifié ;
• validation de l’en-tête Origin pour limiter les risques de DNS rebinding ;
• authentification OAuth ou bearer token selon le client ;
• TLS, logs d’accès, rate limiting ;
• segmentation réseau : le serveur MCP ne doit voir que ce dont il a besoin.

Rollback

Le rollback doit rester trivial :

# Claude Code
claude mcp remove infra-readonly

# Cursor
rm .cursor/mcp.json

# Codex
# supprimer ou désactiver le bloc [mcp_servers.infra-readonly]

Côté serveur, supprime le dossier de test si aucun secret n’y a été stocké :

cd ..
rm -rf mcp-infra-readonly

Sur une infra réelle, préfère désactiver la configuration client avant de supprimer les fichiers serveur. Cela évite les erreurs de démarrage répétées côté IDE ou CLI.

Erreurs fréquentes

FAQ