MCP Marketplace: conectar herramientas externas a tu agente de IA

Por qué un agente necesita puertas, no solo una habitación

El agente ReAct en el corazón de Simmetric Chat ya sabe razonar y actuar: busca en tu base de conocimiento con RAG híbrido, escribe en la memoria del workspace y procesa documentos. Pero un agente encerrado en sus propias skills es un sistema cerrado. El Model Context Protocol (MCP) es el estándar abierto que lo convierte en un sistema abierto - un protocolo compartido por el que un asistente de IA puede descubrir y llamar herramientas externas, y por el que las herramientas externas pueden alcanzar las capacidades del propio asistente.

La historia MCP de Simmetric Chat es bidireccional. De salida, tu agente se conecta a servidores MCP externos y adquiere sus herramientas como skills. De entrada, la plataforma puede exponer su propio conocimiento RAG a otros clientes MCP, como los asistentes en los IDE. Este artículo cubre el lado saliente de cabo a rabo: el marketplace, las conexiones y los controles que deciden qué puede alcanzar realmente tu agente en una conversación dada.

El marketplace: un catálogo curado de servidores de herramientas

Los administradores llegan al marketplace desde la barra lateral - la entrada es solo para admins, porque instalar un servidor de herramientas abre un portón en las conversaciones del workspace. El catálogo presenta los servidores MCP disponibles como tarjetas con los detalles que importan antes de una instalación:

• Badges de categoría - los servidores se agrupan por dominio (herramientas para desarrolladores, bases de datos, comunicación y más), con píldoras de categoría que filtran la rejilla. Las categorías se generan a partir de los datos del catálogo, así que los filtros reflejan lo que existe de verdad.
• Niveles de verificación - los servidores official provienen de maintainers reconocidos, los verified_community han sido revisados, y las entradas unverified se listan pero no se verifican. El nivel está en la tarjeta, para que el grado de confianza sea visible antes del clic.
• Estado de salud - el endpoint de cada servidor se sondea en un ciclo de 30 minutos, y su tarjeta muestra si actualmente está healthy, stale o down, más la fecha del último commit para juzgar si el proyecto se mantiene activamente.
• Lista de herramientas - cada herramienta expuesta por el servidor, con nombre y descripción, aparece en la página de detalle antes de que instales nada.

Una barra de búsqueda filtra el catálogo por nombre o descripción en tiempo real. Nada de esto pasa por un intermediario cloud que no puedas inspeccionar: el catálogo es un conjunto de endpoints, y los badges de salud te dicen cuáles están vivos ahora.

Instalación en un clic, con alcance sobre el workspace

Instalar un servidor es un solo clic desde la tarjeta o su página de detalle, con un prerrequisito: debe haber un workspace seleccionado, porque cada conexión MCP tiene alcance sobre un workspace. Detrás del clic, el sistema crea un registro de conexión con el nombre por defecto del servidor, intenta la conexión de inmediato y registra las herramientas descubiertas en el registro de skills del agente.

Lo que obtienes es la unión de las conexiones del workspace: cada servidor MCP habilitado y conectado aporta sus herramientas al agente. La conexión se crea aunque el servidor sea inalcanzable en el momento de la instalación - llega marcada disconnected, y puedes corregir su URL o transport desde los ajustes de conexión y volver a probarla.

La desinstalación es el inverso deliberado: elimina el registro de conexión, cierra la conexión runtime y desregistra todas sus herramientas. La acción es destructiva - la configuración se elimina, no se marca como borrada - que es el comportamiento honesto para una superficie de permisos tan potente.

Gestionar las conexiones en los ajustes

Cada conexión, instalada desde el marketplace o creada a mano, vive en Ajustes → Conexiones MCP. La tabla muestra el nombre visible, la URL del servidor con su transport, un punto de estado live y un interruptor habilitar/deshabilitar:

• Transport. Se admiten dos tipos de conexión: Server-Sent Events (sse) y streamable HTTP (streamable-http). Editar una conexión puede cambiar URL, nombre o transport, y editar una conexión habilitada dispara una reconexión automática.
• Estado live. La tabla consulta los servidores cada 30 segundos: verde para conectado, gris para desconectado, rojo para error. Una acción Test desconecta, reconecta y reporta el número de herramientas descubiertas - con un timeout de 10 segundos, para que un endpoint muerto te cueste diez segundos, no una tarde.
• Habilitar frente a deshabilitar. Deshabilitar cierra la conexión runtime y desregistra las herramientas manteniendo la configuración en la base de datos, para que una integración estacional pueda apagarse sin borrar nada.

