--- id: a1fad13de24c90924cfa9e25e9f986cb author: snowmerak title: Capire meglio gli MCP host description: Questo articolo si propone di favorire la comprensione del protocollo MCP di Anthropic e di mcphost, un host MCP implementato in Go. language: it date: 2025-04-08T00:59:42.416582136Z path: /blog/posts/a-little-understanding-of-mcp-host-zb952aae0 category: ai --- ## Cos'è MCP [MCP](https://modelcontextprotocol.io/introduction) è un protocollo sviluppato da Anthropic per Claude. MCP è l'acronimo di Model Context Protocol e consente a un LLM di richiedere attivamente azioni o risorse dall'esterno. MCP è, letteralmente, un protocollo che si limita a fornire richieste e risposte; pertanto, il processo e l'esecuzione devono essere implementati dallo sviluppatore. ### Sul funzionamento interno Prima di descrivere il funzionamento interno, vorrei soffermarmi su [Gemini Function Calling](https://ai.google.dev/gemini-api/docs/function-calling). Gemini Function Calling, così come MCP, consente a un LLM di invocare attivamente operazioni esterne. A questo punto potrebbe sorgere il dubbio sul motivo per cui sia stato introdotto Function Calling. La ragione è che Function Calling è apparso prima di MCP e, poiché utilizza lo stesso schema OpenAPI, risulta compatibile; si è quindi ipotizzato che il suo comportamento sia simile. Di conseguenza, poiché la documentazione di Gemini Function Calling è relativamente più dettagliata, si è ritenuto che potesse essere utile e lo si è quindi incluso. ![FunctionCalling](/assets/images/mcp_with_csharp/function-calling-overview.png) Il flusso complessivo è il seguente. 1. Si definisce una funzione. 2. Si invia a Gemini la definizione della funzione insieme al 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. Se necessario, Gemini richiede una chiamata di funzione. 1. Se Gemini lo ritiene necessario, il chiamante riceve il nome e i parametri per la chiamata di funzione. 2. Il chiamante può decidere se eseguire o meno la chiamata. 1. Eseguire la chiamata e restituire un valore legittimo 2. Non eseguire la chiamata e restituire dati come se fosse stata eseguita 3. Ignorarla semplicemente 4. Nel corso di questo processo, Gemini può richiedere l'esecuzione di più funzioni contemporaneamente, oppure, dopo aver osservato il risultato di una funzione, richiederne un'altra. 5. Quando si ottiene una risposta ordinata, il processo termina. Questo flusso è, in generale, coerente con quello di MCP. Ne viene data una descrizione simile anche nel [tutorial di MCP](https://modelcontextprotocol.io/tutorials/building-mcp-with-llms). Anche ollama tools presenta un comportamento analogo. Inoltre, fortunatamente, questi tre strumenti, ollama tools, MCP e Gemini Function Calling, condividono quasi la stessa struttura dello schema, quindi implementando solo MCP è possibile utilizzarlo in tutti e tre i contesti. Ah, e c'è anche uno svantaggio comune a tutti: poiché è il modello a eseguire effettivamente le chiamate, se il modello utilizzato non è in buone condizioni, può non invocare le funzioni, invocarle in modo errato oppure inviare richieste DoS al server MCP, causando così comportamenti anomali. ## Host MCP in Go ### mcphost di mark3lab In Go esiste [mcphost](https://github.com/mark3labs/mcphost), in fase di sviluppo presso l'organizzazione mark3lab. L'utilizzo è molto semplice. ```sh go install github.com/mark3labs/mcphost@latest ``` Dopo l'installazione, si crea il file `$HOME/.mcp.json` con il seguente contenuto. ```json { "mcpServers": { "sqlite": { "command": "uvx", "args": [ "mcp-server-sqlite", "--db-path", "/tmp/foo.db" ] }, "filesystem": { "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-filesystem", "/tmp" ] } } } ``` Quindi lo si esegue con un modello di ollama come segue. Naturalmente, se necessario, prima si scarica il modello con `ollama pull mistral-small`. > In generale si consigliano Claude o qwen2.5, ma per il momento io suggerisco mistral-small. ```sh mcphost -m ollama:mistral-small ``` Tuttavia, eseguendo in questo modo, è possibile utilizzarlo solo in modalità domanda e risposta nell'ambiente CLI. Per questo motivo, modificheremo il codice di questo `mcphost` per renderlo più programmabile. ### Fork di mcphost Come già visto, `mcphost` include la funzionalità di estrazione dei metadati e di invocazione delle funzioni tramite MCP. Pertanto, sono necessarie la parte che chiama l'LLM, quella che gestisce il server MCP e quella che gestisce la cronologia dei messaggi. La parte corrispondente è stata estratta nel `Runner` del seguente package. ```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 } ``` Non esamineremo separatamente le dichiarazioni interne di questa parte. Sono comunque quasi identiche ai loro nomi. ```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, }}, }, }, } } ``` Per `mcpClients` e `tools`, utilizzati qui, si veda [il file corrispondente](https://github.com/snowmerak/mcphost/blob/main/internal/runner/from.go). Per `provider`, utilizzeremo quello di ollama, quindi si veda [il file corrispondente](https://github.com/snowmerak/mcphost/blob/main/pkg/llm/ollama/provider.go). Il piatto principale è il metodo `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 } ``` Il codice stesso è stato ottenuto combinando parti del [file corrispondente](https://github.com/snowmerak/mcphost/blob/main/cmd/mcp.go). In sintesi, il contenuto è il seguente. 1. Si invia la lista degli strumenti insieme al prompt, richiedendo se eseguire una chiamata o generare una risposta. 2. Quando viene generata una risposta, la ricorsione si interrompe e il risultato viene restituito. 3. Se l'LLM richiede l'esecuzione di uno strumento, l'host invoca il server MCP. 4. Si aggiunge il risultato alla cronologia e si torna al punto 1. ## Conclusioni > Già finito? In realtà non c'è molto altro da dire. Questo articolo è stato scritto principalmente per aiutare a comprendere in linea generale il funzionamento di un server MCP. Spero che questo testo abbia contribuito, anche se in misura modesta, a far capire il funzionamento di un host MCP.