Arhitectura MCP: Host, Client și Server în Model Context Protocol (MCP)

Host → Client (1:1) → Server; cereri JSON-RPC 2.0 fără stare, cu _meta per cerere

Ce face Arhitectura MCP: Host, Client și Server

MCP folosește o arhitectură client-host-server bazată pe JSON-RPC 2.0. Host-ul este aplicația LLM (de exemplu un IDE sau o aplicație de chat): creează și administrează mai mulți clienți, controlează permisiunile și ciclul de viață al conexiunilor, aplică politicile de securitate și consimțământ, ia deciziile de autorizare ale utilizatorului și coordonează integrarea cu LLM-ul. Fiecare client comunică cu exact un server, iar serverele oferă context și capabilități specializate, ca procese locale sau servicii remote.

Din revizia 2026-07-28, MCP este un protocol fără stare: fiecare cerere este independentă și își poartă versiunea de protocol și capabilitățile clientului în _meta. Nu mai există handshake initialize; clientul poate afla dinainte capabilitățile serverului cu server/discover. Când serverul are nevoie de input de la client (elicitare, sampling, roots), îl cere în răspuns printr-un InputRequiredResult, iar clientul reîncearcă cererea.

Serverele expun trei primitive: Prompts (controlate de utilizator, de exemplu comenzi slash), Resources (controlate de aplicație: date de context) și Tools (controlate de model: funcții pe care LLM-ul le apelează). Clienții pot oferi Elicitation; Sampling și Roots există încă, dar sunt depreciate. Unul dintre principiile de design: serverele nu pot citi toată conversația și nu pot „vedea” în alte servere; istoricul complet rămâne la host, care controlează interacțiunile dintre servere.

Sintaxă și opțiuni

Opțiune / Parametru	Descriere
Host	Containerul și coordonatorul: creează clienții, aplică consimțământul și securitatea, integrează LLM-ul.
Client	Creat de host; relație 1:1 cu un server; atașează versiunea și capabilitățile la fiecare cerere; gestionează abonările.
Server	Expune resurse, unelte și prompturi; cere input clientului prin InputRequiredResult.
Tools	Controlate de model. tools/list, tools/call.
Resources	Controlate de aplicație. resources/list, resources/read, resources/templates/list.
Prompts	Controlate de utilizator. prompts/list, prompts/get.
Elicitation / Sampling / Roots	Funcții oferite de client; Sampling și Roots sunt depreciate din 2026-07-28.
Negocierea capabilităților	Clientul le trimite în _meta la fiecare cerere; serverul le anunță în server/discover.

Exemple practice

Exemplul 1: Fluxul unei cereri în revizia 2026-07-28

Rezumat al diagramei de negociere a capabilităților din specificație.

Client -> Server: server/discover (opțional)
Server -> Client: versiuni suportate + capabilități
Client -> Server: tools/call (cu _meta: versiune, clientCapabilities)
Server -> Client: InputRequiredResult (dacă îi trebuie input)
Client -> Server: tools/call (id nou, cu inputResponses)
Server -> Client: rezultat final

Exemplul 2: Descoperirea uneltelor

Câmpurile _meta obligatorii sunt omise, ca în exemplele din specificație.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {
    "cursor": "optional-cursor-value"
  }
}

Greșeli frecvente și bune practici

• Tratezi o conexiune (de exemplu un proces stdio) ca pe o sesiune sau conversație. Specificația spune explicit că nu este; clienții pot intercala cereri fără legătură pe același transport.
• Construiești un server monolitic pentru toate serviciile. Principiile de design cer servere cu responsabilități focalizate, care se pot combina.
• Te bazezi pe adnotările uneltelor primite de la servere necunoscute. Ele sunt indicii neverificate.

Comenzi înrudite

• mcp-metode-referinta
• mcp-server-discover
• mcp-tools-primitive
• mcp-resources-uri
• mcp-transport-stdio-http