MCPNest — Um Mês. O Problema, A Solução, Cada Recurso Explicado.

O Problema

O ecossistema MCP está se expandindo a um ritmo extraordinário. Anthropic, Microsoft, Google, AWS e Cloudflare estão todos publicando servidores MCP oficiais. Centenas de servidores de código aberto existem para cada integração concebível. Desenvolvedores estão conectando ferramentas de IA — Claude, Cursor, Windsurf — a bancos de dados internos, bases de código, APIs e sistemas de arquivos.

A infraestrutura para fazer isso existe. A camada de governança não.

Hoje, na maioria das equipes de engenharia:

• Cada desenvolvedor executa servidores MCP em sua própria máquina
• Não há um registro central do que servidores estão ativos
• Não há um histórico de auditoria do que ferramentas foram chamadas, por quem, ou quando
• Credenciais — tokens de acesso pessoal do GitHub, strings de conexão de banco de dados, chaves de API — são armazenadas em arquivos JSON nos laptops dos desenvolvedores
• Não há um processo de aprovação para quais servidores os desenvolvedores podem usar
• Não há isolamento — servidores MCP são executados com as permissões totais do usuário local

Esta é a lacuna que o MCPNest preenche.

A Plataforma

O MCPNest é a plataforma de governança e infraestrutura para servidores MCP. Ele opera em três camadas: um marketplace para descoberta, um gateway para controle e uma camada de infraestrutura hospedada para isolamento e centralização.

Camada 1 — Marketplace

O que é

Um catálogo pesquisável de mais de 7.500 servidores MCP indexados do registro oficial da Anthropic e do GitHub. Cada servidor tem uma pontuação de qualidade, matriz de compatibilidade, perfil do editor e configuração de instalação.

Que problema resolve

Sem um catálogo central, os desenvolvedores encontram servidores MCP através de buscas no GitHub, posts no Reddit e artigos de blog. Não há sinal de qualidade, verificação ou informações de compatibilidade. As equipes acabam com ferramentas inconsistentes e sem visibilidade sobre o que está realmente sendo usado.

Recursos

• Mais de 7.500 servidores indexados com pontuações de qualidade e filtros de compatibilidade
• Instalação com um clique para Cursor e VS Code
• Perfis de editores com distintivos verificados
• Escolhas editoriais do Servidor da Semana
• Coleções e pacotes iniciais curados
• Validador de Configuração — valida sintaxe, endpoints e argumentos antes da instalação
• MCP Composer — construa configurações de múltiplos servidores e compartilhe via link
• Servidores em alta com dados de instalação semanais

Camada 2 — Gateway

O que é

Um único endpoint HTTPS autenticado por espaço de trabalho. Cada desenvolvedor da equipe aponta seu cliente de IA para a mesma URL do Gateway. O Gateway autentica a solicitação, verifica a lista de ferramentas permitidas, faz proxy para o servidor upstream correto e registra a chamada.

Que problema resolve

Sem um gateway, cada desenvolvedor mantém sua própria configuração local. Quando um servidor muda, todos atualizam manualmente. Não há autenticação central, auditoria ou forma de impor quais ferramentas os desenvolvedores podem usar.

Recursos

Endpoint único por espaço de trabalho
Uma URL substitui configurações individuais em cada máquina de desenvolvedor. Quando o administrador adiciona ou remove um servidor, a mudança é imediata para toda a equipe.

Autenticação de token Bearer (SHA-256)
Cada solicitação é autenticada. Tokens são armazenados como hashes SHA-256 com comparação segura em tempo. Sem segredos em texto simples.

Tokens por membro
Cada desenvolvedor tem seu próprio token Bearer. Isso significa que cada chamada de ferramenta é atribuível a um indivíduo específico, não apenas ao espaço de trabalho. Tokens podem ser revogados instantaneamente para qualquer membro sem afetar o restante da equipe.

Listas de ferramentas permitidas por membro
Os administradores definem quais ferramentas cada desenvolvedor pode chamar no nível do protocolo. Um desenvolvedor com acesso ao servidor MCP do GitHub pode ser restrito a ferramentas específicas — por exemplo, apenas operações de leitura. Alternância de imposição em todo o espaço de trabalho.

