MCP · AGENTES DE IA · INTEGRACIONES · ARQUITECTURA
MCP en empresas: cuándo aporta valor y cuándo una API o integración tradicional es suficiente
MCP se ha convertido en una de las siglas más repetidas al hablar de agentes de IA. Eso no significa que una empresa necesite añadirlo a cada proyecto. La pregunta útil no es si MCP es moderno, sino qué complejidad elimina, cuál introduce y si mejora de verdad la forma de conectar la IA con los sistemas del negocio.
MCP no sustituye a las APIs: estandariza cómo una aplicación de IA accede a capacidades externas.
Si una empresa tiene una integración estable, pocas operaciones y un flujo conocido, una API directa o un workflow pueden ser la opción más sencilla. MCP empieza a tener más sentido cuando varias aplicaciones de IA necesitan reutilizar capacidades, cuando conviene disponer de un catálogo común de herramientas o cuando reducir la dependencia de una única aplicación compensa el coste de operar una capa adicional.
El problema no es conectar una IA a una API. Es repetir la misma integración una y otra vez
Imaginemos una empresa que empieza con un asistente interno. Necesita consultar clientes en el CRM, revisar pedidos en el ERP y localizar documentos en un repositorio. El equipo define tres funciones, conecta tres APIs y controla qué puede hacer cada una. La arquitectura puede ser perfectamente válida.
Meses después aparece otro agente para operaciones. Luego un asistente comercial. Después, una herramienta de soporte que también necesita consultar clientes, pedidos y documentos. Si cada aplicación vuelve a definir sus propias funciones, sus esquemas, sus credenciales y su forma de acceder a los mismos sistemas, el problema ya no es conectar una API: es mantener muchas versiones de la misma capacidad.
Ahí aparece una de las razones por las que MCP puede resultar interesante. En lugar de enseñar a cada aplicación de IA cómo hablar de forma específica con cada sistema, una empresa puede exponer determinadas capacidades mediante una interfaz común. La aplicación compatible consulta qué herramientas están disponibles, conoce qué parámetros requieren y puede utilizarlas dentro de las políticas definidas.
Eso no convierte MCP en una solución universal. Si solo existe un consumidor y dos operaciones que no van a reutilizarse, crear un servidor adicional, operarlo, protegerlo y monitorizarlo puede ser más trabajo que mantener dos integraciones directas.
Una misma necesidad, dos arquitecturas razonables
Escenario A: un workflow recibe un pedido ya validado y debe crearlo en un ERP concreto. El proceso es fijo, la API es conocida y ningún otro agente necesita esa operación. Una integración directa puede ser suficiente.
Escenario B: cinco asistentes internos necesitan consultar pedidos, clientes, stock y documentos, y la empresa quiere evitar que cada equipo replique contratos y credenciales. Una capa común basada en MCP puede empezar a reducir repetición.
Qué es MCP, solo hasta donde hace falta para decidir
MCP son las siglas de Model Context Protocol. Es un protocolo abierto diseñado para que aplicaciones que utilizan modelos de lenguaje puedan conectarse de una forma común con datos y capacidades externas.
La arquitectura se organiza, de forma simplificada, en tres piezas: una aplicación de IA que actúa como host, uno o varios clientes MCP gestionados por esa aplicación y uno o varios servidores MCP que exponen capacidades. Detrás del servidor puede seguir habiendo una API de CRM, una base de datos, un servicio interno, un repositorio documental o código propio.
A nivel técnico, MCP estructura esa comunicación mediante mensajes JSON-RPC 2.0. La especificación actual contempla conexiones locales mediante stdio y conexiones remotas mediante Streamable HTTP, que puede utilizar Server-Sent Events (SSE) cuando necesita mantener un flujo de mensajes. Para una empresa, lo importante es entender que MCP define una forma común de comunicación sin sustituir los sistemas que hay detrás.
La especificación permite que los servidores ofrezcan, entre otras cosas, herramientas y recursos. Una herramienta representa una operación que el modelo puede solicitar, por ejemplo consultar un pedido o crear un borrador. Un recurso representa información que la aplicación puede incorporar como contexto, por ejemplo un archivo, un esquema o información de una aplicación.
El cliente puede consultar qué herramientas ofrece el servidor y conocer su estructura, evitando que cada aplicación tenga que definirlas todas de forma independiente.
Comparar MCP con un conector universal ayuda, pero se queda corto. Un conector común no garantiza que dos sistemas compartan reglas, permisos, datos o significado. MCP normaliza una parte de la conversación técnica; no normaliza el negocio entero.
API, conector, workflow y MCP no son alternativas del mismo nivel
La confusión aparece cuando se comparan como si hicieran lo mismo. No es así: pueden coexistir en una misma arquitectura.
| Elemento | Qué resuelve principalmente | Ejemplo empresarial | Qué no resuelve por sí solo |
|---|---|---|---|
| API | Define cómo un software puede consultar o modificar otro software. | Consultar un cliente, crear un pedido, leer inventario. | No decide qué agente debe utilizarla ni en qué momento. |
| Conector | Prepara una integración reutilizable con un servicio o proveedor. | Conectar una plataforma de automatización con Google Drive o un CRM. | No implica necesariamente MCP ni elimina las reglas del proceso. |
| Workflow | Orquesta pasos, condiciones, esperas, errores y estados. | Pedido validado → alta en ERP → comprobación → aviso. | No necesita MCP para existir y puede seguir siendo determinista. |
| MCP | Define una forma común de exponer y utilizar capacidades para aplicaciones de IA. | Varios agentes consultan el mismo catálogo de herramientas empresariales. | No sustituye las APIs, la lógica de negocio ni la gestión del proceso. |
Por eso una frase como “vamos a sustituir nuestras APIs por MCP” suele describir mal la arquitectura. En muchos casos, el servidor MCP utilizará precisamente esas APIs para ejecutar las operaciones.
También puede ocurrir lo contrario: un workflow determinista llama a una API directamente para una operación crítica y, en otro punto del mismo sistema, un agente utiliza MCP para consultar varias herramientas de soporte. No es necesario elegir una sola técnica para todo el proyecto.
Esta distinción enlaza con otra decisión previa: un workflow puede utilizar IA sin convertirse en un agente. MCP tampoco convierte automáticamente una solución en agente. Es una forma de acceso a capacidades, no una definición de autonomía.
Qué relación tiene MCP con function calling y tool calling
El function calling o tool calling permite que un modelo solicite a la aplicación el uso de una función o herramienta y aporte los parámetros necesarios. MCP resuelve otra parte del problema: ofrece una forma común para que la aplicación conozca y utilice herramientas expuestas por servidores MCP.
Una arquitectura puede combinar ambos mecanismos. El modelo puede decidir que necesita consultar un pedido mediante tool calling; la aplicación puede disponer de esa capacidad a través de MCP. También puede existir function calling sin MCP. MCP no estandariza cómo razona el modelo ni sustituye el mecanismo de llamada a herramientas del proveedor: estandariza la interfaz con las capacidades externas.
MCP o integración directa: cinco preguntas antes de decidir
Conviene evaluar MCP por el problema que elimina, no por el interés que genera. Estas cinco preguntas ayudan a decidir.
¿Cuántas aplicaciones de IA necesitan reutilizar las mismas capacidades?
Si solo existe una aplicación y unas pocas operaciones, una integración directa puede ser más sencilla. Si varios asistentes, agentes o productos necesitan consultar los mismos sistemas, una interfaz común gana valor.
¿Las herramientas son pocas y conocidas o deben poder cambiar con frecuencia?
Cuando la aplicación conoce desde el principio todas las funciones que necesita, codificarlas directamente no tiene nada de incorrecto. Si el catálogo crece, cambia o debe consultarse de forma más flexible, MCP reduce parte del acoplamiento.
¿Tiene sentido gobernar un catálogo común de capacidades?
En una organización grande puede ser útil definir de forma central qué herramientas existen, qué hacen, quién las mantiene y qué aplicaciones pueden utilizarlas. En una pyme con tres automatizaciones, crear ese catálogo puede ser innecesario.
¿La portabilidad entre aplicaciones o proveedores tiene un valor real?
Si la empresa quiere que una misma capacidad pueda utilizarse desde distintos entornos compatibles, un protocolo común puede reducir trabajo. Eso no significa portabilidad perfecta: cada aplicación puede aplicar políticas, aprobaciones o compatibilidades diferentes.
¿El coste de operar MCP es menor que el coste de mantener integraciones específicas?
Un servidor MCP también necesita autenticación, despliegue, logs, pruebas, mantenimiento y gestión de cambios. El ahorro solo existe si la reutilización y la estandarización compensan esa nueva responsabilidad.
Cuándo una API directa sigue siendo la mejor decisión
Hay una tendencia comprensible a pensar que una tecnología más reciente debe reemplazar a la anterior. En integración empresarial, esa lógica suele producir sistemas innecesariamente complicados.
Una API directa puede seguir siendo la mejor opción cuando la operación está bien delimitada, el consumidor es conocido y el comportamiento esperado debe estar muy controlado.
Un único consumidor
Una aplicación necesita dos o tres operaciones y no existe previsión razonable de reutilización por otros agentes.
Flujo estable
Los pasos, parámetros y respuestas cambian poco y el proceso está definido de antemano.
Operación crítica
Crear un pedido, emitir un documento o actualizar un estado requiere un recorrido determinista y verificaciones concretas.
Adaptación muy específica
La lógica solo tiene sentido para ese proyecto y convertirla en una herramienta reutilizable no aporta valor.
Pensemos en una automatización que recibe un pedido validado, comprueba el cliente, crea el pedido en el ERP y verifica el identificador devuelto. Si nadie más necesita esa capacidad, envolverla en un servidor MCP puede añadir despliegue y monitorización sin eliminar una complejidad relevante.
Además, una integración directa permite que el equipo vea con claridad qué endpoint se llama, con qué parámetros, cuándo se reintenta y qué ocurre si el resultado es incierto. Esa precisión es especialmente útil en procesos donde un duplicado o una escritura incorrecta tiene consecuencias económicas.
La entrada sobre integración entre CRM y ERP desarrolla precisamente problemas como sincronización, duplicados, reintentos y comprobación de coherencia. MCP puede ser una puerta de acceso a una operación, pero no elimina esas obligaciones.
Cuándo MCP empieza a aportar valor real en una empresa
El valor de MCP crece cuando la organización deja de tener una integración aislada y empieza a tener un conjunto reutilizable de capacidades para varias aplicaciones de IA.
1. Varias aplicaciones necesitan las mismas herramientas
Un agente de soporte, otro de operaciones y un asistente comercial pueden necesitar consultar clientes, pedidos o contratos. Si cada uno mantiene su propia versión de esas funciones, aparecen diferencias, credenciales duplicadas y cambios que deben replicarse. Un servidor común puede reducir esa repetición.
2. El catálogo de capacidades cambia
MCP permite que un cliente consulte las herramientas que expone un servidor y sus esquemas. Esto puede ser útil cuando el conjunto de operaciones evoluciona y no queremos codificar cada cambio de forma independiente en todas las aplicaciones consumidoras.
3. La empresa quiere separar la aplicación de IA de la lógica de integración
El servidor puede encapsular transformaciones, validaciones y llamadas a servicios empresariales. Bien diseñado, esto evita que cada interfaz de IA conozca detalles internos del CRM, ERP o sistema documental.
4. Existe valor en reutilizar capacidades entre distintos entornos
Si la organización utiliza varias aplicaciones compatibles con MCP, una interfaz común puede reducir dependencia de una implementación concreta. Conviene expresarlo con prudencia: la compatibilidad del protocolo no significa que todos los entornos ofrezcan idéntica experiencia, permisos, aprobaciones o soporte de cada función.
5. Tiene sentido gestionar un catálogo empresarial
En organizaciones con muchas herramientas, puede ser útil responder con claridad a preguntas como: ¿qué operaciones puede usar la IA?, ¿quién mantiene cada una?, ¿cuáles solo consultan y cuáles modifican datos?, ¿qué sistemas hay detrás?, ¿qué versión está activa? MCP no crea automáticamente ese gobierno, pero ofrece una base común sobre la que organizarlo.
Dónde puede ayudar la IA y por qué MCP importa especialmente cuando el modelo usa herramientas
El valor está en conseguir que la IA pueda interpretar una petición, elegir una capacidad adecuada, utilizarla con el contexto necesario y devolver un resultado útil sin saltarse las reglas del proceso.
Una automatización tradicional suele saber de antemano qué paso viene después. Un agente puede recibir una petición más abierta: “Comprueba si este cliente tiene algún pedido retrasado y prepara un resumen para el comercial”. Para resolverla puede necesitar localizar al cliente, consultar pedidos, interpretar estados y redactar una síntesis.
En ese escenario, MCP puede facilitar que la aplicación de IA acceda a un conjunto de herramientas descritas de una forma común. La IA puede utilizar esa descripción para decidir qué herramienta necesita dentro de las capacidades permitidas.
La IA aporta especialmente en:
- Interpretar lenguaje natural y convertir una intención del usuario en una acción estructurada.
- Elegir entre varias herramientas disponibles cuando la petición no indica explícitamente cuál usar.
- Combinar resultados de distintas fuentes para preparar una respuesta o propuesta.
- Resumir información recuperada de CRM, ERP, documentos o sistemas internos.
- Detectar que falta información y pedir una aclaración antes de continuar.
- Preparar borradores o recomendaciones a partir de datos ya verificados.
- Gestionar situaciones ambiguas en las que un workflow rígido necesitaría muchas ramas.
Pero la IA no debería inventar permisos, datos ni estados. Que el modelo decida qué herramienta solicitar no significa que pueda saltarse una validación, crear una operación no autorizada o asumir que una escritura ha tenido éxito.
Por eso el diseño de agentes debe separar elección, ejecución y verificación. La evaluación de agentes antes de ampliar su autonomía sigue siendo necesaria aunque las herramientas se expongan mediante MCP.
Que una herramienta esté disponible no significa que el agente tenga permiso para utilizarla
Esta distinción es esencial para evitar una de las malas interpretaciones más peligrosas de MCP.
Un servidor puede informar de que dispone de una herramienta llamada, por ejemplo, actualizar_cliente. Eso permite que la aplicación conozca su existencia y estructura. No significa que cualquier usuario de la aplicación tenga derecho a ejecutarla ni que deba poder modificar cualquier cliente.
La autorización sigue requiriendo una arquitectura explícita: identidad del usuario, credenciales, ámbitos de acceso, políticas internas, aprobación cuando proceda y controles en el sistema final. La especificación de MCP incluye mecanismos de autorización para conexiones remotas y hace especial hincapié en validar tokens, separar destinatarios y evitar reutilizar credenciales de forma insegura.
Además, la documentación de seguridad del propio protocolo advierte de riesgos como el uso incorrecto de tokens, accesos excesivos o servidores con permisos demasiado amplios. MCP estandariza una interfaz; no convierte una mala política de seguridad en una buena política.
| Pregunta | Ejemplo | Quién debe responderla |
|---|---|---|
| ¿La herramienta existe? | Consultar pedidos. | Servidor MCP. |
| ¿Esta aplicación puede verla? | El agente de soporte sí; otro entorno no. | Configuración y políticas de la aplicación. |
| ¿Este usuario puede ejecutarla? | Puede consultar, pero no modificar pedidos. | Autorización y sistema empresarial. |
| ¿Necesita aprobación? | Crear un reembolso exige confirmación. | Política de riesgo del proceso. |
| ¿La operación terminó correctamente? | El ERP devuelve un identificador válido. | Integración y verificación del sistema final. |
La entrada sobre permisos y credenciales en automatizaciones con IA desarrolla este problema con más profundidad. Aquí basta con fijar una frontera: MCP no debe utilizarse como excusa para conceder a un agente acceso amplio “por si lo necesita”.
Lo que MCP no resuelve aunque la integración funcione
Una arquitectura puede cumplir el protocolo perfectamente y seguir teniendo problemas graves de negocio. Conviene dejar claras las responsabilidades que permanecen fuera de MCP.
Quién manda sobre cada dato
Si CRM y ERP muestran valores diferentes, MCP no decide cuál debe prevalecer. Eso pertenece al diseño de datos y del proceso.
Duplicados e idempotencia
Si una operación se reintenta después de una respuesta incierta, el sistema debe evitar efectos duplicados. El protocolo no lo garantiza por sí solo.
Consistencia entre sistemas
Una actualización correcta en una herramienta no asegura que otro sistema haya quedado sincronizado.
Calidad de la API inferior
Si la API no permite una operación, devuelve datos incompletos o tiene límites, envolverla en MCP no elimina esas restricciones.
Lógica de negocio
“Puede crear un pedido” no explica cuándo debe crearse, qué validaciones necesita ni quién lo aprueba.
Verificación del resultado
Una llamada enviada no equivale a una operación completada. La aplicación debe comprobar el resultado cuando el riesgo lo exige.
Lo mismo ocurre con el conocimiento documental. Un servidor MCP puede exponer herramientas de búsqueda o recursos, pero MCP no es una estrategia RAG. La decisión sobre cuándo consultar documentación, cuándo llamar una API y cómo evaluar la evidencia pertenece a otro nivel de arquitectura. Para ese problema, la referencia es RAG en empresas frente a reglas, APIs o workflows.
La arquitectura híbrida suele ser más realista que elegir MCP para todo
En producción, muchas empresas no necesitarán decidir entre “todo MCP” o “nada MCP”. Es más razonable utilizar cada mecanismo donde aporta más control.
Un agente puede utilizar MCP para consultar varias capacidades y comprender qué herramienta necesita. Cuando llega el momento de ejecutar una operación crítica, puede delegar en un workflow determinista que valida condiciones, solicita aprobación, llama a la API y comprueba el resultado.
Ejemplo: agente de compras interno
Un usuario pregunta: “¿Qué pedidos de este proveedor están retrasados y cuál conviene revisar primero?”. El agente puede consultar proveedores, pedidos y recepción mediante herramientas expuestas de forma común.
Si después el usuario pide “reclama al proveedor y cambia la fecha prevista”, el sistema no tiene por qué dejar toda la operación a una decisión libre del agente. Puede preparar un borrador, pedir aprobación y activar un workflow que actualice únicamente los campos permitidos y verifique la escritura.
Esta separación encaja con el criterio de mínima autonomía suficiente: conceder a la IA solo el grado de libertad que el proceso puede justificar, controlar y medir. La arquitectura no tiene que demostrar que el agente puede hacerlo todo; debe demostrar que el sistema completo funciona de forma fiable.
También evita duplicar debates ya resueltos en la entrada SaaS, integración o automatización a medida. MCP es una decisión dentro de la capa de integración con IA, no una sustitución automática de todas las demás decisiones tecnológicas.
Adoptar MCP también significa operar MCP
Una prueba puede parecer sencilla: levantar un servidor, exponer unas herramientas y conectarlo a una aplicación compatible. La pregunta empresarial empieza después: ¿quién mantiene esa capa cuando las APIs, permisos y herramientas cambian?
En producción conviene contemplar, como mínimo:
- Inventario de servidores y herramientas activas.
- Propietario técnico y propietario de negocio de cada capacidad.
- Versionado de contratos y cambios compatibles.
- Autenticación y autorización de conexiones remotas.
- Registro de llamadas, errores, tiempos y resultados.
- Políticas para herramientas de lectura frente a herramientas que modifican datos.
- Pruebas antes de publicar una nueva versión de una herramienta.
- Gestión de dependencias con APIs y servicios inferiores.
- Alertas cuando una herramienta falla o cambia su comportamiento.
- Proceso de retirada para capacidades antiguas.
La especificación incluye utilidades relacionadas con registro, progreso, cancelación y errores, pero que el protocolo contemple esos mecanismos no significa que la empresa tenga automáticamente una observabilidad suficiente. Hay que decidir qué se registra, dónde se consulta y qué incidentes generan una alerta.
También es necesario considerar el tratamiento de datos. Cuando una aplicación utiliza un servidor MCP remoto, la información enviada puede salir hacia un tercero o servicio distinto. En arquitecturas empresariales, eso exige revisar quién opera el servidor, qué datos recibe, qué retención aplica y qué controles contractuales o de seguridad corresponden.
En otras palabras: MCP reduce un tipo de fricción si la empresa está dispuesta a asumir una nueva responsabilidad operativa. Si esa responsabilidad no tiene propietario, el supuesto estándar común puede terminar convirtiéndose en otra capa difícil de mantener.
Cómo tomar la decisión sin convertir MCP en una discusión de moda
La decisión puede resumirse en una secuencia más sencilla que comparar listas de funcionalidades.
Empieza por la capacidad, no por el protocolo
Define qué necesita hacer la aplicación de IA: consultar clientes, obtener inventario, crear borradores, buscar documentos, modificar un registro o activar un proceso. Después identifica qué sistema puede proporcionar esa capacidad y bajo qué condiciones.
Comprueba cuánta reutilización existe de verdad
No diseñes para cinco agentes hipotéticos si hoy solo existe uno y no hay una razón empresarial para crear más. La portabilidad futura tiene valor cuando existe una probabilidad razonable de utilizarla.
Separa consulta de modificación
Exponer una consulta de inventario no tiene el mismo riesgo que crear un pedido, emitir un reembolso o cambiar datos maestros. Una arquitectura puede utilizar MCP para ambas, pero los controles no deberían ser iguales.
Calcula el coste total, no solo el desarrollo inicial
Compara cuántas integraciones específicas dejarán de mantenerse frente al coste de desplegar y gobernar servidores MCP. Incluye autenticación, monitorización, pruebas, soporte y cambios en APIs inferiores.
Prueba el caso con una capacidad real
Un piloto útil no debería medir solo si “el agente consigue llamar a la herramienta”. Debe comprobar si la arquitectura simplifica de verdad el mantenimiento, conserva permisos, permite reconstruir lo ocurrido y responde correctamente ante errores y cambios.
Preguntas frecuentes sobre MCP en empresas
¿MCP sustituye a las APIs?
No. En muchos casos, un servidor MCP utiliza APIs para acceder a CRM, ERP, bases de datos u otros servicios. MCP estandariza la forma en que una aplicación de IA conoce y utiliza capacidades externas; la API sigue resolviendo cómo se comunica el software con el sistema inferior.
¿Cuándo merece la pena utilizar MCP en una empresa?
Empieza a tener más sentido cuando varias aplicaciones de IA necesitan reutilizar las mismas capacidades, cuando existe un catálogo de herramientas que cambia o cuando reducir el acoplamiento con una única aplicación compensa el coste de mantener servidores MCP.
¿Una pequeña empresa necesita MCP para crear un agente?
No necesariamente. Un agente puede utilizar funciones propias o APIs directas. Si el proyecto tiene pocas operaciones estables y un único consumidor, una integración más sencilla puede ser suficiente.
¿MCP hace que un agente sea más autónomo?
No por sí solo. MCP puede facilitar acceso a herramientas y contexto, pero la autonomía depende de cómo se diseñe la aplicación: qué decisiones puede tomar, qué herramientas tiene disponibles, qué aprobaciones necesita y cómo se verifican los resultados.
¿Que una herramienta aparezca en un servidor MCP significa que cualquier usuario puede ejecutarla?
No. Conocer la existencia de una herramienta y estar autorizado a utilizarla son cuestiones distintas. La aplicación y los sistemas empresariales deben aplicar identidad, permisos, ámbitos de acceso y aprobaciones cuando sean necesarios.
¿MCP sirve para sustituir un workflow?
No. Un workflow puede seguir orquestando pasos deterministas, esperas, reintentos, estados y verificaciones. Ese workflow puede llamar APIs directamente o utilizar alguna capacidad expuesta mediante MCP.
¿MCP evita depender de un proveedor de IA?
Puede reducir parte del acoplamiento si varias aplicaciones compatibles reutilizan el mismo servidor, pero no garantiza portabilidad perfecta. Cada host puede tener políticas, aprobaciones, interfaces y niveles de compatibilidad diferentes.
¿Qué debería probar una empresa antes de llevar MCP a producción?
No solo que las herramientas respondan. También permisos, errores, cambios de versión, registros de actividad, operaciones repetidas, resultados inciertos, comportamiento ante caídas del sistema inferior y capacidad de reconstruir qué ocurrió en una ejecución.
DECISIÓN DE ARQUITECTURA
¿MCP simplifica tu arquitectura o solo añade otra capa?
En Yarvia analizamos el proceso, las aplicaciones de IA, las integraciones existentes, los permisos y las operaciones que realmente deben reutilizarse. El objetivo no es implantar MCP porque esté de actualidad, sino decidir si reduce complejidad y mejora la capacidad de automatizar con IA de forma controlada.
Valorar la arquitectura de tu proyectoFuentes
- Model Context Protocol — Specification 2025-11-25.
Especificación estable utilizada para arquitectura, capacidades y principios de seguridad.
Consultar fuente - Model Context Protocol — Tools.
Documentación oficial sobre listado e invocación de herramientas expuestas por servidores MCP.
Consultar fuente - Model Context Protocol — Resources.
Documentación oficial sobre recursos y contexto expuesto a aplicaciones cliente.
Consultar fuente - Model Context Protocol — Authorization.
Marco oficial de autorización para conexiones HTTP y requisitos de validación de acceso.
Consultar fuente - Model Context Protocol — Security Best Practices.
Riesgos y controles recomendados para servidores, credenciales, tokens y límites de acceso.
Consultar fuente - OpenAI API — herramientas y Remote MCP.
Documentación oficial que distingue funciones propias, herramientas integradas y servidores MCP remotos dentro de una misma API.
Consultar fuente - Anthropic — Model Context Protocol.
Documentación oficial de MCP en productos y APIs de Anthropic, utilizada como referencia adicional de adopción del protocolo.
Consultar fuente
MCP evoluciona con rapidez. Antes de actualizar este artículo conviene comprobar la versión estable de la especificación y la documentación vigente de los proveedores citados.
