El protocol de context model ha assolit una fita important en la infraestructura: la seva revisió el 28-07-2026 trasllada el protocol cap a un nucli sense estat. Per a sistemes d'agents de creació d'equips, servidors d'eines, integracions IDE o capes d'orquestració multimodel, aquesta no és una actualització d'especificacions estètica. Canvia les hipòtesis sobre les sessions, la inicialització, l'escalat, la compatibilitat i el govern.

El candidat a la versió de MCP va descriure l'especificació del 28 de juliol com l'addició d'un nucli de protocol sense estat, un marc d'extensions, tasques, aplicacions MCP, enduriment de l'autorització i una política de desús formal. El bloc oficial de MCP també va advertir que el llançament conté canvis de ruptura. GitHub, que opera una de les implementacions de servidor MCP més visibles, va dir abans de la versió final que el seu servidor MCP ja admetia la nova especificació i va descriure el protocol com a "sense estat" el 28 de juliol.

El significat pràctic és senzill: MCP s'està configurant menys com una capa d'integració local a escala de sessió i més com un protocol d'accés remot a Internet. Això és important perquè els sistemes d'agent ja no es limiten a les eines de desenvolupament d'escriptori. S'executen cada cop més dins de serveis al núvol, sistemes CI, fluxos de treball d'atenció al client, rastrejadors de problemes i plataformes d'automatització empresarial.

El que va canviar a MCP

El canvi de titular és el pas a un nucli de protocol sense estat. El registre de canvis de GitHub diu que el nou nucli elimina les sessions i s'inicia, amb l'objectiu de fer que els desplegaments MCP remots siguin més fàcils d'escalar. És un canvi arquitectònic important. Els protocols amb estat poden funcionar bé per a eines locals i entorns controlats, però compliquen l'escalat horitzontal, l'execució sense servidor, la migració per error, el desplegament de punta i l'equilibri de càrrega.

Un nucli sense estat ofereix als implementadors més llibertat per executar servidors MCP darrere d'una infraestructura web normal. Les sol·licituds es poden distribuir entre instàncies sense conservar una sessió de llarga durada en un backend específic. Per a les grans organitzacions, això pot reduir la complexitat operativa. Per als equips més petits, pot fer que els servidors MCP allotjats siguin més fàcils de desplegar mitjançant la informàtica gestionada en lloc d'una infraestructura personalitzada de llarga durada.

La versió més àmplia del 28-07-2026 també introdueix un marc d'extensions i tasques, segons els materials candidats a la versió. Aquestes addicions suggereixen que MCP s'està tornant més modular i més explícit sobre el treball de llarga durada. Les aplicacions MCP i l'enduriment de l'autorització van en la mateixa direcció: el protocol està madurant des de la cola inicial de l'ecosistema fins a una capa més formal per a la interacció entre l'agent i l'eina.

El cost d'aquesta maduració és el treball de compatibilitat. El bloc MCP va caracteritzar el llançament com un amb canvis de ruptura, i els materials TypeScript i C# SDK publicats al voltant de la revisió se centren en el suport de la migració i els conceptes sense estat. Qualsevol equip que utilitzi un servidor MCP, que incrusti MCP en una extensió IDE o que encamine les trucades a l'agent mitjançant la infraestructura interna hauria de tractar la revisió com un esdeveniment d'enginyeria en lloc d'una actualització d'estàndards en segon pla.

Per què l'MCP sense estat és important per als desenvolupadors i els operadors

Les eines d'agent tenen un problema d'escala que sembla diferent de l'escala de l'API normal. Una sol·licitud d'un sol usuari pot activar moltes trucades d'eines, girs de model, reintents, lectures de fitxers, consultes de cerca i passos d'aprovació. Quan el protocol de l'eina assumeix sessions duradores, els operadors de producció han de conservar l'estat d'aquestes interaccions o crear solucions alternatives al protocol.

En suprimir sessions del nucli, MCP s'adapta millor als entorns on les càrregues de treball de l'agent són explosives, distribuïdes i asíncrones. Les funcions sense servidor, els treballadors perifèrics, els desplegaments de Kubernetes i els sistemes multiregionals es beneficien quan les sol·licituds es poden gestionar de manera independent. Això no elimina l'estat de les aplicacions d'agent; trasllada l'estat a bases de dades d'aplicacions, cues de tasques, sistemes d'identitat o capes de flux de treball explícites en lloc d'incrustar-lo al nucli del protocol.

Per als desenvolupadors, el canvi hauria de facilitar el consum dels servidors d'eines remotes. Per als equips de plataforma, pot simplificar l'observabilitat i la planificació de la capacitat. En lloc de depurar el comportament d'afinitat de sessió opaca, els operadors poden centrar-se en els rastres a nivell de sol·licitud, la latència de trucades d'eines, les decisions d'autorització i els patrons d'error.

