Publicado el 29 de septiembre de 2026. Por el equipo de SUNIX Capital.

Un conector MCP es un pequeño servidor que le da a un asistente de IA acceso a una herramienta concreta: tu calendario, una base de datos, un CMS, un repositorio de código. MCP significa Model Context Protocol. Es un estándar abierto que define cómo se hablan el asistente y esa herramienta.

La idea es simple. Antes, cada combinación de asistente y herramienta necesitaba su propia integración. Con MCP, la herramienta se conecta una vez y cualquier asistente compatible la puede usar. Aquí va qué cambió, cómo funciona por dentro y qué conviene revisar antes de conectar uno.

¿Qué problema resolvía MCP?

Un modelo de lenguaje, solo, no sabe nada de tu trabajo. No ve tus archivos, no entra a tus sistemas, no puede crear nada fuera del chat. Para que lo haga, alguien tiene que conectarlo.

Hasta 2024, esa conexión se construía a mano. Cada empresa de IA tenía su formato de plugins o de function calling. Cada herramienta que quería estar disponible tenía que escribir una integración para cada asistente. Diez asistentes y cien herramientas eran, en la práctica, mil integraciones distintas, cada una con su mantenimiento.

Anthropic publicó MCP a fines de 2024 como un protocolo abierto para cortar ese problema. En 2025 lo adoptaron otros actores grandes de la industria, y dejó de ser el formato de una sola empresa para convertirse en un estándar compartido.

¿Cómo funciona un conector MCP?

Hay tres piezas:

• El host. La aplicación donde conversas: un chat de escritorio, un editor de código, una terminal.
• El cliente. La parte del host que habla el protocolo MCP.
• El servidor. El conector propiamente tal. Vive al lado de la herramienta y expone lo que se puede hacer con ella.

Cuando conectas un servidor, pasa esto:

1. El host se presenta. Abre la conexión y pregunta qué ofrece el servidor.
2. El servidor lista sus capacidades. Herramientas (acciones, como crear_tarea), recursos (datos para leer, como un archivo) y prompts (plantillas de uso). Cada una trae nombre, descripción y los parámetros que acepta.
3. El modelo decide cuándo usarlas. Si le pides algo que requiere una de esas herramientas, arma la llamada con los parámetros correctos.
4. El servidor ejecuta y responde. Hace la acción en la herramienta real y devuelve el resultado al chat.

El modelo nunca toca la herramienta directamente. Pide; el servidor hace. Eso permite que el servidor decida qué se puede y qué no.

¿Qué cambió en la forma de conectarse?

El cambio de fondo es de dirección. Antes, el asistente tenía que saber de antemano cómo funcionaba cada herramienta. Ahora, la herramienta se describe sola y el asistente aprende a usarla al conectarse.

¿Por qué es más fácil ahora?

Porque conectar dejó de ser un proyecto de programación. Hay dos formas comunes:

• Servidor local. Corre en tu computador. Se configura con unas líneas en un archivo de la app o con un comando en la terminal. Sirve para cosas que viven en tu equipo, como tus carpetas.
• Servidor remoto. Corre en internet y se conecta por una URL. Muchas apps ya traen un directorio de conectores: eliges uno, inicias sesión en la herramienta y listo.

La autenticación también se ordenó. En los servidores remotos, el estándar usa OAuth: la misma pantalla de «permitir acceso» que ya conoces cuando una app pide entrar a tu cuenta. No tienes que copiar contraseñas a ningún lado.

El resultado es que una persona sin conocimientos técnicos puede darle a su asistente acceso a su correo, su calendario o su gestor de proyectos en minutos. Y un equipo técnico puede exponer un sistema interno escribiendo un solo servidor.

Un ejemplo concreto: este blog

Este mismo artículo se escribió así. El CMS del blog de SUNIX expone un servidor MCP con herramientas como buscar posts, crear un borrador, subir una imagen y publicar.

El flujo fue:

1. Buscar. El asistente revisó si ya existía un post sobre MCP, para no duplicar.
2. Leer. Abrió un post publicado para copiar el estilo, no el tema.
3. Crear. Dejó este texto como borrador en el producto del blog.
4. Completar. Subió la portada y la asignó al post.

Nadie escribió una integración entre el asistente y el CMS. El CMS publicó su servidor una vez, y cualquier app compatible con MCP lo puede usar con la llave correcta. Publicar sigue siendo una decisión de una persona del equipo.

¿Qué cuidar al conectar un MCP?

Que sea fácil de conectar no significa que dé lo mismo qué conectas. Un conector le da al asistente permiso para actuar en tu nombre.

• Permisos mínimos. Si un conector solo necesita leer, no le des una llave que permite escribir o borrar.
• Origen del servidor. Instala conectores de fuentes que conoces: el proveedor oficial de la herramienta o tu propio equipo.
• Revisa las acciones. La mayoría de las apps te pide confirmar antes de que el asistente ejecute una acción. No apruebes en automático lo que no leíste.
• Contenido que entra. Un documento o una página que el asistente lee puede traer instrucciones escondidas. Un buen host las trata como datos, no como órdenes, pero conviene saber que el riesgo existe.

En resumen

• Un conector MCP es un servidor que le da a un asistente de IA acceso controlado a una herramienta.
• MCP es un estándar abierto: una herramienta se conecta una vez y la usan todos los asistentes compatibles.
• El servidor describe lo que ofrece; el modelo pide y el servidor ejecuta.
• Conectar pasó de ser un proyecto de código a un comando, un archivo de configuración o un clic en un directorio.
• La facilidad no reemplaza el criterio: permisos mínimos, fuentes conocidas y llaves bien guardadas.