MCPs: cómo conectar tu agente a Slack, Drive, HubSpot y cualquier herramienta

Hay dos tipos de agente de IA en una empresa. El que sabe lo que pasa en tu empresa: abre un lead en HubSpot, lee el pipeline actualizado, consulta el documento de estrategia en Drive, publica el resumen en el canal de Slack del equipo. Y el que tiene que pedirte todo eso cada vez que necesita trabajar.

La diferencia entre uno y otro no es el modelo de lenguaje que usan. Es si tienen o no MCPs configurados.

Este artículo explica qué es el Model Context Protocol, qué herramientas puedes conectar hoy, cómo se configura de forma segura y por qué importa entender esta capa si estás construyendo agentes que de verdad funcionen en producción.

Qué es MCP: el estándar que conecta agentes con herramientas

MCP son las siglas de Model Context Protocol. Es un protocolo abierto, desarrollado por Anthropic, que define cómo un agente de IA se comunica con herramientas externas de forma estandarizada.

Antes de MCP, cada integración era un proyecto a medida. Querías que tu agente leyera de Google Drive: código personalizado. Querías que escribiera en Notion: otro código. Querías que consultara HubSpot: otra integración. Cada una con su autenticación, su manejo de errores, su formato de respuesta. El resultado era un sistema frágil donde cada conexión era un punto de fallo diferente.

MCP cambia eso con una interfaz común. Un servidor MCP expone las capacidades de una herramienta —Slack, Drive, HubSpot, lo que sea— siguiendo el mismo protocolo. El agente no sabe si está hablando con Notion o con Salesforce. Habla con un servidor MCP. La traducción al sistema específico la hace el servidor.

El resultado práctico: el agente deja de ser un sistema aislado que necesita que le pases información manualmente y se convierte en un sistema conectado que puede acceder, leer y escribir en los sistemas reales de la empresa.

Para entender cómo encaja esta capa en la arquitectura completa de un agente, puedes consultar este artículo sobre cómo construir un agente con Claude Code paso a paso.

Qué MCPs existen hoy

El ecosistema de servidores MCP crece rápido. Estos son los que tienen adopción real en entornos de empresa:

La lista no es exhaustiva. El ecosistema tiene ya más de cien servidores MCP mantenidos por la comunidad, y el número crece cada semana. Si la herramienta que necesitas no existe todavía como MCP, puedes crear un servidor personalizado. Lo explico al final de este artículo.

Cómo se configura: el archivo .mcp.json

La configuración de MCPs vive en un archivo llamado .mcp.json en la raíz del proyecto. Claude Code lo lee al iniciarse y establece las conexiones con los servidores MCP definidos.

La estructura del archivo es un objeto mcpServers donde cada entrada define cómo lanzar ese servidor: el comando que lo ejecuta y las variables de entorno que necesita para autenticarse con la herramienta destino. Hay un principio de seguridad fundamental en este punto: las credenciales nunca van en el archivo en texto plano. El .mcp.json debe poder subirse al repositorio sin riesgo, lo que significa que todos los tokens y claves de API se leen de variables de entorno del sistema. El archivo describe la estructura; el entorno de ejecución aporta los secretos.

Esto no es una convención estética. Es seguridad básica. Un archivo de configuración con claves de API en texto plano es un incidente esperando pasar.

Los nombres exactos de los paquetes npm para cada herramienta, los campos de entorno requeridos y el proceso de obtener las credenciales correctas en cada sistema es lo que trabajamos en el curso presencial, porque varía por herramienta y por la configuración específica de tu empresa.

MCPs como capa de infraestructura

La forma correcta de entender MCP no es como un conjunto de plugins. Es como una capa de infraestructura.

Los agentes no llaman a las APIs externas directamente. Pasan siempre por el servidor MCP correspondiente. Eso tiene tres consecuencias importantes:

Interfaz consistente. El agente habla el mismo protocolo con todas las herramientas. No hay que enseñarle cómo funciona la API de HubSpot versus cómo funciona la de Notion. Aprende a usar MCPs. Los MCPs saben hablar con cada herramienta.

Seguridad centralizada. Los permisos, los tokens y las reglas de acceso están en un solo lugar: la configuración del servidor MCP. Si quieres que el agente solo pueda leer de Salesforce pero no escribir, lo configuras en el MCP. No tienes que implementar esa restricción en cada punto del agente que podría hacer una llamada.

Testabilidad. Puedes levantar un servidor MCP de pruebas que simula las respuestas de HubSpot sin tocar los datos reales de producción. Los agentes funcionan igual porque hablan con el mismo protocolo. Esto convierte las pruebas en algo que se puede hacer de forma sistemática, no en algo que requiere conectar el entorno de producción.