Registro de auditoria completo por chamada de ferramenta
Cada chamada é registrada com: ID do espaço de trabalho, ID do membro, servidor, nome da ferramenta, status HTTP, latência, timestamp e código de erro, quando aplicável. Nenhuma entrada ou saída é armazenada — apenas metadados. Seguro pelo GDPR por design. Logs são exportáveis.

Namespace de ferramentas
Resolução automática de conflitos quando múltiplos servidores expõem ferramentas com o mesmo nome. Nenhuma configuração manual necessária.

RBAC do espaço de trabalho
Três papéis: Proprietário, Administrador, Membro. Apenas Administradores podem aprovar servidores para o espaço de trabalho. Separação de funções entre gerenciamento de equipe e uso de ferramentas.

Camada 3 — Infraestrutura Hospedada

O que é

Servidores MCP executando em contêineres Docker isolados em infraestrutura central, gerenciados pelo Orquestrador do MCPNest. Desenvolvedores implantam servidores de um catálogo através do painel de controle do espaço de trabalho. O cliente de IA se conecta ao Gateway, que faz proxy para o contêiner hospedado.

Que problema resolve

Executar servidores MCP localmente significa sem isolamento, sem gerenciamento central de credenciais, sem infraestrutura compartilhada e sem visibilidade sobre o que está realmente em execução. Quando o laptop de um desenvolvedor é perdido ou roubado, todas as credenciais em cada arquivo de configuração local estão expostas. Quando um desenvolvedor deixa a empresa, não há um processo de desligamento limpo.

Recursos

12 servidores verificados disponíveis para implantação com um clique
Sistema de arquivos, GitHub, PostgreSQL, Notion, Context7, Slack, SQLite, Brave Search, Puppeteer, Pensamento Sequencial, Tudo. Todos pré-validados e executando na imagem do MCPNest Bridge.

Isolamento de contêiner
Cada contêiner é executado com: cap_drop ALL (zero capacidades do Linux), flag no-novo-privilégios, limites de recursos de CPU e memória aplicados, rede Docker dedicada por espaço de trabalho.

Gerenciamento de credenciais
Servidores que requerem credenciais — tokens de acesso pessoal do GitHub, strings de conexão de banco de dados, tokens de bot do Slack, chaves de API — solicitam-nas através de um modal antes da implantação. Credenciais são criptografadas e nunca registradas. Desenvolvedores nunca as veem ou armazenam localmente.

Console de implantação em tempo real
Um modal de terminal transmite logs do contêiner durante a inicialização. O sistema detecta automaticamente o estado EXECUTANDO + SAUDÁVEL e fecha automaticamente. Nenhuma atualização manual necessária.

Visualizador de logs por instância
Cada instância em execução tem um botão de Logs que mostra as últimas 50 linhas de saída do contêiner. Depuração sem acesso SSH.

Encerrar com limpeza
Parar um servidor remove o contêiner e limpa o registro do banco de dados. Sem contêineres órfãos.

MCP Bridge
Um adaptador stdio-para-HTTP que envolve qualquer servidor MCP baseado em npx em um endpoint HTTP compatível com o Gateway. Permite a hospedagem de qualquer servidor MCP sem modificar seu código-fonte.

Segurança e Conformidade

Infraestrutura
Toda a infraestrutura é baseada na UE. Supabase (Frankfurt) para o banco de dados. Hetzner (Nuremberg) para o orquestrador e contêineres hospedados. Rede de borda Vercel para a camada de aplicação.

Segurança do token
Tokens Bearer são armazenados como hashes SHA-256. Comparação segura em tempo em cada solicitação. Tokens por membro permitem trilhas de auditoria individuais e revogação instantânea.

Manipulação de dados
Nenhuma entrada ou saída de chamadas de ferramentas é armazenada. Apenas metadados são registrados (quem, quando, qual ferramenta, qual status). Seguro pelo GDPR por design.

Segurança do contêiner
cap_drop ALL remove todas as capacidades do Linux dos contêineres. no-novo-privilégios impede a escalada de privilégios. Limites de recursos evitam processos barulhentos e descontrolados. Rede Docker dedicada por espaço de trabalho.