--- id: a1fad13de24c90924cfa9e25e9f986cb author: snowmerak title: Essayer de comprendre un peu l'hôte MCP description: Il s'agit d'un article visant à faciliter la compréhension du protocole MCP d'Anthropic et de l'hôte MCP (mcphost) implémenté en Go. language: fr date: 2025-04-08T00:59:42.416582136Z path: /blog/posts/a-little-understanding-of-mcp-host-zb952aae0 category: ai --- ## Qu'est-ce que MCP [MCP](https://modelcontextprotocol.io/introduction) est un protocole développé par Anthropic pour Claude. MCP est l'abréviation de Model Context Protocol, un protocole qui permet aux LLM de demander activement des actions ou des ressources à l'extérieur. Comme MCP n'est littéralement qu'un protocole de requêtes et de réponses, le processus et l'exécution doivent être implémentés par le développeur. ### À propos du fonctionnement interne Avant d'expliquer le fonctionnement interne, je voudrais évoquer [Gemini Function Calling](https://ai.google.dev/gemini-api/docs/function-calling). Gemini Function Calling permet également, comme MCP, au LLM d'invoquer de manière proactive des actions externes. On pourrait alors se demander pourquoi avoir introduit Function Calling. La raison est que Function Calling est apparu avant MCP et qu'il utilise de manière identique le schéma OpenAPI, ce qui le rend compatible; j'ai donc supposé que son fonctionnement serait similaire. Par conséquent, comme la documentation de Gemini Function Calling est relativement plus détaillée, j'ai jugé utile de l'inclure. ![FunctionCalling](/assets/images/mcp_with_csharp/function-calling-overview.png) Le flux global se présente ainsi. 1. On définit une fonction. 2. On envoie à Gemini la définition de la fonction accompagnée du prompt. 1. "Send user prompt along with the function declaration(s) to the model. It analyzes the request and determines if a function call would be helpful. If so, it responds with a structured JSON object." 3. Gemini demande un appel de fonction si nécessaire. 1. Si Gemini le juge nécessaire, l'appelant reçoit le nom et les paramètres de l'appel de fonction. 2. L'appelant peut décider d'exécuter ou non l'appel. 1. Effectuer l'appel et renvoyer une valeur légitime 2. Ne pas effectuer l'appel et renvoyer des données comme si celui-ci avait été effectué 3. Simplement l'ignorer 4. Gemini effectue et demande plusieurs appels de fonctions en une seule fois, ou appelle à nouveau une fonction après avoir examiné le résultat d'un appel précédent. 5. Lorsqu'une réponse structurée est finalement produite, le processus se termine. Ce flux est globalement cohérent avec MCP. Il est d'ailleurs décrit de manière similaire dans le [tutoriel MCP](https://modelcontextprotocol.io/tutorials/building-mcp-with-llms). Il en va de même pour ollama tools. Et, heureusement, ces trois outils, ollama tools, MCP et Gemini Function Calling, partagent presque la même structure de schéma; ainsi, en n'implémentant que MCP, on peut l'utiliser dans les trois contextes. Ah, et il existe un inconvénient commun à tous. Comme c'est le modèle qui exécute ces appels, si le modèle que vous utilisez est de mauvaise qualité, il peut ne pas appeler la fonction, l'appeler de manière incorrecte, ou encore envoyer une attaque DoS au serveur MCP, entre autres dysfonctionnements. ## Hôte MCP en Go ### mcphost de mark3lab En Go, il existe [mcphost](https://github.com/mark3labs/mcphost), développé par l'organisation mark3lab. Son utilisation est très simple. ```sh go install github.com/mark3labs/mcphost@latest ``` Après l'installation, créez le fichier `$HOME/.mcp.json` et rédigez-le comme suit. ```json { "mcpServers": { "sqlite": { "command": "uvx", "args": [ "mcp-server-sqlite", "--db-path", "/tmp/foo.db" ] }, "filesystem": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-filesystem", "/tmp" ] } } } ``` Ensuite, exécutez-le avec le modèle ollama comme suit. Bien entendu, si nécessaire, téléchargez d'abord le modèle avec `ollama pull mistral-small`. > En règle générale, Claude ou qwen2.5 sont recommandés, mais pour le moment, je recommande mistral-small. ```sh mcphost -m ollama:mistral-small ``` Cependant, avec cette exécution, vous ne pouvez l'utiliser qu'en mode questions-réponses dans un environnement CLI. C'est pourquoi nous allons modifier le code de ce `mcphost` afin de le rendre plus programmable. ### Fork de mcphost Comme nous l'avons vu, `mcphost` intègre des fonctionnalités qui utilisent MCP pour extraire des métadonnées et appeler des fonctions. Il faut donc une partie qui appelle le LLM, une partie qui gère le serveur MCP et une partie qui gère l'historique des messages. Le `Runner` du package suivant reprend ces parties. ```go package runner import ( "context" "encoding/json" "fmt" "log" "strings" "time" mcpclient "github.com/mark3labs/mcp-go/client" "github.com/mark3labs/mcp-go/mcp" "github.com/mark3labs/mcphost/pkg/history" "github.com/mark3labs/mcphost/pkg/llm" ) type Runner struct { provider llm.Provider mcpClients map[string]*mcpclient.StdioMCPClient tools []llm.Tool messages []history.HistoryMessage } ``` Je ne m'attarderai pas sur les déclarations internes de cette partie. Elles correspondent presque exactement à leurs noms. ```go func NewRunner(systemPrompt string, provider llm.Provider, mcpClients map[string]*mcpclient.StdioMCPClient, tools []llm.Tool) *Runner { return &Runner{ provider: provider, mcpClients: mcpClients, tools: tools, messages: []history.HistoryMessage{ { Role: "system", Content: []history.ContentBlock{{ Type: "text", Text: systemPrompt, }}, }, }, } } ``` Pour les `mcpClients` et `tools` utilisés ici, veuillez consulter [ce fichier](https://github.com/snowmerak/mcphost/blob/main/internal/runner/from.go). Pour le `provider`, nous utiliserons celui d'ollama; veuillez consulter [ce fichier](https://github.com/snowmerak/mcphost/blob/main/pkg/llm/ollama/provider.go). Le plat principal est la méthode `Run`. ```go func (r *Runner) Run(ctx context.Context, prompt string) (string, error) { if len(prompt) != 0 { r.messages = append(r.messages, history.HistoryMessage{ Role: "user", Content: []history.ContentBlock{{ Type: "text", Text: prompt, }}, }) } llmMessages := make([]llm.Message, len(r.messages)) for i := range r.messages { llmMessages[i] = &r.messages[i] } const initialBackoff = 1 * time.Second const maxRetries int = 5 const maxBackoff = 30 * time.Second var message llm.Message var err error backoff := initialBackoff retries := 0 for { message, err = r.provider.CreateMessage( context.Background(), prompt, llmMessages, r.tools, ) if err != nil { if strings.Contains(err.Error(), "overloaded_error") { if retries >= maxRetries { return "", fmt.Errorf( "claude is currently overloaded. please wait a few minutes and try again", ) } time.Sleep(backoff) backoff *= 2 if backoff > maxBackoff { backoff = maxBackoff } retries++ continue } return "", err } break } var messageContent []history.ContentBlock var toolResults []history.ContentBlock messageContent = []history.ContentBlock{} if message.GetContent() != "" { messageContent = append(messageContent, history.ContentBlock{ Type: "text", Text: message.GetContent(), }) } for _, toolCall := range message.GetToolCalls() { input, _ := json.Marshal(toolCall.GetArguments()) messageContent = append(messageContent, history.ContentBlock{ Type: "tool_use", ID: toolCall.GetID(), Name: toolCall.GetName(), Input: input, }) parts := strings.Split(toolCall.GetName(), "__") serverName, toolName := parts[0], parts[1] mcpClient, ok := r.mcpClients[serverName] if !ok { continue } var toolArgs map[string]interface{} if err := json.Unmarshal(input, &toolArgs); err != nil { continue } var toolResultPtr *mcp.CallToolResult req := mcp.CallToolRequest{} req.Params.Name = toolName req.Params.Arguments = toolArgs toolResultPtr, err = mcpClient.CallTool( context.Background(), req, ) if err != nil { errMsg := fmt.Sprintf( "Error calling tool %s: %v", toolName, err, ) log.Printf("Error calling tool %s: %v", toolName, err) toolResults = append(toolResults, history.ContentBlock{ Type: "tool_result", ToolUseID: toolCall.GetID(), Content: []history.ContentBlock{{ Type: "text", Text: errMsg, }}, }) continue } toolResult := *toolResultPtr if toolResult.Content != nil { resultBlock := history.ContentBlock{ Type: "tool_result", ToolUseID: toolCall.GetID(), Content: toolResult.Content, } var resultText string for _, item := range toolResult.Content { if contentMap, ok := item.(map[string]interface{}); ok { if text, ok := contentMap["text"]; ok { resultText += fmt.Sprintf("%v ", text) } } } resultBlock.Text = strings.TrimSpace(resultText) toolResults = append(toolResults, resultBlock) } } r.messages = append(r.messages, history.HistoryMessage{ Role: message.GetRole(), Content: messageContent, }) if len(toolResults) > 0 { r.messages = append(r.messages, history.HistoryMessage{ Role: "user", Content: toolResults, }) return r.Run(ctx, "") } return message.GetContent(), nil } ``` Le code lui-même a été assemblé à partir d'une partie du code de [ce fichier](https://github.com/snowmerak/mcphost/blob/main/cmd/mcp.go). Le contenu peut se résumer ainsi. 1. On envoie la liste des outils avec le prompt pour demander soit une exécution, soit la génération d'une réponse. 2. Lorsqu'une réponse est générée, on arrête la récursion et on la renvoie. 3. Si le LLM demande l'exécution d'un outil, l'hôte appelle le serveur MCP. 4. On ajoute le résultat à l'historique, puis on revient à l'étape 1. ## Pour conclure > Déjà la fin? En réalité, je n'ai pas grand-chose de plus à dire. Cet article a été rédigé pour vous aider à comprendre, en gros, le fonctionnement d'un serveur MCP. J'espère qu'il vous a été utile, même modestement, pour comprendre le fonctionnement d'un hôte MCP.