Para entender cómo esta capa encaja con el resto de la arquitectura —skills, comandos, orquestación—, el artículo sobre arquitectura de agentes inteligentes: skills y comandos da la visión completa.

Caso real: agente de marketing conectado a HubSpot, Google Analytics y Notion

Para que no quede como teoría, este es un caso concreto de cómo funciona en la práctica.

El equipo de marketing de una empresa mediana necesitaba un informe semanal: rendimiento de las campañas activas, leads generados, estado del pipeline y resumen editorial para la semana siguiente. Antes tardaban entre dos y tres horas. Con el agente, el proceso es este:

Google Analytics MCP: el agente consulta las métricas de tráfico de la semana, identifica las páginas con mayor caída o subida de visitas y extrae las fuentes de tráfico por canal.

HubSpot MCP: el agente lee los leads creados en los últimos siete días, el estado actual del pipeline por etapa y las tareas vencidas del equipo comercial. También puede crear una tarea de seguimiento si detecta leads sin actividad en más de 48 horas.

Notion MCP: el agente lee el calendario editorial de la semana siguiente, verifica qué contenidos están marcados como aprobados y cuáles están pendientes de revisión. Al finalizar el análisis, escribe el resumen del informe directamente en la página de Notion asignada al equipo.

El resultado: un informe completo, con datos reales y actualizados, en el formato que el equipo ya usa, sin intervención manual. El agente no tiene acceso a más datos de los que necesita. Cada MCP está configurado con los permisos mínimos requeridos para la tarea.

Por dónde empezar: uno primero

La tentación habitual es conectar todo a la vez. Slack, Drive, Notion, HubSpot, el CRM, la base de datos. En la teoría suena bien. En la práctica produce un sistema que es difícil de depurar cuando algo no funciona, porque no sabes cuál de las cinco conexiones es el problema.

La recomendación es simple: elige un MCP, conéctalo y haz que funcione bien. Observa cómo el agente lo usa. Revisa los logs. Ajusta los permisos. Cuando estás seguro de que esa conexión es estable y el agente la usa correctamente, añades la siguiente.

El criterio para elegir el primero no es el MCP más impresionante. Es el que resuelve el problema más concreto y donde puedes verificar fácilmente que el resultado es correcto. Un agente que lee de Notion y escribe en Notion es fácil de verificar: abres Notion y ves si el contenido está bien. Un agente que actualiza registros en Salesforce es más difícil de verificar y más costoso si algo sale mal.

Empieza donde el ciclo de prueba y verificación sea más corto.

Qué pasa cuando el MCP que necesitas no existe

El ecosistema crece rápido, pero hay herramientas que todavía no tienen servidor MCP público. En ese caso, tienes la opción de crear un servidor MCP personalizado.

Un servidor MCP es, en esencia, un proceso que implementa el protocolo MCP y expone las capacidades de una herramienta concreta. Si tu empresa usa un ERP a medida, un sistema de reservas propietario o una base de datos interna, puedes escribir un servidor MCP que hable con esa herramienta y la exponga al agente con la misma interfaz que cualquier MCP estándar.

No es trivial. Requiere entender el protocolo MCP, implementar los handlers correctos y manejar la autenticación con la herramienta destino. Pero el resultado es un servidor MCP que funciona como cualquier otro: se configura en .mcp.json, el agente lo usa de la misma forma y los permisos se gestionan de forma centralizada.

La documentación oficial de MCP en el repositorio de Anthropic tiene la especificación completa del protocolo y ejemplos de implementación en TypeScript y Python. Es el punto de partida si necesitas ir por ese camino.

Lo que MCP no resuelve solo

Tener MCPs configurados no significa tener un agente que funcione bien. MCP resuelve el problema de la conexión. No resuelve el problema del diseño.

Un agente que tiene acceso a HubSpot, Slack y Notion a través de MCP pero que no tiene instrucciones precisas sobre qué hacer con esos accesos, cuándo usarlos y con qué criterios, es un agente que puede hacer cosas incorrectas de forma muy eficiente.

La capa de configuración —instrucciones del agente, límites de autonomía, criterios de éxito, manejo de errores— es tan importante como la capa de conexión. MCP te da la infraestructura. Lo que el agente hace con ella depende del diseño.

El orden correcto es: definir qué problema resuelve el agente, qué datos necesita para resolverlo, qué acciones tiene que ejecutar y con qué restricciones. Después conectar los MCPs que hacen posible ese diseño. No al revés.

Preguntas frecuentes