Blog
Novidades do produto

MCP Marketplace: conectar ferramentas externas ao seu agente de IA

O Simmetric Chat fala MCP nas duas direções - um marketplace curado de servidores de ferramentas externos, instalações em um clique e controle por chat sobre o que seu agente pode alcançar.

Simmetric Team6 min de leitura24/02/2026

Por que um agente precisa de portas, não apenas de uma sala

O agente ReAct no coração do Simmetric Chat já sabe raciocinar e agir: busca na sua base de conhecimento com RAG híbrido, escreve na memória do workspace e processa documentos. Mas um agente trancado dentro das próprias skills é um sistema fechado. O Model Context Protocol (MCP) é o padrão aberto que o transforma em um sistema aberto - um protocolo compartilhado pelo qual um assistente de IA pode descobrir e chamar ferramentas externas, e pelo qual ferramentas externas podem alcançar as capacidades do próprio assistente.

A história MCP do Simmetric Chat é bidirecional. Na saída, seu agente se conecta a servidores MCP externos e adquire suas ferramentas como skills. Na entrada, a plataforma pode expor o próprio conhecimento RAG a outros clientes MCP, como os assistentes nas IDEs. Este artigo cobre o lado de saída de ponta a ponta: o marketplace, as conexões e os controles que decidem o que seu agente pode realmente alcançar numa dada conversa.

O marketplace: um catálogo curado de servidores de ferramentas

Os administradores chegam ao marketplace pela barra lateral - a entrada é restrita a admins, porque instalar um servidor de ferramentas abre um portão nas conversas do workspace. O catálogo apresenta os servidores MCP disponíveis como cartões com os detalhes que importam antes de uma instalação:

  • Badges de categoria - os servidores são agrupados por domínio (ferramentas para desenvolvedores, bancos de dados, comunicação e mais), com pílulas de categoria que filtram a grade. As categorias são geradas a partir dos dados do catálogo, então os filtros refletem o que realmente existe.
  • Níveis de verificação - servidores official vêm de maintainers reconhecidos, os verified_community foram revisados, e as entradas unverified são listadas mas não verificadas. O nível está no cartão, para que o grau de confiança seja visível antes do clique.
  • Estado de saúde - o endpoint de cada servidor é sondado num ciclo de 30 minutos, e seu cartão mostra se ele está atualmente healthy, stale ou down, mais a data do último commit para julgar se o projeto é ativamente mantido.
  • Lista de ferramentas - cada ferramenta exposta pelo servidor, com nome e descrição, aparece na página de detalhe antes de você instalar qualquer coisa.

Uma barra de busca filtra o catálogo por nome ou descrição em tempo real. Nada disso passa por um intermediário na nuvem que você não possa inspecionar: o catálogo é um conjunto de endpoints, e os badges de saúde dizem quais estão vivos agora.

Instalação em um clique, com escopo no workspace

Instalar um servidor é um único clique a partir do cartão ou da sua página de detalhe, com um pré-requisito: um workspace deve estar selecionado, porque cada conexão MCP tem escopo num workspace. Por trás do clique, o sistema cria um registro de conexão com o nome padrão do servidor, tenta a conexão imediatamente e registra as ferramentas descobertas no registro de skills do agente.

O que você obtém é a união das conexões do workspace: cada servidor MCP habilitado e conectado contribui com suas ferramentas para o agente. A conexão é criada mesmo se o servidor estiver inalcançável no momento da instalação - ela chega marcada disconnected, e você pode corrigir sua URL ou transport nas configurações de conexão e testá-la de novo.

A desinstalação é o inverso deliberado: remove o registro de conexão, fecha a conexão de runtime e desregistra todas as suas ferramentas. A ação é destrutiva - a configuração é removida, não soft-deleted - o que é o comportamento honesto para uma superfície de permissões tão poderosa.

Gerenciar as conexões nas configurações

Cada conexão, instalada pelo marketplace ou criada à mão, vive em Configurações → Conexões MCP. A tabela mostra o nome exibido, a URL do servidor com seu transport, um ponto de status ao vivo e um interruptor habilitar/desabilitar:

  • Transport. Dois tipos de conexão são suportados: Server-Sent Events (sse) e streamable HTTP (streamable-http). Editar uma conexão pode mudar URL, nome ou transport, e editar uma conexão habilitada dispara uma reconexão automática.
  • Status ao vivo. A tabela consulta os servidores a cada 30 segundos: verde para conectado, cinza para desconectado, vermelho para erro. Uma ação Test desconecta, reconecta e reporta o número de ferramentas descobertas - com um timeout de 10 segundos, para que um endpoint morto custe dez segundos, não uma tarde inteira.
  • Habilitar versus desabilitar. Desabilitar fecha a conexão de runtime e desregistra as ferramentas mantendo a configuração no banco de dados, para que uma integração sazonal possa ser desligada sem apagar nada.

