Servidores MCP locais rodam como um processo na sua própria máquina, via stdio, enquanto servidores MCP remotos ficam atrás de um endpoint HTTPS que qualquer pessoa da sua equipe pode acessar. Este artigo compara configuração, segurança, latência, custo e escala para você escolher o certo para seu agente de IA.
O arquivo de configuração do seu agente de IA pede uma coisa antes de qualquer outra: um command ou um url. Essa única linha decide onde suas ferramentas rodam, quem pode acessá-las, o que acontece quando seu notebook entra em suspensão e quem paga pela máquina por trás delas. Escolher errado e você acaba cuidando de um monte de processos em segundo plano ou entregando a um servidor de terceiros um caminho até seus arquivos.
A escolha entre um servidor MCP local e um servidor MCP remoto parece técnica, mas é, na verdade, uma questão de confiança, distância e propriedade. Este artigo mostra como cada um funciona, onde cada um se sai melhor, onde cada um dá problemas, e termina com um checklist curto para você decidir em cinco minutos, em vez de cinco reuniões.
💡 Resposta curta: Use um servidor local quando a ferramenta mexer com arquivos, shells ou dados privados na sua própria máquina. Use um servidor remoto quando várias pessoas, dispositivos ou agentes precisarem da mesma ferramenta sem instalar nada.
O Model Context Protocol, ou MCP, é um padrão aberto que permite a um aplicativo de IA chamar ferramentas externas por meio de uma interface única e consistente. Em vez de escrever um plugin personalizado para cada modelo e cada aplicativo, um desenvolvedor escreve um único servidor. Qualquer cliente compatível pode então listar as ferramentas dele, chamá-las e ler os resultados.
Três papéis estão envolvidos. O host é o aplicativo que você usa, como um editor de código ou um assistente de chat. Dentro dele existe um cliente MCP, que mantém uma conexão um para um com um servidor. O servidor expõe ferramentas (ações que o modelo pode solicitar), recursos (dados que o modelo pode ler) e prompts (modelos reutilizáveis). As mensagens trafegam como JSON-RPC 2.0, então o tráfego é texto estruturado simples, não importa como ele vá do ponto A ao ponto B.
Essa parte de "como ele vai do A ao B" é todo o debate entre local e remoto.
A especificação define dois transportes padrão:
Servidores locais quase sempre usam stdio. Servidores remotos usam Streamable HTTP, que substituiu o antigo transporte HTTP mais SSE. As ferramentas em si podem ser idênticas nos dois casos. Só a camada de conexão muda, e é ela que define seu modelo de segurança, sua latência e a conta de manutenção.
Com stdio, seu cliente lê um arquivo de configuração, executa o comando que você escreveu e mantém esse processo ativo durante toda a sessão. As requisições entram por stdin, as respostas saem por stdout, e os logs devem ir para stderr. Se você escrever um print perdido no stdout, corrompe o fluxo do protocolo, um erro clássico do primeiro dia.
{
"mcpServers": {
"project-files": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects"]
}
}
}
Não há porta para abrir, nenhuma regra de firewall e nenhuma tela de login. O processo herda suas permissões de usuário e suas variáveis de ambiente, e é exatamente isso que o torna tão conveniente e tão merecedor de cuidado.
Cada colega de equipe precisa instalar o runtime, fixar a versão certa e copiar a configuração. Atualize o servidor e dez notebooks saem de sincronia. Cada aplicativo cliente também inicia seu próprio processo, então três editores significam três cópias rodando lado a lado. E um servidor local morre junto com sua sessão, então nada consegue chamá-lo enquanto seu notebook estiver fechado.
O suporte é o custo escondido. Quando uma ferramenta quebra na máquina de uma pessoa, você passa a depurar uma versão do Node, um problema de PATH ou um pacote Python ausente, em vez da própria ferramenta.
Um servidor remoto fica em uma URL como https://tools.example.com/mcp. O cliente envia mensagens JSON-RPC como requisições HTTP POST para esse endpoint único. O servidor responde com uma resposta JSON normal ou abre um stream de Server-Sent Events quando tem atualizações de progresso ou várias mensagens para enviar. Um cabeçalho de sessão permite que o servidor mantenha o estado entre as chamadas.
Adicionar um leva um único comando na maioria dos clientes:
claude mcp add --transport http notes https://tools.example.com/mcp
Como o endpoint é acessível pela internet, a autenticação passa de "quem está logado neste notebook" para "quem tem um token válido". O fluxo de autorização da especificação é baseado em OAuth, então o usuário faz login pelo navegador e o cliente armazena um token com escopo definido e que pode ser revogado.
O conector próprio da PicassoIA é um bom exemplo real. Trata-se de um servidor MCP remoto que expõe ferramentas para geração de imagens, edição de imagens e geração de vídeo. Os jobs são assíncronos: uma chamada de geração retorna imediatamente um ID de predição, e o cliente consulta o resultado repetidamente. Um limite compartilhado de cinco predições simultâneas por conta se aplica a todas as conexões, o que só é possível porque o estado fica no servidor. Seu notebook nunca precisa de uma GPU, de um download de modelo ou de um ambiente Python.
Agora você depende do tempo de atividade de outra pessoa e da sua própria conexão. As idas e voltas da rede somam latência a cada chamada de ferramenta, e um handshake demorado pode fazer um agente parecer lento. Tudo que o servidor precisar da sua máquina, como um arquivo local, simplesmente não estará lá. Hospedar significa certificados TLS, monitoramento, limites de requisições e alguém de plantão. E um endpoint público é um alvo, então precisa de autenticação adequada desde o primeiro dia.
| Fator | Local (stdio) | Remoto (Streamable HTTP) |
|---|---|---|
| Onde roda | Na sua máquina, como processo filho | Um servidor hospedado atrás de uma URL |
| Configuração por usuário | Instalar um runtime e editar a configuração | Colar uma URL e fazer login |
| Atualizações | Manuais em cada máquina | Implantado uma vez |
| Precisa de rede | Não | Sim |
| Acesso a arquivos locais | Direto | Nenhum, a menos que você os envie |
| Modelo de autenticação | Usuário do sistema e variáveis de ambiente | OAuth ou tokens bearer |
| Suporte a vários usuários | Fraco | Feito para isso |
| Sobrecarga de latência | Insignificante | Uma ida e volta de rede por chamada |
| Custo de operação | Seu próprio hardware | Hospedagem mais manutenção |
| Falha típica | O processo trava ou não inicia | Queda, timeout ou token expirado |
Nenhuma das opções é automaticamente mais segura. Um servidor local roda com as suas permissões, então um pacote malicioso ou com bugs pode ler seus arquivos e sua configuração SSH, e qualquer coisa trazida por meio de npx ou uvx é código que você provavelmente não auditou. Um servidor remoto mantém esse código fora da sua máquina, mas agora você confia no operador dele com tudo que a ferramenta recebe, e cada requisição trafega pela rede.
💡 Regra prática: Trate qualquer servidor MCP como uma extensão de navegador. Verifique quem o escreveu, fixe a versão e conceda as permissões mais restritas que ainda o deixem funcionar.
Alguns pontos específicos que vale a pena fazer:
127.0.0.1 e valide o cabeçalho Origin, senão uma página da web no seu navegador pode alcançá-los via DNS rebinding.A camada stdio custa quase nada. Uma chamada remota adiciona pelo menos uma ida e volta de rede, que pode ser de alguns milissegundos dentro de uma mesma região e de algumas centenas entre continentes, além de TLS e de quaisquer verificações de autenticação. Na prática, o trabalho da própria ferramenta, como uma consulta a banco de dados, uma chamada de API ou uma renderização de imagem, eclipsa o transporte. A latência remota só pesa para agentes que disparam dezenas de chamadas pequenas em sequência.
A confiabilidade funciona ao contrário. Um processo local falha de forma ruidosa e visível, normalmente na inicialização. Um serviço remoto pode falhar em silêncio: um token expirado, um limite de requisições, uma queda regional. Planeje novas tentativas e escreva mensagens de erro com as quais um modelo consiga agir.
Defina timeouts explícitos dos dois lados. Um cliente que espera para sempre por uma chamada remota travada congela a conversa inteira, enquanto um servidor que desiste cedo demais corta trabalhos longos legítimos, como a renderização de vídeo. Informe o progresso de qualquer coisa que dure mais do que alguns segundos.
Local não custa nada para hospedar, mas custa tempo para dar suporte, e cada chamado de "na minha máquina funciona" cai em você. Remoto custa dinheiro e trabalho operacional, mas economiza tempo de suporte quando uma equipe está envolvida. O ponto de equilíbrio fica por volta do momento em que mais de algumas pessoas precisam do mesmo servidor.
Uma forma simples de estimar: conte as pessoas, multiplique pelos minutos que cada uma gasta com configuração e solução de problemas por mês, e compare esse número com um plano pequeno de hospedagem. Para duas pessoas, a rota local geralmente vence. Para vinte, quase nunca.
Escolha local quando suas ferramentas mexerem nas suas próprias coisas: um repositório de código, uma pasta de anotações, um banco de dados local, um navegador que você automatiza. Local também é o lugar melhor para protótipos, porque você pode editar o servidor e reiniciá-lo em segundos, sem um pipeline de deploy.
Escolha remoto quando a ferramenta pertencer à equipe: sistemas de chamados, bases de conhecimento internas, ativos de design compartilhados, dados de faturamento. Autenticação centralizada e logs de auditoria importam mais do que economizar alguns milissegundos. Remoto também é a única escolha quando o cliente não consegue iniciar processos, o que acontece com a maioria dos assistentes web e apps mobile.
Implante em etapas. Comece com um servidor remoto somente leitura para que as pessoas possam testar sem risco, adicione ferramentas de escrita quando o log de auditoria estiver saudável, e mantenha um botão de desligamento de emergência que revogue os tokens em um passo. Equipes que pulam essa ordem tendem a descobrir seus erros por meio de uma mensagem irritada, em vez de um painel.
Responda na ordem e pare na primeira resposta "sim":
Projetos reais raramente escolhem só uma opção. Estes padrões aparecem repetidamente:
Trabalhar de um café com uma conexão instável é onde o modelo híbrido compensa. As ferramentas de arquivo continuam rodando localmente enquanto as ferramentas hospedadas tentam de novo em segundo plano, e nada sensível sai da sua máquina a menos que você decida que deve sair.
/Users/me/notes não faz sentido em uma máquina na nuvem. Se os dados estão no seu notebook, o servidor pertence ao seu notebook.Qualquer que seja o transporte escolhido, o resultado é o mesmo: um assistente de IA que faz trabalho real por você, em vez de apenas falar sobre ele. Uma conexão remota é a forma mais rápida de sentir isso, porque não há nada para instalar e nada para manter rodando.
Experimente com imagens primeiro. O PicassoIA Image transforma um prompt em linguagem simples em uma imagem pronta em segundos, com sete proporções, um seed que pode ser travado e sem limite por imagem. Escreva um prompt, gere algumas variações e depois mude um único detalhe, como a lente, a luz ou o ângulo da câmera, e veja o que muda. Esse pequeno ciclo de prompt, resultado e ajuste é o hábito que torna todas as ferramentas seguintes mais fáceis de usar, sejam elas MCP ou não.
Se você mesmo escreve ou revisa código de servidor, um bom modelo de programação ajuda. Claude Sonnet 5, GPT 5.6 Sol, Gemini 3.5 Flash e Kimi K2.6 estão todos disponíveis no Picasso IA, então você pode comparar como cada um lida com o mesmo esquema de ferramenta.
Pronto para experimentar? Abra o Picasso IA, escolha um modelo na lista completa de modelos e gere sua primeira imagem hoje mesmo.
Escolha seu idioma
