Les API fa dècades que permeten que una aplicació consulti dades o executi operacions en una altra. Gràcies a elles, una botiga pot cobrar mitjançant una passarel·la de pagament, un ERP pot sincronitzar comandes amb un CRM i una aplicació mòbil pot consultar la previsió meteorològica.
L'arribada dels agents d'intel·ligència artificial planteja un repte addicional. Ja no sempre hi ha un desenvolupador que programa per endavant cada crida i cada transició: un model pot decidir quina eina necessita, seleccionar una operació, construir-ne els arguments i interpretar-ne el resultat durant una conversa.
Aquí és on entra en joc MCP, sigles de Model Context Protocol. MCP és un estàndard obert per connectar aplicacions d'IA amb sistemes externs, tant si són fitxers locals, bases de dades, serveis remots o fluxos de treball. La seva proposta és crear una interfície comuna entre els agents i les capacitats que poden utilitzar.
La pregunta sembla inevitable: si ja tenim API, per què necessitem MCP? La resposta breu és que no resolen exactament el mateix problema.
Abans de comparar: una API no és un protocol concret
Tot i que acostumem a parlar d'“API” com a sinònim d'una API REST sobre HTTP, una API és, en realitat, una interfície mitjançant la qual un component de programari ofereix dades o funcions a un altre. Es pot implementar amb REST, GraphQL, gRPC, SOAP, una biblioteca local o molts altres estils.
OpenAPI, per exemple, no defineix el comportament de totes les API: proporciona una descripció estàndard i independent del llenguatge per a API HTTP. Aquesta descripció permet que persones i eines coneguin rutes, operacions, paràmetres, respostes i mecanismes de seguretat sense inspeccionar el codi font. Així ho estableix la mateixa especificació OpenAPI.
MCP sí que és un protocol concret. Defineix una arquitectura client-servidor, missatges basats en JSON-RPC 2.0, mecanismes de descobriment i un conjunt de primitives pensades per a aplicacions d'IA. Per això, “MCP vs. API” és una comparació útil per prendre decisions, però no una oposició estricta entre conceptes equivalents.
Una manera senzilla de veure-ho és aquesta:
L'API exposa què pot fer un sistema. MCP tradueix i organitza aquestes capacitats perquè un agent les pugui descobrir i utilitzar d'una manera comuna.
Què aporta una API tradicional?
Una API convencional ofereix un contracte perquè un programa invoqui operacions conegudes. En una API REST, per exemple, el client sap que ha d'enviar una petició GET /customers/123 per recuperar un client o una petició POST /orders/ per crear una comanda.
L'aplicació consumidora es programa al voltant d'aquest contracte. L'equip de desenvolupament decideix quin endpoint ha de cridar, en quin moment, amb quins paràmetres i com ha de processar la resposta. Això ofereix control, previsibilitat i eficiència.
Les API són especialment adequades per a:
- Integracions deterministes entre serveis.
- Aplicacions mòbils i web amb fluxos coneguts.
- Processament massiu o de baixa latència.
- Interfícies públiques per a desenvolupadors i socis.
- Automatitzacions en què cada pas està definit per endavant.
A més, l'ecosistema de les API està molt consolidat. Hi ha eines madures per a documentació, generació de clients, proves, observabilitat, control de versions, quotes i seguretat. OpenAPI pot descriure, entre d'altres, esquemes amb API keys, autenticació HTTP, OAuth 2.0, OpenID Connect o mTLS.
La seva limitació en el context dels agents no és que una API sigui incapaç de servir-los. Un agent pot utilitzar una API directament si la seva plataforma permet registrar funcions o eines. El problema apareix en escalar: cada aplicació d'IA ha d'adaptar el contracte de cada servei, seleccionar quines operacions exposa al model i transformar-ne les respostes en context útil.
Què aporta MCP?
MCP estandarditza la comunicació entre una aplicació d'IA (el host) i un o diversos servidors MCP. El host crea un client per a cada servidor i agrega les capacitats disponibles perquè el model les pugui utilitzar. L'arquitectura oficial de MCP també separa la capa de dades, basada en JSON-RPC 2.0, de la capa de transport.
Un servidor MCP pot exposar tres primitives principals:
- Eines (tools): funcions executables per consultar un servei o dur a terme accions, com ara cercar comandes, crear una incidència o actualitzar una tasca.
- Recursos (resources): fonts d'informació que es poden incorporar al context, com ara un document, un esquema de base de dades o el contingut d'un registre.
- Prompts: plantilles reutilitzables que estructuren una interacció o un flux de treball.
El client pot descobrir aquestes capacitats en temps d'execució. Per exemple, sol·licita la llista d'eines, en rep els noms, les descripcions i els esquemes d'entrada i, posteriorment, n'invoca una mitjançant tools/call. Els esquemes permeten validar arguments i els resultats poden combinar text, contingut estructurat i referències a recursos. L'especificació d'eines de MCP detalla aquest contracte.
MCP admet connexions locals mitjançant entrada i sortida estàndard (stdio) i connexions remotes mitjançant Streamable HTTP. Això permet utilitzar el mateix model conceptual tant per a una eina local que opera sobre fitxers com per a un servei allotjat al núvol.
El seu avantatge principal és la interoperabilitat en la capa de l'agent. Un servidor MCP ben dissenyat es pot connectar a diferents clients compatibles sense crear una integració específica per a cadascun. A l'altra banda, un host pot incorporar servidors diferents sota un patró comú de descobriment i invocació.
MCP vs. API: no se substitueixen, es complementen
En una arquitectura real, el servidor MCP acostuma a funcionar com una capa d'adaptació. Rep una petició estàndard del client d'IA, valida els arguments, aplica permisos i crida l'API interna o pública que ja conté la lògica de negoci.
Per exemple, una plataforma de suport pot mantenir la seva API REST com a interfície canònica:
- L'API ofereix operacions per consultar clients, llegir incidències i publicar respostes.
- El servidor MCP agrupa aquestes operacions en eines comprensibles per a un agent, com ara
cercar_incidenciesorespondre_incidencia. - L'agent descobreix les eines i decideix quina proposa segons la petició de l'usuari.
- El host aplica polítiques i, si l'acció és sensible, sol·licita confirmació.
- El servidor MCP crida l'API amb les credencials i els permisos corresponents.
Aquesta separació és útil perquè la lògica de negoci es manté darrere de l'API, on també pot servir l'aplicació web, l'aplicació mòbil i altres integracions. MCP aporta una façana específica per a clients d'IA sense convertir el model en consumidor directe de tota la superfície tècnica del sistema.
Tampoc no cal exposar cada endpoint com una eina. De fet, acostuma a ser millor dissenyar eines de nivell superior, acotades i orientades a la intenció. En lloc de traslladar vint endpoints de baix nivell, un servidor podria oferir preparar_reemborsament, que consulti la comanda, comprovi les regles i retorni una proposta abans d'executar l'operació definitiva.
Avantatges de les API
- Ofereixen un control precís sobre cada petició i resposta.
- Són una base estable per a múltiples canals i consumidors.
- Encaixen bé en operacions d'alt volum, fluxos deterministes i requisits estrictes de latència.
- Disposen d'un ecosistema madur de gateways, SDK, proves, monitoratge i governança.
Límits de les API per als agents
- Cada client d'IA pot requerir una adaptació diferent.
- Una especificació tècnica no sempre conté les descripcions semàntiques que ajuden el model a escollir correctament una operació.
- Les respostes poden ser massa extenses o poc adequades per a una finestra de context.
- Exposar tota una API augmenta el nombre d'eines i en dificulta la selecció per part del model.
Avantatges de MCP
- Proporciona una interfície comuna per a diferents clients d'IA.
- Permet descobrir capacitats i els seus esquemes dinàmicament.
- Distingeix entre accions, fonts de context i plantilles d'interacció.
- Facilita que una mateixa integració estigui disponible en diversos hosts compatibles.
- Pot encapsular diverses crides a API en eines orientades a tasques.
Límits de MCP
- Introdueix una altra capa que cal desplegar, versionar, observar i protegir.
- La compatibilitat real pot variar segons les funcions de MCP que implementi cada client.
- No elimina la necessitat d'una API o d'una capa d'accés a dades darrere del servidor.
- No converteix una eina mal dissenyada en una eina segura o fàcil d'utilitzar.
- Pot ser innecessari si només hi ha un consumidor i el flux és completament determinista.
La seguretat canvia quan el consumidor pot raonar i actuar
En una integració tradicional, la seqüència de crides està escrita en codi. En un agent, una part de la decisió pot dependre del model i de contingut extern no fiable. Per tant, connectar una eina no equival a autoritzar qualsevol ús d'aquesta eina.
Per als servidors MCP remots, l'especificació preveu l'autorització en el transport HTTP i es basa en estàndards d'OAuth. Tanmateix, l'autorització és opcional en MCP i una implementació l'ha de dissenyar correctament. Quan s'aplica, l'especificació d'autorització exigeix validar que els tokens estiguin destinats al servidor correcte i recomana seleccionar permisos d'acord amb el principi del privilegi mínim.
També hi ha riscos específics: servidors locals amb accés a l'equip, eines amb descripcions no fiables, delegació incorrecta de credencials, SSRF durant el descobriment OAuth o accions destructives proposades pel model. La guia oficial de bones pràctiques de seguretat de MCP tracta amenaces com el confused deputy, el reenviament indegut de tokens, el segrest d'identificadors d'estat i el compromís de servidors locals.
Com a mínim, una implementació hauria de:
- Concedir a cada servidor i eina només els permisos necessaris.
- Separar les operacions de lectura i escriptura.
- Validar entrades, sortides, rutes i URI al servidor.
- Tractar les descripcions, anotacions i respostes externes com a dades no fiables.
- Mostrar quina eina s'executarà i demanar confirmació per a accions sensibles o irreversibles.
- Aplicar límits d'ús, registres d'auditoria, temps d'espera i idempotència quan correspongui.
- Executar els servidors locals en un entorn aïllat i amb accés restringit al sistema.
- Evitar que el servidor MCP accepti o reenviï tokens destinats a altres serveis.
La mateixa especificació d'eines recomana mantenir una persona dins del circuit, amb capacitat per denegar invocacions. MCP estandarditza la connexió, no la confiança.
Quan convé utilitzar una API?
Utilitza una API directament quan:
- El consumidor és una aplicació tradicional i no un agent.
- El flux està definit de principi a fi i no necessita descobriment dinàmic.
- Necessites el màxim control sobre la latència, els reintents, la memòria cau o el volum.
- Estàs publicant una interfície general per a desenvolupadors i diversos tipus de clients.
- Només tens un agent i unes quantes operacions estables que pots registrar com a funcions sense afegir una altra capa.
Una API també hauria de continuar sent la base quan l'organització ja hi concentra la lògica de negoci, els permisos i l'auditoria. No cal duplicar aquesta lògica dins del servidor MCP.
Quan convé utilitzar MCP?
MCP és especialment útil quan:
- Vols que una integració funcioni amb diversos clients o entorns d'agents compatibles.
- L'agent necessita combinar eines i fonts de context de sistemes diferents.
- Les capacitats disponibles canvien i convé descobrir-les en temps d'execució.
- Necessites exposar fitxers, documents o esquemes com a recursos, a més d'executar accions.
- Vols oferir una integració oficial del teu producte per a l'ecosistema d'assistents d'IA.
- Vols encapsular API complexes en tasques de negoci més clares i segures per a un model.
El benefici augmenta amb el nombre de combinacions. Si una empresa ha de connectar diversos agents amb molts serveis, una interfície compartida redueix la feina d'adaptadors punt a punt.
Quan convé utilitzar tots dos?
En la majoria dels productes consolidats, aquesta serà l'opció més raonable:
- API com a nucli: manté la lògica de negoci, les dades, l'autorització i els contractes per a qualsevol consumidor.
- MCP com a capa per a agents: selecciona les capacitats adequades, les descriu amb claredat, en limita l'abast i transforma els resultats en context útil.
Aquest patró permet fer evolucionar l'experiència de l'agent sense trencar les aplicacions que ja consumeixen l'API. També evita que la capa MCP es converteixi en una segona implementació de la lògica empresarial.
Una regla pràctica per decidir
Pots prendre la decisió amb tres preguntes:
- Qui consumirà la interfície? Si és codi determinista, comença per una API. Si són diversos clients d'IA, valora MCP.
- La capacitat ja existeix darrere d'una API? Conserva-la i crea una capa MCP només si aporta interoperabilitat o una semàntica millor per a l'agent.
- El model ha de decidir entre eines o accedir a context heterogeni? Com més gran sigui aquesta necessitat, més valor aportarà MCP.
En resum:
API per exposar capacitats de programari; MCP per presentar capacitats i context als agents. En sistemes reals, el més habitual no serà triar-ne un o l'altre, sinó utilitzar MCP sobre API ben dissenyades.
Conclusió i ús a Gescon
MCP respon a una necessitat que les API tradicionals no tractaven de manera uniforme: connectar models i agents amb eines, recursos i fluxos de treball mitjançant un contracte comú. El seu descobriment dinàmic i les seves primitives redueixen el cost d'integrar un mateix servei en diferents aplicacions d'IA.
Però MCP no substitueix l'arquitectura existent. Les API continuen sent el mecanisme adequat per exposar serveis, centralitzar regles de negoci i atendre integracions deterministes. Un servidor MCP s'hi pot basar i oferir a l'agent una superfície més petita, semàntica i controlada.
Per tant, la decisió no s'hauria de basar en quina tecnologia és més nova. S'hauria de basar en el consumidor i el problema: utilitza una API quan necessitis una interfície general i previsible; utilitza MCP quan necessitis que agents compatibles descobreixin i utilitzin capacitats d'una manera comuna; utilitza tots dos quan vulguis combinar una base madura amb una experiència dissenyada específicament per a la IA.
MCP i API a Gescon
A la nostra plataforma, els agents d'intel·ligència artificial es poden connectar tant a API REST tradicionals com a servidors MCP. A l'apartat d'Integracions disposem d'informació sobre alguns connectors desenvolupats per NurIA Labs a Gescon. En funció del proveïdor, aprofitem la connexió amb el seu servidor MCP, mentre que en altres casos optem per adaptar de manera nativa les integracions dels agents a les API.
Marc Seguí Coll