Què és un servidor MCP i per què canvia les integracions d'IA

Un servidor MCP és un pont estandarditzat entre un model d’IA i una eina de l’empresa. Publica el que aquella eina sap fer en un format que qualsevol agent compatible entén, sense escriure una integració a mida per a cada model.

El Model Context Protocol fa temps que va deixar de ser una novetat. Avui és la manera habitual de connectar agents amb dades i eines, i apareix a les propostes tècniques que reben les empreses que es plantegen contractar un agent. Aquest article explica què és un servidor MCP, quin problema resol de debò i què implica la decisió per a una empresa que vol integrar un agent amb el seu ERP, el seu CRM, el correu i els fitxers interns. Sense promeses, sense futurologia.

Què és un servidor MCP

Un servidor MCP publica les accions que una eina pot executar (llegir un correu, crear un contacte al CRM, buscar un fitxer) i les dades que pot llegir, en un format estandarditzat que qualsevol agent compatible amb el protocol entén. No és un producte que es compri: és una peça de programari petita que es posa davant d’una eina que ja tens.

Tres precisions que eviten la majoria de malentesos:

• MCP és un protocol obert, no una plataforma. Anthropic el va publicar a finals de 2024 i el manté com a especificació oberta. No es contracta MCP, s’implementa.
• El servidor va per eina, no per model. Un servidor per al teu ERP serveix per a Claude, per a GPT i per a Gemini alhora.
• L’API de l’eina segueix existint a sota. MCP és la capa que la fa consumible per un agent de manera genèrica, no un substitut de l’API.

El 2026 això ja no és una aposta: els SDKs dels grans proveïdors de models parlen el protocol, hi ha servidors mantinguts pels mateixos fabricants d’eines i existeixen directoris públics de servidors comunitaris. El nucli de la idea segueix sent el mateix que a la primera especificació: en lloc d’escriure un connector a mida per a cada combinació de model i eina, el servidor exposa una interfície comuna i els models parlen aquest mateix idioma.

El problema que resol

Fins ara, cada vegada que volies que un agent llegís el teu Holded, escrivís al teu HubSpot o consultés un full intern, tocava el mateix: un connector a mida. Si canviaves de model (de GPT a Claude, per exemple), calia reescriure bona part d’aquell connector. Si una eina interna s’actualitzava, el connector deixava de funcionar i ningú ho sabia fins que l’agent fallava.

El resultat, a la pràctica, és que molts projectes d’IA a pimes es quedaven en proves pilot. El cost de mantenir vint connectors a mida contra cinc models diferents era prohibitiu, i ningú volia lligar-se a un únic proveïdor d’IA per por de la dependència tècnica.

MCP canvia aquesta equació. Construeixes un servidor MCP per al teu Holded una sola vegada. Funciona amb Claude. Funciona amb GPT. Funciona amb Gemini. Funciona amb el següent model que surti l’any que ve. La teva integració no caduca cada sis mesos al ritme del màrqueting de les grans plataformes d’IA.

Com funciona, sense entrar en arquitectura

Tres peces:

1. Servidor MCP. Un procés petit (sol ser un servei Node, Python o Go) que sap parlar amb la teva eina concreta: el teu CRM, la teva base de dades, el teu sistema de tiquets. Exposa “tools” (accions que l’agent pot executar) i “resources” (dades que l’agent pot llegir).
2. Client MCP. L’entorn on viu l’agent: Claude Desktop, Cursor, una aplicació interna construïda sobre el SDK d’Anthropic o d’OpenAI. El client sap com descobrir els servidors MCP disponibles i com invocar les seves tools.
3. Model. El model d’IA en si (Claude, GPT, Gemini, open-weights). El client li passa el llistat de tools disponibles, el model decideix quina invocar segons la conversa o el procés, i el servidor executa l’acció contra l’eina real.

La peça clau és que els tres components són intercanviables. Canvies el model, els servidors MCP segueixen funcionant. Canvies el client, els servidors segueixen funcionant. Canvies el servidor d’un proveïdor (per exemple, migres de Holded a Sage), reescrius només aquell servidor, tota la resta segueix igual.

Un exemple concret

