Servidores MCP locais vs remotos: qual você realmente deseja

Existem dois tipos de servidor MCP, eles resolvem problemas diferentes, e quase nada te diz qual você está construindo até que você esteja profundo o suficiente para já ter feito a escolha errada.

Eu descobri isso a partir de um formulário de submissão. Mais sobre isso abaixo, porque acaba sendo o sinal mais claro em todo o ecossistema e está enterrado em uma nota de rodapé.

As duas formas

Local (stdio). O servidor roda como um processo na própria máquina do usuário. O cliente — Claude Desktop, Cursor, seja o que for — o inicia e se comunica com ele através de stdin/stdout. É um pacote que o usuário instala.

Remoto (Streamable HTTP). O servidor é um serviço que você hospeda. O cliente se conecta a uma URL com um token em um cabeçalho de Autorização. Nada é instalado localmente.

Essa é toda a distinção, e ela determina todo o resto.

O que realmente difere

Quem executa o código. Local: o usuário, em seu hardware. Remoto: você, em seu hardware. Essa é a verdadeira decisão. Tudo abaixo segue a partir disso.

Onde os segredos vivem. Servidores locais leem credenciais do próprio ambiente do usuário — seu perfil de shell, seu arquivo de configuração. Você nunca os vê. Servidores remotos exigem que o usuário mantenha um token que você emitiu, o que significa que você possui todo o ciclo de vida da credencial: emissão, escopo, rotação, revogação.

O que o servidor pode acessar. Um servidor local pode ler o sistema de arquivos do usuário, acessar localhost, conversar com seu daemon Docker. Um servidor remoto não pode ver nada disso e não deve querer.

Caminho de atualização. Remoto: você faz o deploy, todos estão na nova versão imediatamente. Local: os usuários rodam qualquer versão que instalaram, possivelmente para sempre.

Superfície de falha. Um servidor local falha em uma máquina. Um servidor remoto falha para todos ao mesmo tempo. Escolha seu veneno.

Escolhendo

Local se você precisa do sistema de arquivos do usuário, processos locais, um banco de dados local ou hardware. Ou se os dados não devem sair da máquina deles.

Remoto se o servidor é a frente de um serviço que você já executa. Se o trabalho do seu servidor MCP é chamar sua própria API, fazer os usuários instalarem um processo que faz proxy para seu endpoint HTTP é pura sobrecarga — você enviou um wrapper local em torno de uma chamada remota, e agora mantém ambos.

Regra geral: se os dados estão na sua infraestrutura, o servidor deve ser remoto. Se estão na máquina do usuário, local.

A parte que me custou uma hora

Anthropic mantém um diretório de servidores MCP, e existem dois formulários de submissão separados — um para local, um para remoto. O local é estruturado em torno de Extensões de Desktop, e seus requisitos declarados são:

• Disponível publicamente no GitHub
• Licenciado sob MIT
• Construído com Node.js
• Um manifest.json válido com o campo author apontando para seu perfil do GitHub
• Um arquivo .mcpb, como um upload obrigatório

A última é a dica. Um .mcpb é uma extensão local empacotada que o Claude Desktop instala e executa. Se seu servidor é remoto, não há pacote a ser produzido — e o campo de arquivo obrigatório é onde você descobre que está na página errada.

O link para o formulário remoto está em uma única linha perto do topo do formulário local, fácil de passar direto.

Então: leia os requisitos de transporte antes de preencher qualquer coisa. Se um formulário pede um .mcpb, ou menciona Node.js como um requisito obrigatório, ele quer um servidor local. Uma submissão rejeitada é um resultado pior do que um mais lento e correto.

Autenticação, se você for remoto

Remoto significa que você possui as credenciais, então algumas coisas deixam de ser opcionais.

Escopo os tokens de forma restrita. Um token que só pode ler o contexto para uma única tarefa é um problema muito menor quando vaza do que um que atua como toda a conta do usuário.

Faça a expiração o padrão, não a revogação. "Revogável" coloca o ônus em alguém lembrar. Expirar significa que a negligência é inofensiva. Projete para a pessoa que esquece, porque essa pessoa é você.

Nunca deixe um token cair em um arquivo comitado. Referencie uma variável de ambiente na configuração e exporte o valor real do perfil do shell. Uma vez que uma credencial chega a um branch remoto, deletar a linha não faz nada — o valor está no histórico, e a rotação é a única solução real.

Onde eu cheguei

Eu trabalho na Wagglet, que é remoto. O servidor é a frente de um quadro de tarefas compartilhado, então os dados são nossos em vez de do usuário. Ir para local significaria enviar um processo cujo único trabalho era fazer proxy de chamadas HTTP para nossa própria API, além de um pacote para empacotá-lo, além de um problema de desvio de versão — em troca de nada.

Os docs cobrem o modelo de conexão e credencial se você quiser um exemplo prático do lado remoto.

Divulgação: Eu trabalho na Wagglet. A decisão local/remota acima é a parte que vale a pena considerar, independentemente do que você está construindo.

Versão curta

Dados na sua infraestrutura, vá remoto. Dados na máquina do usuário, vá local.

E antes de preencher qualquer formulário de diretório, verifique se ele quer um .mcpb. Essa é a maneira mais rápida de saber em qual porta você está parado.