MCP : donner à un assistant IA un accès en lecture seule à son infra

Brancher Claude Code sur une API d’infra par un serveur MCP, c’est lui donner des yeux sur le parc. Si le serveur sait aussi créer et supprimer, c’est lui donner des mains : voici comment s’en tenir aux yeux.

Le principe

Le Model Context Protocol est un standard ouvert. L’application hôte, ici Claude Code, crée un client MCP par serveur, chacun avec sa connexion dédiée. Les messages suivent JSON-RPC 2.0, sur deux transports : stdio pour un serveur local lancé en sous-processus, Streamable HTTP pour un serveur distant.

Un serveur expose trois briques :

• les tools, des fonctions que le modèle décide d’appeler (tools/list pour les découvrir, tools/call pour les exécuter) ; ils peuvent écrire en base, appeler une API, modifier des fichiers ;
• les resources, des sources de données passives, en lecture seule ;
• les prompts, des modèles d’instructions que l’utilisateur invoque.

Le risque d’écriture est donc dans les tools.

Où se trouve vraiment la frontière

La spécification prévoit des annotations d’outil, dont readOnlyHint (« l’outil ne modifie pas son environnement », faux par défaut). Ce sont des indices, et un client ne doit jamais s’y fier quand le serveur n’est pas de confiance.

La vraie frontière est le compte avec lequel le serveur appelle votre API. S’il n’a qu’un rôle en lecture, ni un outil mal décrit ni une instruction piégée ne pourront écrire par ce serveur. D’où trois règles :

1. un compte de service dédié à l’assistant, distinct des comptes humains, pour que ses appels se repèrent dans les journaux d’audit ;
2. le rôle le plus restreint que propose la plateforme, en lecture, sur le seul périmètre utile ;
3. un jeton à portée minimale : les bonnes pratiques de sécurité MCP rappellent qu’un jeton aux portées larges, une fois volé, ouvre tout ce qu’il couvre.

Un serveur local tourne avec les droits de l’utilisateur : n’installez que des serveurs de provenance connue.

La configuration dans Claude Code

claude mcp add --transport stdio --scope project infra-lecture -- <commande-du-serveur>

Le -- sépare les options de Claude Code de la commande qui lance le serveur. Trois portées : local (par défaut, vous seul et ce projet, dans ~/.claude.json), project (fichier .mcp.json à la racine, versionnable) et user (tous vos projets, dans ~/.claude.json).

Aucun secret en clair dans .mcp.json : Claude Code y développe ${VAR} dans command, args, env, url et headers.

{
  "mcpServers": {
    "infra-lecture": {
      "command": "<commande-du-serveur>",
      "env": {
        "INFRA_URL": "${INFRA_URL}",
        "INFRA_TOKEN": "${INFRA_TOKEN}"
      }
    }
  }
}

Si la variable manque, la configuration se charge quand même : claude mcp list signale l’absence et le texte ${VAR} part tel quel. Pour un serveur distant, certains noms comme ANTHROPIC_API_KEY ou NPM_TOKEN sont lus vides dans url et headers : prenez un nom à vous.

En session interactive, Claude Code demande une approbation avant d’utiliser un serveur déclaré dans le .mcp.json d’un projet ; en mode -p, il le charge sans demander. /mcp affiche l’état des serveurs ; sélectionner un outil donne son nom complet.

Les permissions, deuxième ceinture

Chaque outil MCP s’appelle mcp__<serveur>__<outil>, et les règles de permission le visent directement :

{
  "permissions": {
    "allow": ["mcp__infra-lecture__list_*", "mcp__infra-lecture__get_*"],
    "deny": ["mcp__infra-lecture__delete_*", "mcp__infra-lecture__update_*"]
  }
}

Les noms d’outils dépendent du serveur : relevez-les avec /mcp avant d’écrire les règles. L’ordre d’évaluation est détaillé dans le billet sur les garde-fous. En allow, un joker n’est accepté qu’après le préfixe littéral mcp__<serveur>__. Une règle mcp__ avec parenthèses est ignorée dans les fichiers de réglages ; pour filtrer un paramètre d’outil MCP, la doc passe une règle deny par --disallowedTools. Pour aller plus loin, un hook PreToolUse avec le matcher mcp__infra-lecture__.* lit les arguments de chaque appel : voir le billet sur les hooks.

Ce qu’il faut retenir

• MCP : un client par serveur ; les tools agissent, les resources se lisent.
• readOnlyHint est un indice, pas une garantie : la lecture seule se joue sur le compte du serveur.
• Compte de service dédié, rôle en lecture, portée minimale.
• Secrets référencés par ${VAR} dans .mcp.json, jamais écrits en clair.
• Règles deny sur les outils d’écriture, et un hook pour contrôler les arguments.

In English

The Model Context Protocol connects an AI assistant to your tools. To let it read without writing: a minimal service account, secrets in environment variables, and permission rules tool by tool. Tool annotations such as readOnlyHint are only hints, so read-only access is guaranteed by the account and role given to the server, not by its tool descriptions.

Sources & vérification

Relevé sur : Documentation Claude Code et MCP, relevé 2026-10

• Claude Code, MCP code.claude.com
• Claude Code, Configure permissions code.claude.com
• MCP, What is MCP modelcontextprotocol.io
• MCP, Architecture overview modelcontextprotocol.io
• MCP, Understanding MCP servers modelcontextprotocol.io
• MCP specification, Tools modelcontextprotocol.io
• MCP specification, Schema reference (ToolAnnotations) modelcontextprotocol.io
• MCP specification, Security Best Practices modelcontextprotocol.io

Comment les billets sont vérifiés et corrigés