flowchart LR
A1[App A] --> T1[DMS]
A1 --> T2[Correo]
A1 --> T3[CRM]
A2[App B] --> T1
A2 --> T2
A2 --> T3
A3[App C] --> T1
A3 --> T2
A3 --> T3
MCP
Por qué aparece Model Context Protocol, cómo se organiza mediante host, cliente y servidor, qué son tools, resources y prompts, y por qué MCP no debe confundirse con un agente.
Con una API podemos comunicar sistemas.
Con un connector podemos reducir el trabajo necesario para integrar una aplicación concreta con un servicio concreto.
Pero imaginemos que la arquitectura sigue creciendo.
Tenemos varias aplicaciones basadas en modelos:
asistente jurídico
revisor contractual
herramienta de investigación
sistema de complianceY muchas fuentes o sistemas externos:
DMS
correo
calendario
CRM
procurement
bases de datos
repositoriosSi cada aplicación necesita una integración distinta con cada herramienta o fuente, el número de conexiones aumenta rápidamente.
Aquí aparece el problema que MCP intenta abordar.
Idea central
MCP —Model Context Protocol— es un protocolo de interoperabilidad que proporciona una forma común de exponer capacidades y contexto a aplicaciones basadas en modelos.
En el nivel que necesitamos para este curso, conviene comprender:
problema de integración → host → cliente → servidor → tools → resources → prompts.
Y conservar una frontera absoluta:
MCP ≠ agente.
El problema N × M
Google describe el problema de integración mediante una idea conocida como N × M.
Supongamos:
N aplicaciones
×
M herramientas o sistemasSi cada par necesita una integración propia, el esfuerzo de desarrollo y mantenimiento se multiplica.
Cada línea puede implicar:
- autenticación;
- formatos;
- schemas;
- errores;
- versionado;
- documentación;
- permisos;
- mantenimiento.
La fragmentación no desaparece simplemente porque las APIs existan.
Qué intenta estandarizar MCP
La idea de MCP es introducir una capa común de comunicación entre aplicaciones basadas en modelos y capacidades externas.
En vez de que cada aplicación tenga que comprender completamente la implementación particular de cada herramienta, un servidor MCP puede exponer capacidades siguiendo un protocolo compartido.
Esto busca desacoplar, al menos parcialmente:
APLICACIÓNde:
IMPLEMENTACIÓN PARTICULAR DE LA TOOL O FUENTEEl resultado esperado es una arquitectura más modular.
Protocolo no significa producto único
MCP no es una aplicación concreta.
No es un chatbot.
No es una base de datos.
No es un modelo.
Es un protocolo.
La analogía más útil es pensar en una regla común de comunicación.
La analogía ayuda porque muestra que distintos componentes pueden hablar siguiendo convenciones compartidas.
Pero deja de servir si imaginamos que todos los servidores MCP ofrecen las mismas capacidades o el mismo nivel de seguridad.
El protocolo define una forma de interacción; cada implementación sigue teniendo sus propias decisiones de diseño.
La arquitectura básica: host, cliente y servidor
La arquitectura MCP contiene tres conceptos que conviene distinguir.
Host
El host es la aplicación que crea y administra conexiones MCP.
Puede ser, por ejemplo:
una aplicación jurídica
un entorno de desarrollo
un asistente empresarialEl host coordina la experiencia del usuario y puede aplicar políticas de seguridad.
Cliente MCP
El cliente es el componente dentro del host que mantiene la conexión con un servidor MCP.
Su función incluye enviar solicitudes y recibir respuestas.
Podemos pensar:
HOST
aplicación completa
CLIENTE MCP
componente que habla MCP con un servidorServidor MCP
El servidor expone capacidades que quiere poner a disposición de aplicaciones.
Puede actuar como adapter o proxy hacia:
- una API;
- una base de datos;
- un DMS;
- un servicio;
- funciones locales.
Google describe entre sus responsabilidades el descubrimiento de tools, recepción y ejecución de comandos y devolución de resultados.
Mapa mínimo
flowchart LR
U[Usuario] --> H[Aplicación / Host]
H --> M[Modelo]
H --> C[Cliente MCP]
C <--> S[Servidor MCP]
S --> X[Sistema externo]
Éste es suficiente para un lector no técnico.
El usuario trabaja con la aplicación.
La aplicación contiene un cliente MCP.
El cliente se comunica con un servidor.
El servidor expone capacidades o contexto y puede interactuar con un sistema externo.
MCP puede envolver una API existente
Una confusión frecuente consiste en imaginar que MCP reemplaza las APIs.
No necesariamente.
Una arquitectura común puede ser:
Aplicación
↓
Cliente MCP
↓
Servidor MCP
↓
API existente
↓
Sistema externoEl servidor MCP puede actuar como una capa de adaptación.
Por eso:
API
≠
MCPUna API sigue siendo la interfaz del sistema.
MCP puede ofrecer una forma común de exponer esa capacidad a aplicaciones basadas en modelos.
Tools
La capacidad más importante para nuestro recorrido son las tools.
Un servidor MCP puede anunciar operaciones como:
buscar_documentos
obtener_documento
consultar_proveedor
crear_ticketLa aplicación puede descubrir qué tools existen y qué esquemas utilizan.
Esto evita que todas las capacidades tengan que estar codificadas de manera completamente específica en cada aplicación.
Tool como operación
La distinción aprendida sigue intacta:
TOOL
algo que puedo invocarPor ejemplo:
buscar_documentos(proveedor, tipo)Resources
MCP contempla también resources.
Google los describe como datos contextuales accesibles a la aplicación host.
Pueden incluir:
archivo
registro de base de datos
schema de base de datos
imagen
configuración
PDFPara nuestro caso contractual:
Contrato_ACME_2026.pdf
Anexo_Seguridad_ACME.pdf
Politica_Contratacion_IA.pdfpueden conceptualizarse como resources.
La diferencia sencilla es:
TOOL
operación invocable
RESOURCE
objeto o información accesibleResources no son RAG
Aquí conviene proteger otra frontera.
Un resource puede ser un documento disponible mediante MCP.
RAG es un mecanismo para localizar e incorporar información pertinente.
Un sistema podría utilizar resources dentro de un proceso de recuperación, pero los conceptos no son equivalentes.
RESOURCE
qué objeto está disponible
RAG
cómo recuperamos información pertinente para una tareaNo necesitamos volver a enseñar RAG para comprender esta diferencia.
Prompts
MCP contempla además prompts como capacidad del lado del servidor.
Pueden ser ejemplos o plantillas reutilizables asociadas a tools y resources.
Por ejemplo:
revisión_estándar_proveedor
pauta_negociacion_responsabilidadUn servidor podría proporcionar una instrucción diseñada para ayudar a utilizar correctamente los recursos que expone.
Esto conecta con las páginas anteriores sobre prompts y templates.
Pero la existencia de esta capacidad introduce también riesgos: aceptar instrucciones provenientes de servicios externos puede alterar el comportamiento de la aplicación.
Google advierte específicamente que los prompts distribuidos por servidores pueden introducir problemas de seguridad en entornos empresariales.
Tools, Resources y Prompts
Podemos consolidar la distinción.
| Elemento | Qué representa | Ejemplo contractual |
|---|---|---|
| Tool | Operación invocable | buscar_documentos |
| Resource | Objeto o información accesible | Contrato_ACME.pdf |
| Prompt | Instrucción reutilizable | pauta_revision_proveedor |
Las tres categorías ayudan a evitar que la palabra “herramienta” termine significando cualquier cosa conectada a la aplicación.
No todas las capacidades MCP tienen igual soporte
La especificación contempla más capacidades además de tools, resources y prompts.
Sin embargo, el propio material de Google destaca que el soporte práctico es desigual y que las tools son, por mucho, la capacidad más extendida en implementaciones observadas.
Esta observación ilustra una distinción transversal del handbook:
ESPECIFICACIÓN
lo que un protocolo permite
IMPLEMENTACIÓN
lo que una aplicación concreta realmente soportaNo debemos leer una especificación y asumir automáticamente que todas las plataformas implementan cada capacidad.
MCP facilita descubrimiento, pero no elimina gobierno
Supongamos que una aplicación puede descubrir automáticamente que un servidor ofrece:
buscar_contrato
crear_registro
eliminar_documentoEso no significa que deba permitir al modelo utilizar las tres.
El host puede aplicar políticas y limitar qué tools están disponibles.
El servidor también puede exponer un conjunto acotado.
Y la tool puede validar sus argumentos.
Las clases UDD resumen esta arquitectura con una idea útil:
la aplicación define permisos
el servidor expone capacidades acotadas
las tools validan argumentos
el sistema registra llamadas y resultadosMCP no elimina esos controles.
MCP tampoco resuelve confianza automáticamente
Un servidor puede ser de un tercero.
Puede cambiar.
Puede exponer nuevas tools.
Puede devolver contenido externo.
Puede contener errores.
Por eso el protocolo no convierte una capacidad en confiable por el hecho de estar estandarizada.
Una implementación empresarial necesita decidir:
qué servidores están permitidos
qué tools se aceptan
qué datos pueden enviarse
qué resources pueden incorporarse
qué acciones requieren autorizaciónMCP ≠ connector
Los conceptos están relacionados, pero no son idénticos.
Un connector suele representar una integración concreta con un sistema particular.
MCP define una interfaz común mediante la cual diferentes capacidades pueden exponerse.
Un servidor MCP puede funcionar como adapter o proxy hacia una API y cumplir un papel parecido a un connector.
Pero la distinción pedagógica se mantiene:
CONNECTOR
integración preparada con un sistema
MCP
protocolo común de interoperabilidadMCP ≠ agente
Llegamos a la frontera más importante.
Supongamos que un servidor MCP expone:
buscar_contrato
obtener_anexo
consultar_excepciones
crear_borrador¿Qué ha ocurrido?
La aplicación dispone ahora de cuatro capacidades accesibles mediante un protocolo común.
Pero MCP no ha determinado:
qué objetivo perseguir
qué tool utilizar primero
qué hacer según el resultado
cuándo terminar
cuándo pedir ayuda
qué alternativa elegirEsas son preguntas de decisión y orquestación.
MCP crea el carril técnico.
No decide la política de circulación.
Interoperabilidad ≠ autonomía
MCP puede facilitar que una aplicación descubra y utilice capacidades externas.
No convierte por sí mismo esa aplicación en un agente.
Un workflow fijo puede usar MCP.
Una aplicación manual puede usar MCP.
Un agente puede usar MCP.
El protocolo no determina cuál de esas arquitecturas existe.
El caso conductor completo
Nuestro revisor contractual necesita consultar el DMS.
El host es:
Aplicación de revisión contractualMantiene un cliente MCP.
El cliente se conecta a:
Servidor MCP del DMSEl servidor anuncia:
Tools:
- buscar_documentos
- obtener_documento
Resources:
- metadatos de documentos autorizados
Prompts:
- pauta opcional de uso del repositorioEl modelo necesita el anexo.
La aplicación utiliza la tool:
buscar_documentos(
proveedor = "ACME",
tipo = "anexo_seguridad"
)El servidor consulta el DMS y devuelve el resultado.
Nada en ese circuito implica todavía que el sistema pueda aprobar el contrato.
La capacidad de conexión y la autoridad de decisión siguen separadas.
Una vista integrada
flowchart LR
U[Usuario] --> H[Host jurídico]
H --> M[Modelo]
H --> C[Cliente MCP]
C --> S[Servidor MCP DMS]
S --> T[Tools]
S --> R[Resources]
S --> P[Prompts]
S --> A[API / sistema externo]
El diagrama resume el nivel técnico necesario para esta etapa del curso.
No necesitamos profundizar todavía en registries, multi-agent systems o protocolos entre agentes.
Eso pertenece a páginas posteriores.
Por qué importa para un abogado
Si un proveedor afirma:
“Nuestra plataforma soporta MCP”
la afirmación es insuficiente para evaluar riesgo.
Debemos preguntar:
¿Qué servidores MCP puede conectar?
¿Quién los administra?
¿Qué tools exponen?
¿Qué resources pueden incorporarse?
¿Se aceptan prompts del servidor?
¿Qué permisos tiene cada conexión?
¿Puede el usuario añadir servidores arbitrarios?
¿Qué queda registrado?
¿qué acciones requieren aprobación?El valor jurídico de comprender MCP no consiste en programar el protocolo.
Consiste en entender qué nueva superficie de integración y control introduce.
Descubrimiento dinámico: una capacidad útil que también debe gobernarse
Una ventaja de un protocolo como MCP es que un servidor puede anunciar las tools que ofrece.
Eso facilita descubrimiento.
Pero también plantea una pregunta:
¿qué ocurre si el servidor cambia su inventario?
Supongamos que ayer exponía:
buscar_documento
leer_documentoy mañana añade:
eliminar_documentoLa aplicación no debería asumir automáticamente que toda capacidad anunciada queda autorizada.
Puede mantener una política propia:
TOOLS PERMITIDAS
buscar_documento
leer_documento
TOOL NUEVA
eliminar_documento
→ bloqueada hasta revisiónEsto muestra que interoperabilidad y gobernanza deben diseñarse juntas.
Confiar en el servidor y confiar en cada resultado son cosas diferentes
Un servidor puede pertenecer a un proveedor aprobado.
Aun así, cada resultado puede necesitar validación.
Por ejemplo, un resource puede contener texto obtenido de una fuente externa. Ese contenido podría estar desactualizado, ser incorrecto o incluir instrucciones maliciosas.
Por eso la cadena de confianza tiene varios niveles:
¿confío en quién opera el servidor?
↓
¿confío en la tool concreta?
↓
¿confío en la fuente consultada?
↓
¿puedo validar el resultado recibido?No basta una respuesta binaria como “MCP seguro” o “MCP inseguro”.
Un servidor MCP no debería convertirse en una caja negra de autoridad
Pensemos en un servidor que expone:
aprobar_contratoEl hecho de que la operación esté disponible mediante MCP no dice nada sobre si debería existir, quién puede utilizarla o qué controles requiere.
La interfaz común hace más fácil conectarse.
No transforma una mala política de permisos en una buena política.
Esta es una razón para mantener el análisis por capas:
PROTOCOLO
cómo se comunica
TOOL
qué operación existe
PERMISO
quién puede usarla
DECISIÓN
cuándo se selecciona
RESPONSABILIDAD
quién respondeMCP y contratos de tecnología
Si una solución empresarial depende de MCP, pueden aparecer preguntas contractuales nuevas o más visibles:
¿qué servidores forman parte del servicio?
¿quién los opera?
¿pueden cambiar sin aviso?
¿qué capacidades pueden añadir?
¿qué soporte se presta?
¿qué logs existen?
¿quién responde por una integración de tercero?No necesitamos convertir estas preguntas en un capítulo de negociación tecnológica. Su función aquí es mostrar que el protocolo es parte de una arquitectura operacional que puede convertirse en objeto de especificación y control.
Qué debes recordar
MCP aparece para abordar un problema de interoperabilidad entre muchas aplicaciones y muchas capacidades externas.
Su arquitectura básica contiene:
HOST
aplicación que administra la experiencia y clientes
CLIENTE
componente que mantiene la conexión MCP
SERVIDOR
componente que expone capacidadesY del lado del servidor puede exponer, entre otras cosas:
TOOLS
operaciones
RESOURCES
información u objetos
PROMPTS
instrucciones reutilizablesLa existencia de MCP no elimina permisos, validación, evaluación ni control humano.
Y, sobre todo:
MCP ≠ AGENTEEl problema que todavía queda abierto
Con tools, APIs, connectors y MCP ya podemos construir un sistema capaz de interactuar con muchas fuentes y aplicaciones.
Eso aumenta muchísimo su poder operacional.
Precisamente por eso la última pregunta de esta sección no es técnica en sentido estrecho.
Es una pregunta de gobierno:
¿qué puede hacer realmente cada identidad, sobre qué recursos y cuándo necesita autorización?
El siguiente nodo se dedica a permisos: leer, escribir, comunicar, modificar y distinguir las acciones que pueden ejecutarse de aquellas que deben pasar por una aprobación humana.