Para los casos reales de mismatch de transport, el cliente recae con sensatez: una conexión configurada para streamable HTTP que responde con un 4xx reintenta como SSE, mientras que una conexión declarada explícitamente sse se queda en SSE.

Pinning por chat: privilegio mínimo para las conversaciones

La habilitación a nivel de workspace es un pincel ancho. El control fino es el pinning por chat, disponible desde el panel consola junto a cada conversación: un menú desplegable lista las conexiones MCP del workspace con un punto de estado y un interruptor para cada una.

Fija (pin) una conexión para convertirla en el conjunto de herramientas deliberado de ese chat - útil para conversaciones enfocadas, discusiones sensibles o para probar cómo se comporta el agente con un subconjunto específico de herramientas. El modelo de pinning es estrictamente aditivo: fijar conexiones nunca retira las herramientas de las demás conexiones activas y conectadas del workspace; quitar todos los pins vuelve a la unión por defecto de todas las conexiones habilitadas. Los pins sobreviven a recargas y reinicios, almacenados por chat, con un interruptor optimista que vuelve al estado anterior y señala un error si la persistencia falla.

El resultado es un modelo de privilegio mínimo para las herramientas del agente: el workspace decide qué existe, los interruptores de conexión deciden qué está generalmente disponible, y cada chat decide qué puede alcanzar esa conversación concreta.

La dirección entrante: exponer el RAG vía MCP

El mismo protocolo gira también al revés. La plataforma puede hacer de servidor MCP, exponiendo la búsqueda RAG híbrida sobre su propia base de conocimiento para que clientes MCP externos - los asistentes en los IDE son el ejemplo canónico - puedan anclar sus respuestas en tu conocimiento curado y protegido por RBAC. Tus documentos se quedan donde están; el asistente del IDE llama, recibe resultados de búsqueda con citas y nunca necesita una copia del corpus.

Esto convierte la base de conocimiento en infraestructura: los mismos documentos indexados sirven al workspace de chat interno y a cualquier herramienta MCP-aware que tu equipo ya use, con las mismas reglas de acceso aplicadas en la frontera.

Dónde encajan las herramientas en el bucle del agente

Las herramientas MCP entran en el agente como skills de primera clase. Cuando el orquestador ReAct está en marcha, las herramientas proporcionadas vía MCP se codean con las skills integradas - búsqueda en la base de conocimiento, memoria del workspace, procesamiento de documentos - y el agente decide en cada turno si una llamada a herramienta ayuda a responder. Los nombres de las herramientas llevan namespace por conexión para que los identificadores nunca colisionen, y cada evento en streaming que reporta uso de herramientas lleva el nombre de la fuente legible, para que la traza de actividad del chat muestre qué conexión sirvió qué llamada.

Los controles de salud de las conexiones instaladas corren como jobs planificados a través de la cola basada en Postgres de la plataforma, para que un marketplace que se vuelve stale sea notado por la infraestructura y no por los usuarios. Toda la superficie - catálogo, conexiones, pinning - está protegida por el RBAC de la plataforma: gate admin en marketplace y gestión de conexiones, y el pinner por chat se queda dentro de la superficie de chat que los usuarios ya tienen.

Para empezar

1. Abre el marketplace desde la barra lateral (rol admin) y elige un servidor verificado cuyas herramientas encajen con un flujo de trabajo real.
2. Selecciona un workspace, instala y confirma que el punto de estado se vuelve verde.
3. Abre un chat, verifica que la herramienta aparece en el panel consola y fíjala si esa conversación debe quedarse limitada a ella.
4. Haz una pregunta que requiera la herramienta - la traza de actividad del agente muestra la llamada, su fuente y su resultado.

Los servidores MCP externos son solo servidores: ejecuta uno en tu infraestructura, apunta una conexión hacia él, y la superficie de capacidades de tu agente crece sin ningún cambio de código en la plataforma.

Lee la guía completa en la documentación →