Alege transportul în mod deliberat
Un server stdio local și un serviciu HTTP la distanță au nevoi de implementare diferite. Folosiți un transport la distanță acceptat, TLS și o rută autentificată. Verificați versiunile clientului și serverului în loc să presupuneți că fiecare implementare acceptă aceleași capabilități.
Tratează fiecare instrument ca pe un API
Validați argumentele, aplicați autorizarea specifică utilizatorului și limitați resursele. Nu expuneți execuția arbitrară de shell ca instrument de comoditate. Restrângeți destinațiile de ieșire atunci când un instrument preia URL și țineți secretele în afara descrierilor și răspunsurilor.
Păstrați colectarea identității proporțională
Un furnizor fără KYC poate minimiza datele de înregistrare la furnizor, dar serviciul MCP poate avea în continuare nevoie de propriii utilizatori, de securitatea sesiunilor și de controale împotriva abuzurilor. Explicați ce jurnalizează și evitați păstrarea intrărilor instrumentelor fără un scop definit.
Implementați pentru claritate operațională
Rulați sub un utilizator dedicat, folosiți verificări de stare, limitați timpii de solicitare și mențineți bufferingul și timeout-urile proxy-ului invers compatibile cu protocolul. Testați autentificarea, revocarea, deconectările și reîncercările înainte de a acorda privilegii de scriere.
Aliniază autentificarea cu protocolul acceptat
Pentru un deployment MCP bazat pe HTTP, examinează cerințele actuale de autorizare ale protocolului și versiunea suportată de client. Accesul la resurse bazat pe OAuth implică audiența tokenului, descoperirea și scopul, nu doar o parolă pe pagina principală. Folosește HTTPS, validează tokenurile pentru resursa vizată și ține credențialele bearer în afara șirurilor de interogare. Un server stdio folosește o graniță locală diferită pentru credențiale.
- Testați o cerere neautentificată
- Testează o cerere autentificată în afara domeniului său de aplicare
- Revocați o acreditare și verificați că nu mai funcționează
Documentație oficială: Specificația de autorizare MCP
Publică un prim set de instrumente limitat
Începe cu instrumente doar pentru citire care returnează o cantitate limitată de date. Adaugă scrieri de fișiere, operațiuni asupra ciclului de viață al serverului sau mesaje externe doar după ce permisiunile și comportamentul la duplicate sunt înțelese. Tratează paginile web și documentele returnate ca date nesigure; acestea nu trebuie să extindă în mod silențios autoritatea serverului de instrumente.
Fixați comportamentul protocolului înainte de a scrie reguli de proxy
Înregistrați atât versiunea SDK a serverului, cât și revizia MCP pe care o va folosi clientul. În revizia 2026-07-28 Streamable HTTP, cererile folosesc un endpoint POST; exemplele mai vechi care se bazează pe sesiuni de protocol sau pe un flux GET independent reprezintă o altă revizie. Nu eliminați o cerință aparentă de compatibilitate până când nu știți ce client acceptați. Un proxy invers trebuie să păstreze antetele necesare, starea HTTP și comportamentul de streaming al răspunsului pentru acea versiune.
- Începeți cu un instrument cu acces doar în citire pe un listener loopback, apoi plasați în fața acestuia granița de HTTPS/autentificare dorită.
- Testați un rezultat normal, un rezultat în streaming, un timeout și un client deconectat prin proxy-ul public.
- Validați valorile Origin permise conform cerințelor transportului; o verificare Origin nu înlocuiește autentificarea apelantului.
- Dacă evenimentele sosesc doar la final, inspectează memorarea în buffer a proxy-ului și comportamentul la expirarea timpului înainte de a modifica codul instrumentelor.
Documentație oficială: MCP 2026-07-28: HTTP transmisibil
Testați eșecurile de autorizare la fel de deliberat ca succesul
Pentru accesul HTTP protejat prin OAuth, serverul MCP este o resursă protejată. Testează descoperirea metadatelor, emitentul așteptat și audiența tokenului, precum și domeniile de aplicare necesare pentru o anumită operațiune. Ține tokenul de autorizare în afara șirurilor de interogare URL și nu îl transmite niciodată neschimbat către un serviciu downstream fără legătură. O eroare de autentificare orientată către client trebuie să păstreze provocarea HTTP corespunzătoare, astfel încât clientul să se poată recupera prin fluxul său acceptat.
- Fără token sau cu un token expirat: punctul final protejat respinge accesul în loc să returneze date private ale instrumentelor.
- Token valid cu permisiuni insuficiente: resursa solicitată rămâne inaccesibilă.
- Token pentru alt public: respinge-l chiar dacă semnătura sa este altfel validă.
- URL extern sau cale de fișier neașteptată: validați față de autoritatea instrumentului înainte de a prelua sau scrie.
- Jurnale și urme de erori: păstrează un identificator de operațiune și rezultatul, eliminând tokenurile și intrările private ale instrumentelor.
Documentație oficială: MCP 2026-07-28: autorizare HTTP · MCP: bune practici de securitate