MCP (Model Context Protocol) explicado para diseñadores
MCP es un estándar abierto que conecta apps de IA con herramientas y datos. Qué expone un servidor, cuándo es local o remoto y qué revisar antes de conectarlo.
¿Qué problema resuelve y quién es quién?
Sin un estándar, cada aplicación de IA necesita su propia integración con cada servicio. Cinco aplicaciones y diez servicios son cincuenta conexiones que mantener. Con MCP, cada servicio publica un servidor una vez y cada aplicación compatible se conecta con el mismo protocolo. La documentación lo resume como construir una vez e integrar en todas partes. Claude, ChatGPT, Visual Studio Code y Cursor aparecen entre los clientes compatibles.
Para un agente de IA, MCP es una forma de acceder a lo que necesita fuera del modelo. El protocolo solo se ocupa del intercambio de contexto: no dicta cómo la aplicación usa el modelo ni cómo gestiona ese contexto.
La arquitectura tiene tres participantes:
- Host: la aplicación de IA que coordina todo, como Claude Code o Claude Desktop.
- Client: un componente dentro del host que mantiene una conexión dedicada con un servidor. El host crea un client por cada servidor.
- Server: el programa que ofrece contexto y capacidades. Puede correr en tu computadora o en el servicio de un proveedor.
Un ejemplo de la documentación: Visual Studio Code es el host. Si lo conectas al servidor de Sentry y luego a un servidor de archivos local, crea dos clients, uno por servidor.
¿Qué puede exponer un servidor?
MCP define tres primitivas que un servidor puede ofrecer:
| Primitiva | Qué es | Quién la controla | Ejemplo en diseño |
|---|---|---|---|
| Tools | Funciones que el modelo puede invocar | El modelo | Crear un comentario en un archivo |
| Resources | Datos de solo lectura que dan contexto | La aplicación | Leer las variables de un sistema de diseño |
| Prompts | Plantillas de instrucciones listas para usar | El usuario | “Revisa esta pantalla con la guía de accesibilidad” |
La diferencia práctica es quién decide. El modelo elige cuándo llamar a una tool, así que ahí están los riesgos: una tool puede escribir en bases de datos, modificar archivos o llamar APIs externas. La documentación indica que las tools pueden requerir el consentimiento del usuario antes de ejecutarse y que las aplicaciones pueden mostrar diálogos de aprobación o registros de actividad. Un resource lo pide la aplicación para dar contexto. Un prompt lo invoca el usuario de forma explícita, por ejemplo con un comando slash.
Los nombres y descripciones de las tools los lee el modelo, igual que en cualquier tool use. Un servidor con nombres claros produce mejores llamadas.
¿Qué cambia entre un servidor local y uno remoto?
“Local” y “remoto” describen dónde corre el servidor, no qué hace. Un servidor local se ejecuta en tu máquina y usa el transporte stdio (entrada y salida estándar); suele atender a un solo cliente. Uno remoto corre en el servicio y usa Streamable HTTP (HTTP con streaming opcional); suele atender a muchos clientes. Para autenticarse, MCP recomienda OAuth.
| Local (stdio) | Remoto (Streamable HTTP) | |
|---|---|---|
| Dónde corre | Tu computadora | El servicio del proveedor |
| Instalación | La haces tú | Ninguna, solo conectar |
| Riesgo principal | Corre con los permisos de tu usuario | Depende de la autorización y del proveedor |
Figma ofrece los dos. Su documentación recomienda el servidor remoto, que aloja Figma, no necesita la aplicación de escritorio y tiene más funciones; el de escritorio corre dentro de la app de Figma y está pensado para necesidades de organizaciones y empresas. Escribir en el lienzo, es decir, crear y editar marcos, componentes y variables, solo funciona con el servidor remoto. Para el flujo completo, mira de Figma a código con MCP y servidores MCP útiles para diseñadores.
¿Qué revisar antes de conectar un servidor?
Las herramientas que usas (un archivo de Figma, un tablero de tareas, un repositorio) pueden exponerse por MCP. Un agente podrá leer lo que ahí haya y, si el servidor lo permite, cambiarlo. Antes de conectar:
- Lista de capacidades. Lee qué tools ofrece. Lo que el servidor expone es lo que el agente puede hacer.
- Lectura o escritura. Si hay tools que escriben, decide si cada llamada pedirá tu aprobación. Más sobre esto en aprobación de acciones y UX de permisos.
- Quién lo publica. La guía de seguridad de MCP advierte que un servidor local es un programa que se descarga y ejecuta, y que corre con los mismos privilegios que el cliente. Un servidor malicioso, o un comando de arranque pegado desde un tutorial sin leerlo, podría ejecutar código en tu máquina. Revisa el comando completo antes de aceptarlo.
- Permisos mínimos. La misma guía recomienda empezar con el alcance mínimo y ampliarlo solo cuando haga falta. Para tu equipo, eso significa empezar en solo lectura.
Puedes reforzar el límite con sandboxing y permisos, que restringe a qué archivos y redes llega el proceso.
¿Cuándo NO conviene MCP?
- Cuando necesitas una sola función propia dentro de tu aplicación. Una tool local simple es más directa.
- Cuando el servicio ya tiene una integración nativa en la herramienta que usas.
- Cuando no puedes revisar qué expone el servidor ni quién lo mantiene.
Ejemplo
Ejemplo ilustrativo: un equipo de producto conecta el servidor remoto de Figma a Claude Code para generar código a partir de un marco. Antes de conectarlo, alguien lee la lista de tools y ve que algunas escriben en el lienzo. Deciden que cada llamada de escritura pida aprobación y que el agente trabaje sobre una copia del archivo, no sobre el de producción. Esa decisión se toma al configurar la conexión, no en el prompt.
¿Qué puedes hacer mañana?
- Haz una lista de las herramientas que tu equipo usa a diario y revisa cuáles tienen servidor MCP oficial.
- Para cada una, anota si el acceso es de lectura o escritura, si el servidor es local o remoto y quién puede revocarlo.
- Empieza con una sola conexión en solo lectura y úsala una semana en una tarea real antes de sumar otra.
Errores comunes
- Confundir MCP con una API. MCP es el protocolo; un servidor suele envolver una o varias APIs.
- Instalar un servidor local de un tercero sin leer el comando que ejecuta.
- Suponer que el servidor tiene los mismos permisos que tu cuenta. Depende de cómo esté configurado.
- Dar por hecho que el agente ve algo que el servidor no expone.
- Conectar de entrada todas las tools de escritura “por si acaso”.