MCP bidireccional: el marketplaces y el RAG expuesto

El asistente que se encuentra con las herramientas a mitad de camino MCP tiene dos sentidos, y la mayoría de las integraciones solo cuenta el primero

MCP tiene dos sentidos, y la mayoría de las integraciones solo cuenta el primero. En el sentido de conectar, usted lleva servidores MCP EXTERNOS al workspace y sus herramientas se vuelven invocables en los chats - sin código, sin redesplegar. En el sentido de exponer, Simmetric Chat se da la vuelta: un servidor MCP integrado sirve la búsqueda RAG del workspace a clientes EXTERNOS - sus IDE, donde sus desarrolladores ya trabajan.

Este artículo recorre ambos sentidos más las superficies de control que los vuelven seguros de operar: el flujo de instalación desde el marketplaces, las conexiones manuales, el pinning por chat, el repliegue de transporte, y los chequeos de salud.

Las operaciones de escritura del marketplaces son de admin (navegar basta un usuario autenticado). El dato: FACT-CENSUS.md F-MCP-1.

El sentido de conectar: el marketplaces

El MCP Marketplace es un catálogo curado de servidores MCP externos. Navegar el catálogo (lista + detalle) basta con autenticarse; los brazos de escritura - crear entradas e instalar en un workspace - son solo del admin. El flujo de instalación es atómico y autocontenido:

1. El esquema valida el payload de instalación (un workspace + una sobreescritura opcional de nombre/encabezados - los encabezados pasan un chequeo de bloqueo por lado de escritura que rechaza las llaves hop-by-hop, impone una regex de nombres, y acota tamaños).
2. La entrada debe existir (404) y no estar ya instalada en ese workspace (409).
3. La fila de conexión del espacio de trabajo nace con la URL y el transporte del catálogo.
4. El evento aterriza en el registro de audit (mcp.installed), y el conector arranca fire-and-forget: un fallo de conexión se registra, jamás tragado en un estado "sano".

Desinstalar es el inverso: los registros de las herramientas caen, la conexión se borra fuerte, y el asiento de audit aterriza (mcp.uninstalled). La instalación queda reversible sin residuo.

Las herramientas externas se vuelven skills del agente

Una vez conectado, cada herramienta del servidor externo se registra en la registry de skills del agente bajo nombres sin colisiones (mcp_<conexion>_<herramienta>). La registry se resuelve por chat:

• Sin pins - cada conexión habilitada del workspace presta sus herramientas.
• Con pins - solo las pinnadas Y habilitadas Y dentro del scope; el conjunto de pins nunca puede QUITAR herramientas (solo añade - la unión estricta con las herramientas del workspace sigue).

El pinning por chat es el volante de la operación: un chat de cumplimiento habla con justo las herramientas que debe, sin tocar el resto del workspace.

El sentido de exponer: el IDE alcanza el RAG

El servidor MCP integrado expone el retrieval de la plataforma a clientes externos:

• `rag_query` - busca en los documentos del workspace (la búsqueda fundada y citada que usa el chat interno).
• `list_workspaces` - el brazo de descubrimiento del lado del cliente.

El transporte es el endpoint HTTP Streamable sin estado (la revisión core actual de MCP, respuestas solo-JSON); el transporte SSE legado sigue con un periodo de gracia. La autenticación tiene dos formas: con MCP_API_KEY puesta, un chequeo bearer (ausente o erróneo = 401); sin ella, el servidor retrocede a solo-loopback - los llamantes remotos reciben un 401 en lugar de acceso sin autenticación. La historia del IDE: el editor del desarrollador alcanza la misma búsqueda documental fundada que alcanza el chat - la base de conocimiento es un corpus con muchas puertas.

Los raíles operativos

Tres mecanismos mantienen ambos sentidos operables en vez de solamente encendidos:

• El repliegue de transporte - una conexión declarada streamable repliega a SSE ante un rechazo 4xx (nunca con un 5xx - un error del servidor no debe degradar el transporte en silencio); una declarada SSE queda SSE.
• Los chequeos de salud - un cron pg-boss recorre las conexiones instaladas + habilitadas cada 30 minutos, con ping de reintentos exponenciales, y sigue una escalera de estado (sano → stale con los primeros fallos → down desde el tercero) con los detalles por conexión.
• El mutex de conexión + el mapa de estados - connect/disconnect se serializan por conexión; los estados vivos vienen de la corrida, no de la base, así que una "prueba" refleja la verdad del momento.

La clase de audit

Toda mutación de marketplaces y conexiones anota en el registro de eventos (mcp.installed / mcp.uninstalled / los brazos CRUD) - el log inmutable de actividad de la plataforma lleva la superficie (por F-AUDIT-1), en sintonía con la historia operativa del resto de la plataforma.

Para seguir

La guía lleva la referencia completa - los campos del catálogo, install/uninstall, la semántica de pinning, los transportes del lado que expone - en /es/docs/mcp-marketplace:

• MCP Marketplace - la guía
• El post más antiguo sobre la primera versión del marketplaces: /es/blog/mcp-marketplace
• Datos de este post: filas FACT-CENSUS.md F-MCP-1 (MCP bidireccional + el marketplaces) y F-AUDIT-1 (el registro de eventos)

Provenance: Simmetric Chat docs/MCP_MARKETPLACE.md + packages/server/src/agent/mcpServer.ts/mcpClient.ts (los transportes + el repliegue), services/mcpHealthCheckJob.ts, CHANGELOG.md v0.28.1 - en el estado documental fijado por el census (SHA aca5b8ff).