MCP bidirecional: o marketplaces e o RAG exposto

O assistente que encontra as ferramentas a meio do caminho MCP tem dois sentidos, e a maioria das integrações conta só o primeiro

MCP tem dois sentidos, e a maioria das integrações conta só o primeiro. No sentido de conectar, você traz servidores MCP EXTERNOS para o workspace e as suas ferramentas se tornam chamáveis nas conversas - sem código, sem reimplantar. No sentido de expor, o Simmetric Chat se revira do avesso: um servidor MCP embutido serve a busca RAG do workspace a clientes EXTERNOS - as suas IDEs, onde os seus desenvolvedores já trabalham.

Este artigo percorre ambos sentidos mais as superfícies de controle que os tornam seguros de operar: o fluxo de instalação pelo marketplaces, as conexões manuais, o pinning por conversa, o retorno de transporte, e os cheques de saúde.

As operações de escrita do marketplaces são do admin (navegar basta um usuário autenticado). Fatos: FACT-CENSUS.md F-MCP-1.

O sentido de conectar: o marketplaces

O MCP Marketplace é um catálogo de servidores MCP externos. Navegar o catálogo (lista + detalhe) basta a autenticação; os braços de escrita - criar entradas e instalar num workspace - são só do admin. O fluxo de instalação é atômico e autocontido:

1. O schema valida o payload de instalação (um workspace + uma sobreposição opcional de nome/cabeçalhos - os cabeçalhos passam um chequeo de bloqueio do lado da escrita que rejeita as chaves hop-by-hop, impõe uma regex de nomes, e cerca tampões).
2. A entrada deve existir (404) e não estar já instalada naquele workspace (409).
3. A linha de conexão do espaço de trabalho nasce com a URL e o transporte do catálogo.
4. O evento pousa no registro de audit (mcp.installed), e o conector parte fire-and-forget: uma falha de conexão se anota, jamais engolida num estado "saudável".

Desinstalar é o inverso: os registros das ferramentas caem, a conexão apaga-se dura, e a linha de audit pousa (mcp.uninstalled). A instalação fica assim reversível sem resíduo.

As ferramentas externas viram skills do agente

Uma vez conectado, cada ferramenta do servidor externo se registra na registry de skills do agente sob nomes sem colisões (mcp_<conexão>_<ferramenta>). A registry se resolve por conversa:

• Sem pins - cada conexão habilitada do workspace empresta as suas ferramentas.
• Com pins - só as pinadas E habilitadas E dentro do escopo; o conjunto de pins nunca pode TIRAR ferramentas (só acrescenta - a união estrita com as ferramentas do workspace segue).

O pinning por conversa é o volante da operação: uma conversa de conformidade fala com exatamente as ferramentas que deve, sem tocar o resto do workspace.

O sentido de expor: a IDE alcança o RAG

O servidor MCP embutido expõe o retrieval da plataforma a clientes externos:

• `rag_query` - busca nos documentos do workspace (a busca fundada e citada que o chat interno usa).
• `list_workspaces` - o braço de descoberta do lado do cliente.

O transporte é o endpoint HTTP Streamable sem estado (a revisão core atual do MCP, respostas só-JSON); o transporte SSE legado segue com um prazo de graça. A autenticação tem duas formas: com MCP_API_KEY posta, um cheque bearer (faltando ou errando = 401); sem ela, o servidor recua para só-loopback - os chamantes remotos recebem um 401 em vez de acesso sem autenticação. A história da IDE: o editor do desenvolvedor alcança a mesma busca documental fundada que alcança o chat - a base de conhecimento é um corpus com muitas portas.

Os trilhos operacionais

Três mecanismos mantêm os dois sentidos operáveis em vez de somente ligados:

• O retorno de transporte - uma conexão declarada streamable retorna a SSE ante uma recusa 4xx (nunca com um 5xx - um erro do servidor não deve degradar o transporte em silêncio); uma declarada SSE segue SSE.
• Os cheques de saúde - um cron pg-boss roda pelas conexões instaladas + habilitadas a cada 30 minutos, com ping de tentativas exponenciais, e segue uma escada de estado (saudável → stale com os primeiros falços → down desde o terceiro) com os detalhes por conexão.
• O mutex de conexão + o mapa de estados - connect/disconnect se serializam por conexão; os estados vivos vêm da corrida, não da base, assim um "teste" reflete a verdade do momento.

A classe de audit

Toda mutação de marketplaces e conexões anota no registro de eventos (mcp.installed / mcp.uninstalled / os braços CRUD) - o log imutável de atividade da plataforma leva a superfície (por F-AUDIT-1), no tom da história operativa do resto da plataforma.

Para continuar

A guia leva a referência completa - os campos do catálogo, install/uninstall, a semântica de pinning, os transportes do lado que expõe - em /pt/docs/mcp-marketplace:

• MCP Marketplace - a guia
• O post mais antigo sobre a primeira versão do marketplaces: /pt/blog/mcp-marketplace
• Fatos deste post: linhas FACT-CENSUS.md F-MCP-1 (MCP bidirecional + o marketplaces) e F-AUDIT-1 (o registro de eventos)

Provenance: Simmetric Chat docs/MCP_MARKETPLACE.md + packages/server/src/agent/mcpServer.ts/mcpClient.ts (os transportes + o retorno), services/mcpHealthCheckJob.ts, CHANGELOG.md v0.28.1 - no estado documental fixado pelo census (SHA aca5b8ff).