Para os casos reais de incompatibilidade de transport, o cliente recua com sensatez: uma conexão configurada para streamable HTTP que responde com um 4xx tenta de novo como SSE, enquanto uma conexão declarada explicitamente sse permanece em SSE.

Pinning por chat: privilégio mínimo para as conversas

A habilitação no nível do workspace é um pincel largo. O controle fino é o pinning por chat, disponível no painel de console ao lado de cada conversa: um menu suspenso lista as conexões MCP do workspace com um ponto de status e um interruptor para cada uma.

Fixe (pin) uma conexão para torná-la o conjunto deliberado de ferramentas daquele chat - útil para conversas focadas, discussões sensíveis ou para testar como o agente se comporta com um subconjunto específico de ferramentas. O modelo de pinning é estritamente aditivo: fixar conexões nunca remove as ferramentas das outras conexões ativas e conectadas do workspace; remover todos os pins volta à união padrão de todas as conexões habilitadas. Os pins sobrevivem a recarregamentos e reinícios, armazenados por chat, com um interruptor otimista que volta ao estado anterior e sinaliza um erro se a persistência falhar.

O resultado é um modelo de privilégio mínimo para as ferramentas do agente: o workspace decide o que existe, os interruptores de conexão decidem o que está geralmente disponível, e cada chat decide o que aquela conversa específica pode alcançar.

A direção de entrada: expor o RAG via MCP

O mesmo protocolo gira também ao contrário. A plataforma pode atuar como servidor MCP, expondo a busca RAG híbrida sobre a própria base de conhecimento para que clientes MCP externos - os assistentes nas IDEs são o exemplo canônico - possam ancorar suas respostas no seu conhecimento curado e protegido por RBAC. Seus documentos ficam onde estão; o assistente da IDE chama, recebe resultados de busca com citações e nunca precisa de uma cópia do corpus.

Isso transforma a base de conhecimento em infraestrutura: os mesmos documentos indexados servem o workspace de chat interno e qualquer ferramenta MCP-aware que sua equipe já use, com as mesmas regras de acesso aplicadas na fronteira.

Onde as ferramentas se encaixam no ciclo do agente

As ferramentas MCP entram no agente como skills de primeira classe. Quando o orquestrador ReAct está em execução, as ferramentas fornecidas via MCP ficam lado a lado com as skills integradas - busca na base de conhecimento, memória do workspace, processamento de documentos - e o agente decide a cada turno se uma chamada de ferramenta ajuda a responder. Os nomes das ferramentas ganham namespace por conexão para que os identificadores nunca colidam, e cada evento em streaming que reporta uso de ferramenta carrega o nome legível da fonte, para que a trilha de atividade do chat mostre qual conexão serviu qual chamada.

Os controles de saúde das conexões instaladas rodam como jobs agendados através da fila baseada em Postgres da plataforma, para que um marketplace que fica stale seja notado pela infraestrutura e não pelos usuários. Toda a superfície - catálogo, conexões, pinning - é protegida pelo RBAC da plataforma: gate admin no marketplace e na gestão de conexões, e o pinner por chat permanece dentro da superfície de chat que os usuários já têm.

Para começar

  1. Abra o marketplace pela barra lateral (papel admin) e escolha um servidor verificado cujas ferramentas correspondam a um fluxo de trabalho real.
  2. Selecione um workspace, instale e confirme que o ponto de status fica verde.
  3. Abra um chat, verifique que a ferramenta aparece no painel de console e fixe-a se aquela conversa deve ficar limitada a ela.
  4. Faça uma pergunta que exija a ferramenta - a trilha de atividade do agente mostra a chamada, sua fonte e seu resultado.

Servidores MCP externos são apenas servidores: rode um na sua infraestrutura, aponte uma conexão para ele, e a superfície de capacidades do seu agente cresce sem nenhuma mudança de código na plataforma.

Leia o guia completo na documentação →

Artigos relacionados