Imagina una pime amb Holded com a ERP, HubSpot com a CRM i un Drive intern amb plantilles de proposta. Vols un agent que, quan un client envia un correu demanant un pressupost, busqui les seves dades a HubSpot, recuperi l’última conversa, miri els productes disponibles a Holded i prepari un esborrany de proposta utilitzant la plantilla del Drive.

Sense MCP, això requereix quatre integracions a mida (correu, HubSpot, Holded, Drive), cadascuna lligada al model concret que faci servir l’agent. Si canvies de model en sis mesos, cal reescriure les quatre.

Amb MCP, muntes:

• Un servidor MCP per a Holded (o fas servir un de comunitari si existeix).
• Un servidor MCP per a HubSpot.
• Un servidor MCP per al Drive.
• Un servidor MCP per al teu sistema de correu.

I connectes l’agent al client MCP de la teva elecció. Qualsevol model compatible pot executar el procés complet. El dia que el model de torn millori prou, el canvies i els servidors segueixen funcionant.

Per què podria substituir els sistemes actuals d’integració

MCP està desplaçant tres famílies d’integració que fins fa poc eren la norma:

• Plugins propietaris. Les primeres versions de plugins de ChatGPT i similars lligaven cada integració a una plataforma concreta. MCP elimina aquest acoblament: la mateixa integració serveix per a qualsevol client compatible.
• Connectors en eines d’automatització. Plataformes com Zapier o Make ofereixen milers de connectors, però cadascun requereix ser mantingut per la mateixa plataforma. Amb MCP, un servidor el pot mantenir el proveïdor de l’eina original, la comunitat o el mateix client.
• Wrappers de SDK específics. Avui, integrar OpenAI Function Calling amb les teves eines internes implica escriure wrappers lligats al seu SDK. MCP estandarditza la interfície: el wrapper deixa de ser part de l’agent i passa a ser part de l’eina.

El desplaçament no és total ni ho serà a curt termini. Les plataformes establertes tenen incentius comercials per mantenir els seus connectors propis, i molts equips segueixen amb integracions a mida senzillament perquè ja les tenen escrites i funcionen. Però el patró històric es repeteix: quan apareix un protocol obert que resol un problema real (HTTP, SMTP, OAuth en el seu dia), les opcions propietàries acaben convergint. MCP ja ocupa aquest lloc per a la IA connectada.

El que MCP no resol

Convé posar l’optimisme al seu lloc. MCP no és:

• Una recepta per fer agents fiables. El protocol estandarditza com el model parla amb les eines. La fiabilitat de l’agent depèn del prompt, del model, de la qualitat de les dades i, sobretot, del procés acotat que se li demana executar. Un servidor MCP perfecte no salva un agent mal definit.
• Una garantia de seguretat. El servidor exposa tools al model. Si aquestes tools inclouen “esborrar registres del CRM” sense confirmació humana, l’agent pot executar-les. La capa de permisos, kill-switch i validació humana segueix sent responsabilitat de l’implementador.
• Una substitució de la lògica de negoci. El servidor MCP és un pont. Les regles de quins clients són prioritaris, quins productes estan actius, quins casos requereixen escalada segueixen vivint al codi del servidor o a l’eina original.
• Una drecera per evitar la fase de discovery. Tot i que la integració tècnica sigui més ràpida, la feina prèvia de definir el procés, la mètrica d’èxit, el kill-switch i el fallback humà segueix sent igual.

Què mirar abans de connectar un agent a un servidor MCP

Les guies sobre MCP estan escrites per a qui tria un servidor. La pregunta que es fa una empresa és una altra: què implica donar accés. Quatre comprovacions abans de connectar res a dades reals.

1. Quines tools són de lectura i quines escriuen. Un servidor que només llegeix factures i un que les pot emetre són la mateixa mena de peça amb conseqüències molt diferents. Demana la llista de tools separada en dues columnes abans d’aprovar la connexió. Si el proveïdor no la té escrita, la conversa encara no està madura.

2. Qui manté el servidor. Un servidor publicat pel fabricant de l’eina, un de la comunitat i un de construït a mida tenen cicles de manteniment molt diferents. El de la comunitat es pot quedar sense actualitzar el dia que l’API canviï, i l’agent falla sense avisar.