També hi ha un angle de govern. A mesura que MCP es fa més comú als assistents de codificació i als agents empresarials, les empreses necessitaran polítiques sobre quines eines poden trucar els agents, a quines dades poden accedir i quins usuaris o serveis poden invocar-los. Per tant, l'enduriment de l'autorització en la nova revisió no és casual.Reflecteix la realitat que l'accés a les eines és ara un límit de seguretat, no només una comoditat per a desenvolupadors.

Qui es veu afectat

Els grups més directament afectats són els mantenedors de servidors MCP, els usuaris d'SDK, els equips de plataforma d'agents i les organitzacions que exposen les eines internes als agents d'IA. Si un servidor depèn del comportament de la sessió o de fluxos d'inicialització anteriors, caldrà provar-lo amb la nova especificació. Si una aplicació admet diverses versions d'MCP, pot ser que necessiti negociació de versions, capes de compatibilitat o un pla de migració per fases.

També s'inclouen els proveïdors d'IDE i d'eines per a desenvolupadors. MCP apareix cada cop més al costat d'agents de codificació, agents personalitzats i funcions de gestió de models. Un nucli de protocol sense estat facilita que aquests productes puguin trucar a eines remotes de manera fiable, però només si les seves integracions segueixen el ritme de les especificacions.

Les empreses que utilitzen l'automatització d'agents haurien de prestar atenció encara que no llegeixin mai l'especificació MCP. El canvi pot afectar la fiabilitat dels agents que es connecten a dipòsits, sistemes de tickets, bases de dades, bases de coneixement internes o eines de desplegament. Durant les finestres de migració, els possibles modes de fallada no només són interrupcions evidents. Poden incloure capacitats d'eines que falten, comportament d'autenticació canviat o agents que prenen camins diferents perquè un servidor d'eines ja no es comporta com s'esperava.

Per a una passarel·la d'API d'IA com ara Model Gate, la connexió és pràctica. Una API d'IA unificada es troba cada cop més a prop de l'encaminament del model, la gestió de claus de l'API, l'anàlisi d'ús i el govern de l'API d'equip. A mesura que els sistemes d'agent afegeixen trucades a l'eina MCP a més de les trucades de model normals, les capes de passarel·la i d'observabilitat hauran de tenir en compte ambdues parts del flux de treball: quin model s'ha utilitzat, quines eines s'han invocat, quin cost, qui les ha autoritzat i on s'han produït errors.

Prioritats de migració i preguntes obertes

La primera prioritat de migració és la prova de compatibilitat. Els equips haurien d'inventariar els clients i servidors MCP, identificar les dependències de les sessions o inicialitzar el comportament i provar amb els SDK 2026-07-28 o els materials de conformitat quan estiguin disponibles. Els sistemes de producció haurien d'escenificar l'actualització, sobretot si els agents realitzen accions amb efectes secundaris, com ara crear sol·licituds d'extracció, modificar problemes, consultar dades dels clients o executar fluxos de treball de desplegament.

La segona prioritat és l'observabilitat. La infraestructura sense estat pot ser més fàcil d'escalar, però els sistemes d'agents distribuïts encara necessiten identificadors de correlació, captura de traça, registres de sol·licituds i esdeveniments de política. Sense aquests, els equips poden canviar la complexitat de la sessió per la complexitat de depuració. Les analítiques d'ús haurien de distingir entre trucades de models i trucades d'eines, especialment quan els fluxos de treball d'agents es facturen, es limiten a tarifes o l'equip audita.

La tercera prioritat és la revisió de l'autorització. Si la nova especificació endureix la semàntica d'autorització, els implementadors no haurien de portar els supòsits d'accés antics a la nova versió. Haurien de tornar a comprovar els àmbits del testimoni, la delegació d'usuaris, els comptes de servei, els registres d'auditoria i el comportament de denegació. L'accés a l'eina hauria de tenir els privilegis mínims de manera predeterminada, especialment per als desplegaments MCP remots.

Val la pena comprovar alguns detalls abans que les organitzacions prenguin decisions de disseny irreversibles. La investigació disponible per a aquest article incloïa el candidat de llançament, la pàgina d'especificacions, els materials de migració de l'SDK i la nota d'implementació de GitHub. La redacció normativa final de l'especificació 2026-07-28 s'ha de revisar directament abans de citar els requisits exactes del protocol en els estàndards interns o la documentació del client.

Fins i tot amb aquesta advertència, la direcció és clara. MCP s'està convertint en un protocol més orientat a la producció per a la infraestructura d'agents. El nucli sense estat hauria de facilitar l'escala dels desplegaments remots, però també obliga l'ecosistema a netejar els supòsits de les implementacions anteriors. Per a la creació d'equips amb agents, aquest és el tipus de canvi de protocol que mereix un bitllet d'esprint, no només un marcador.