Technical Tutorials

Le Protocole de Contexte de Modèle (MCP) s'est rapidement imposé comme le « USB-C de l'IA », offrant une méthode standardisée pour connecter les grands modèles de langage (LLM) aux sources de données et outils externes. Bien que les premières implémentations aient souvent reposé sur l'Entrée/Sortie Standard locale (stdio) pour la simplicité, la transition vers les transports HTTP est une évolution cruciale pour les environnements de production, les systèmes distribués et les architectures multi-locataires.

Ce guide explore les mécanismes du MCP via HTTP, en détaillant la structure sous-jacente de JSON-RPC, les implications en matière de sécurité et des exemples de code pour l'implémentation des côtés client et serveur.

Pourquoi aller au-delà de Stdio ?

Le transport standard stdio est idéal pour le développement local et les outils CLI à utilisateur unique. Cependant, il présente des limitations significatives dans les scénarios à grande échelle :

Isolation : Stdio exige que le modèle et l'outil fonctionnent sur la même machine et dans l'arborescence de processus.
Évolutivité : Il ne prend pas nativement en charge l'équilibrage de charge ou le dimensionnement horizontal.
Sécurité : Le lancement direct de processus est moins sécurisé que les services réseau avec des couches d'authentification appropriées.

HTTP (spécifiquement HTTP/1.1 ou HTTP/2) offre une communication sans état, un support robuste des middlewares et une accessibilité mondiale, ce qui en fait le choix naturel pour exposer les serveurs MCP aux instances LLM distantes.

L'Architecture : JSON-RPC via HTTP

Le MCP n'est pas seulement une couche de transport ; c'est un protocole sémantique. Lorsqu'il est déployé via HTTP, le MCP utilise JSON-RPC 2.0 comme format de message. Chaque interaction consiste en un objet JSON contenant une méthode, des paramètres et un ID.

Méthodes clés

Les fonctionnalités de base exposées par un serveur MCP incluent :

tools/list : Découvrir les outils disponibles.
tools/call : Appeler un outil spécifique avec des arguments.
resources/list : Accéder aux ressources de données disponibles.

Exemples d'implémentation

1. Le gestionnaire côté serveur (Exemple Node.js/Express)

Ci-dessous se trouve un exemple minimal de la manière dont un serveur MCP gère une requête HTTP POST entrante. Notez que le MCP via HTTP utilise généralement un point de terminaison unique (par exemple, /mcp) qui achemine les requêtes en fonction du champ method dans le corps JSON.

const express = require('express');
const app = express();
app.use(express.json());

app.post('/mcp', (req, res) => {
    const { method, params, id } = req.body;

    // Routage de base basé sur les méthodes MCP
    switch (method) {
        case 'tools/list':
            res.json({
                jsonrpc: '2.0',
                id,
                result: {
                    tools: [
                        {
                            name: 'get_weather',
                            description: 'Get current weather data',
                            inputSchema: {
                                type: 'object',
                                properties: {
                                    city: { type: 'string' }
                                },
                                required: ['city']
                            }
                        }
                    ]
                }
            });
            break;
            
        case 'tools/call':
            // Implémentez votre logique d'outil ici
            const cityName = params.arguments.city;
            res.json({
                jsonrpc: '2.0',
                id,
                result: {
                    content: [{ type: 'text', text: `Sunny in ${cityName}, 75°F` }]
                }
            });
            break;

        default:
            res.json({
                jsonrpc: '2.0',
                id,
                error: { code: -32601, message: 'Method not found' }
            });
    }
});

app.listen(3000, () => console.log('MCP Server running on port 3000'));

2. La requête côté client

L'application LLM (ou son middleware) agit en tant que client MCP. Elle envoie une requête POST avec la charge utile JSON-RPC. Il est crucial de gérer correctement les dépassements de délai et les réponses asynchrones, car les appels d'outils peuvent être longs.

const fetch = require('node-fetch');

async function callMCPTool(toolName, args) {
    const response = await fetch('http://localhost:3000/mcp', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
            jsonrpc: '2.0',
            method: 'tools/call',
            params: {
                name: toolName,
                arguments: args
            },
            id: '12345'
        })
    });

    const data = await response.json();
    if (data.error) {
        throw new Error(data.error.message);
    }
    return data.result;
}

// Utilisation
callMCPTool('get_weather', { city: 'New York' }).then(console.log);

Considérations de sécurité

L'exposition des outils MCP via HTTP introduit des surfaces d'attaque qui n'existent pas dans les environnements stdio locaux. Les développeurs doivent mettre en œuvre des contrôles de sécurité stricts :

Authentification : Exigez toujours des clés API, des jetons OAuth 2.0 ou du mTLS. N'exposez jamais un serveur MCP sur Internet public sans authentification.
Autorisation : Assurez-vous que le contexte du LLM ne permet pas l'élévation de privilèges. Le serveur doit vérifier que l'utilisateur demandeur a la permission d'appeler des outils spécifiques.
Validation des entrées : Validez strictement tous les arguments passés aux outils. Étant donné que le LLM génère l'entrée, il peut produire du JSON malformé ou malveillant. Utilisez la validation de schéma (par exemple, Zod, Joi) côté serveur.
Limitation de débit : Mettez en œuvre des limites de débit pour prévenir les abus ou les dépassements de coûts associés aux appels d'API externes effectués par les outils.

Meilleures pratiques pour la production

Utiliser HTTPS : Chiffrez toujours le trafic en transit.
Absence d'état : Concevez votre serveur MCP pour qu'il soit sans état autant que possible afin de permettre un dimensionnement horizontal facile.
Journalisation : Journalisez tous les appels d'outils à des fins d'audit. Suivez quelle instance LLM a appelé quel outil avec quels paramètres.
Versionnage : Incluez le versionnage dans votre URL ou vos en-têtes (par exemple, /mcp/v1) pour gérer les modifications cassantes des schémas d'outils.

Conclusion

La transition du MCP de stdio à HTTP est une étape nécessaire pour construire des applications IA robustes et évolutives. En exploitant le format standard JSON-RPC 2.0 via des points de terminaison HTTP sécurisés, les développeurs peuvent créer des écosystèmes d'outils modulaires et réutilisables qui peuvent être partagés entre différents fournisseurs de LLM et environnements de déploiement. À mesure que l'écosystème MCP mûrit, on peut s'attendre à voir des fonctionnalités plus riches, telles que les réponses en streaming et le lien de ressources complexes, devenir standard sur les transports HTTP.