3. On viu la confirmació humana. El protocol no decideix quines accions necessiten que algú digui que sí. Aquesta regla la posa qui implementa. Abans de producció ha d’estar escrit quines operacions un agent pot executar sol i quines paren a esperar una persona.

4. Què passa el dia que l’apagues. Si desconnectes el servidor, el procés ha de seguir funcionant a mà. El kill-switch i el fallback humà no són opcionals pel fet que la integració sigui estàndard.

A l’operativa interna de serpixel els agents es connecten a Holded i a Notion a través de servidors MCP, i aquestes quatre preguntes són les mateixes que apliquem abans de donar accés a una eina d’un client. És un ordre de treball, no una garantia: el que decideix el resultat segueix sent el procés acotat que hi ha al darrere.

Què canvia per a una pime

Tres coses concretes.

1. Cost d’integració a la baixa. Els connectors ja escrits (els publica la comunitat o el mateix fabricant de l’eina) redueixen la feina a mida. Això baixa el sòl a partir del qual un agent té sentit econòmic, especialment per a processos de volum mitjà.

2. Menys dependència del proveïdor d’IA. Una pime que inverteix en una arquitectura MCP no es lliga a Claude, a GPT o a Gemini en concret. Pot canviar de model segons fiabilitat o cost sense reescriure la integració. La capa mecànica del procés (servidor MCP) sobreviu als canvis de model.

3. Possibilitat de combinar tools de fonts diferents. Un mateix agent pot consultar un servidor MCP de Holded, un altre d’un sistema intern propi i un altre d’una API pública, sense cost addicional d’integració. Això obre processos que abans eren prohibitius per la complexitat de combinar diverses eines.

El que no canvia és la part humana: definir el procés, validar el que l’agent fa, revisar la mètrica d’èxit, mantenir el kill-switch operatiu. MCP allibera la capa mecànica de les integracions, no substitueix l’equip que decideix què automatitzar i com. La capa on aporta valor l’equip (criteri, decisions ambigües, relació amb el client) segueix intacta.

Com ho apliquem a serpixel

serpixel (Clever European Business, S.L.) és una agència d’implementació a mida per a empreses amb operativa diària real: comandes, reserves, factures, parts d’hores. Treballa en quatre línies de servei: agents d’IA, automatitzacions i integracions, software a mida i webs. Els agents s’integren amb les eines que el client ja fa servir (ERP, CRM, correu, WhatsApp Business). La proposta és model-agnòstica (Claude, GPT, Gemini), el codi i les dades es queden amb el client, i cada implementació inclou kill-switch, fallback humà i un harness d’avaluació.

A la pràctica, això significa que els agents que construïm segueixen la mateixa separació que MCP estandarditza: la capa d’integració (cada eina, al seu propi mòdul) va per un costat i la capa d’orquestració (què fa l’agent amb aquestes tools) va per l’altre. Quan una eina del client ja té un servidor MCP mantingut pel fabricant o per la comunitat, l’agent s’hi connecta en lloc d’arrossegar un connector propi. Quan no en té, el connector es construeix una sola vegada i es reutilitza al següent projecte que faci servir la mateixa eina.

L’avantatge per al client, en qualsevol cas, és el mateix: la inversió en l’agent no caduca cada vegada que surt un model nou. La capa mecànica del procés sobreviu, l’equip humà segueix ocupant-se del que només les persones fan bé i el cost de manteniment es manté previsible. serpixel acompanya aquesta decisió tècnica des de l’inici del projecte, abans d’escriure una sola línia de codi.

Què fer ara

Si tens un procés acotat al cap i et preguntes si MCP canvia la conversa, la resposta curta és que ja l’ha canviada: connectar un agent a les teves eines costa menys que fa dos anys i et lliga menys a un proveïdor. Però la conversa útil no és quin protocol faràs servir, és quin procés concret tens i quines eines toca.

Una sessió de descoberta de 30 minuts basta per resoldre tres preguntes: si el procés encaixa amb un agent, quines eines caldria integrar i quina mètrica d’èxit té sentit mesurar abans de pressupostar res. Si vols tenir aquesta conversa, reservem 30 minuts a Calendly. Sense compromís de contractació, sense pressió comercial, només l’espai que cal per entendre si el projecte té sentit i, si en té, per quin camí començar.