Model Context Protocol (MCP) : connecter l'IA à vos outils DevOps

Qu'est-ce que le Model Context Protocol ?

Le Model Context Protocol (MCP) est un standard open-source créé par Anthropic pour résoudre un problème fondamental : comment permettre à un LLM d'accéder de manière sécurisée et standardisée à des outils, des données, et des contextes externes ? Avant MCP, chaque application IA devait implémenter ses propres intégrations propriétaires pour chaque outil.

MCP définit un protocole JSON-RPC 2.0 entre deux acteurs :

• Client MCP : l'application IA (Claude Desktop, Claude Code, votre application custom)
• Serveur MCP : un processus exposant des capacités (outils, ressources, prompts) à travers le protocole standardisé

La communication se fait via stdin/stdout (processus locaux) ou via HTTP+SSE (serveurs distants).

Les primitives MCP

• Tools : fonctions que le LLM peut appeler (ex: kubectl_get_pods, terraform_plan). Le LLM décide quand les invoquer en fonction du contexte.
• Resources : données statiques ou dynamiques exposées comme contexte (ex: contenu d'un fichier, résultat d'une requête SQL)
• Prompts : templates de prompts paramétrés que l'utilisateur peut activer
• Sampling : le serveur peut demander au client de faire une inférence LLM (agents récursifs)

MCP vs Function Calling classique

Le function calling (OpenAI, Anthropic) permet déjà aux LLM d'appeler des fonctions. MCP apporte deux avantages supplémentaires :

• Standardisation : un serveur MCP fonctionne avec n'importe quel client compatible (Claude, Cursor, votre app custom) sans modification
• Découverte dynamique : le client découvre les outils disponibles au runtime via tools/list, sans configuration statique

Construire un serveur MCP pour AWS CLI

Voici un serveur MCP minimal en TypeScript qui expose des commandes AWS comme outils accessibles par un LLM :

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  CallToolRequestSchema,
  ListToolsRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";
import { exec } from "child_process";
import { promisify } from "util";

const execAsync = promisify(exec);

const server = new Server(
  { name: "aws-devops-mcp", version: "1.0.0" },
  { capabilities: { tools: {} } }
);

server.setRequestHandler(ListToolsRequestSchema, async () => ({
  tools: [
    {
      name: "list_ecs_services",
      description: "Liste les services ECS dans un cluster",
      inputSchema: {
        type: "object",
        properties: {
          cluster: { type: "string", description: "Nom du cluster ECS" },
          region: { type: "string", description: "Région AWS", default: "eu-west-1" },
        },
        required: ["cluster"],
      },
    },
    {
      name: "get_cloudwatch_logs",
      description: "Récupère les logs CloudWatch d'un log group",
      inputSchema: {
        type: "object",
        properties: {
          logGroupName: { type: "string" },
          minutes: { type: "number", default: 15 },
        },
        required: ["logGroupName"],
      },
    },
  ],
}));

server.setRequestHandler(CallToolRequestSchema, async (request) => {
  const { name, arguments: args } = request.params;

  if (name === "list_ecs_services") {
    const { stdout } = await execAsync(
      `aws ecs list-services --cluster ${args.cluster} --region ${args.region || "eu-west-1"} --output json`
    );
    return { content: [{ type: "text", text: stdout }] };
  }

  if (name === "get_cloudwatch_logs") {
    const startTime = Date.now() - (args.minutes || 15) * 60 * 1000;
    const { stdout } = await execAsync(
      `aws logs filter-log-events --log-group-name "${args.logGroupName}" --start-time ${startTime} --output json`
    );
    return { content: [{ type: "text", text: stdout }] };
  }

  throw new Error(`Unknown tool: ${name}`);
});

const transport = new StdioServerTransport();
server.connect(transport);

Serveur MCP pour Kubernetes

// Outil kubectl wrappé comme MCP tool
{
  name: "kubectl_get",
  description: "Exécute kubectl get sur un namespace et une ressource",
  inputSchema: {
    type: "object",
    properties: {
      resource: { type: "string", description: "Type de ressource (pods, services, deployments)" },
      namespace: { type: "string", default: "default" },
      selector: { type: "string", description: "Label selector optionnel" },
    },
    required: ["resource"],
  },
}

// Handler
const { stdout } = await execAsync(
  `kubectl get ${args.resource} -n ${args.namespace} ${args.selector ? '-l ' + args.selector : ''} -o json`
);

Intégration Claude Desktop

Pour connecter votre serveur MCP à Claude Desktop, ajoutez-le dans la configuration :

// ~/.config/claude/claude_desktop_config.json
{
  "mcpServers": {
    "aws-devops": {
      "command": "node",
      "args": ["/opt/mcp-servers/aws-devops/dist/index.js"],
      "env": {
        "AWS_PROFILE": "production",
        "AWS_DEFAULT_REGION": "eu-west-1"
      }
    },
    "kubernetes": {
      "command": "node",
      "args": ["/opt/mcp-servers/kubernetes/dist/index.js"],
      "env": {
        "KUBECONFIG": "/home/user/.kube/config"
      }
    }
  }
}

Serveur MCP pour GitHub

Le serveur MCP GitHub officiel (github.com/github/github-mcp-server) expose les opérations GitHub comme outils MCP :

• list_pull_requests : liste les PRs d'un repository
• create_issue : crée une issue GitHub
• get_file_contents : lit le contenu d'un fichier dans un repo
• search_code : recherche dans le code de l'organisation

Considérations de sécurité

Les serveurs MCP ont accès à des outils puissants — une validation rigoureuse est indispensable :

• Validation des inputs : valider tous les arguments avant d'exécuter des commandes shell (injection de commandes)
• Principe du moindre privilège : le serveur MCP ne doit avoir que les permissions minimales nécessaires
• Sandboxing : exécuter le serveur MCP dans un container avec capabilities limitées
• Audit log : logger toutes les invocations d'outils avec l'identité de l'utilisateur
• Allowlist de commandes : ne pas exposer de tool générique exec_command — définir des tools spécifiques avec validation

Déploiement en production d'un serveur MCP

Pour un serveur MCP utilisé par une équipe, déployez-le comme un service HTTP avec transport SSE :

// Serveur MCP avec transport HTTP/SSE
import { SSEServerTransport } from "@modelcontextprotocol/sdk/server/sse.js";
import express from "express";

const app = express();
const transports = new Map();

app.get("/mcp", (req, res) => {
  const transport = new SSEServerTransport("/mcp/message", res);
  transports.set(transport.sessionId, transport);
  server.connect(transport);
});

app.post("/mcp/message", (req, res) => {
  const transport = transports.get(req.query.sessionId);
  transport?.handlePostMessage(req, res);
});

app.listen(3000);

Écosystème des serveurs MCP

En 2026, l'écosystème MCP compte plusieurs centaines de serveurs open-source :

• Bases de données : PostgreSQL, MySQL, Redis, MongoDB
• Cloud : AWS, GCP, Azure, Terraform, Pulumi
• DevOps : GitHub, GitLab, Jira, PagerDuty, Datadog
• Productivité : Slack, Notion, Google Drive, Gmail
• Observabilité : Grafana, Prometheus, OpenSearch

Conclusion

MCP est en train de devenir le standard universel pour connecter les LLM aux outils d'entreprise. Sa simplicité (JSON-RPC sur stdio ou HTTP) et son modèle de sécurité explicite (le LLM ne peut faire que ce qu'un tool MCP autorise) en font une base solide pour construire des agents IA fiables dans des contextes DevOps. La clé du succès : définir des tools avec des interfaces claires et des validations rigoureuses plutôt que d'exposer des outils génériques non bornés.