El Model Context Protocol, explicado para quien construye
Todo equipo que construye más de un agente escribe el mismo adaptador dos veces: conectar con un sistema, describir lo que puede hacer y exponer esas capacidades al modelo con la forma que espera el cliente de turno. El Model Context Protocol existe para detener esa duplicación estandarizando la interfaz entre cliente de agente y servidor de herramientas.
Es realmente útil y también más estrecho de lo que sugiere el entusiasmo. MCP describe cómo se anuncian e invocan capacidades. No decide quién puede invocarlas, y confundir ambas cosas es de donde salen los incidentes de seguridad.
Qué estandariza el protocolo#
- Descubrimiento: el servidor indica al cliente sus herramientas y recursos, con esquemas.
- Invocación: el cliente llama con argumentos tipados y recibe un resultado estructurado.
- Recursos: contenido de solo lectura que el cliente trae al contexto cuando lo pide.
- Transporte: un formato común para que cliente y servidor de autores distintos se entiendan.
Lo que deliberadamente no hace#
MCP no autentica a tus usuarios, no decide qué registros puede leer cada uno y no decide si una acción necesita aprobación. Eso sigue siendo tuyo y debe vivir en el lado servidor — un cliente que pide permiso amablemente no es un sistema de permisos. El error arquitectónico más común es exponer una herramienta amplia como `run_query` por MCP y confiar en que el prompt la mantenga a raya.
Trata cada herramienta MCP como si un llamante confundido o manipulado fuera a invocarla con los peores argumentos plausibles, porque tarde o temprano ocurrirá.
Dónde compensa hoy#
| Situación | Valor de MCP |
|---|---|
| Un sistema interno, varios clientes de agente | Alto: escribes el servidor una vez |
| Asistentes de escritorio con contexto local | Alto: el ecosistema se construyó ahí |
| Un agente con tres herramientas propias | Bajo: las llamadas directas son más simples |
| Herramientas de terceros que no controlas | Medio: cómodo, pero audita el servidor |
Una forma segura de adoptarlo#
- Envuelve capacidades estrechas, no poder general: `get_order(id)` en vez de `sql(query)`.
- Aplica autorización dentro del servidor, por llamada, con la identidad del usuario final.
- Devuelve errores cortos y honestos — `no encontrado`, `no permitido` — para que el agente reaccione bien.
- Registra cada invocación con argumentos e identidad; ese es tu rastro de auditoría.
- Fija los servidores que uses a versiones revisadas, como cualquier dependencia.
La cuestión de la cadena de suministro#
Un servidor MCP de terceros es código que describe herramientas a tu agente y recibe los argumentos que tu agente decide enviar. Las descripciones forman parte del contexto del modelo, así que una descripción maliciosa o descuidada puede influir en el comportamiento. Revisa los servidores antes de adoptarlos, prefiere los que puedas leer y mantén los no confiables lejos de clientes con acceso sensible.
Preguntas frecuentes
¿Necesito MCP para construir un agente?
No. Para un agente con unas pocas herramientas propias, las llamadas directas son más simples. MCP empieza a compensar cuando la misma capacidad debe alcanzarse desde varios clientes o cuando quieres consumir herramientas de otros equipos.
¿MCP es seguro por defecto?
Es un estándar de transporte y descubrimiento, no un modelo de seguridad. Autenticación, autorización por usuario y puertas de aprobación las implementas tú en el servidor, y nunca se delegan al prompt.
¿Pueden ser vector de inyección?
Sí, tanto por descripciones que entran en el contexto como por el contenido devuelto. Trata la salida como no confiable, mantén alcances estrechos y no apuntes un agente con permisos de escritura a servidores sin revisar.
model context protocolmcp explicadoestándar herramientas agentesseguridad mcpdescubrimiento de herramientas
