As palavras local e nuvem são usadas a respeito de servidores MCP como se resolvessem a questão da privacidade. Elas não resolvem. Respondem com precisão a uma única pergunta — onde o processo do servidor roda — e deixam intacta aquela com que a maioria das pessoas de fato se importa: quem acaba conseguindo ler os seus dados.
Em resumo: um servidor MCP local mantém os seus dados fora da infraestrutura do fornecedor; ele não os mantém fora da conversa. Tudo o que o seu assistente ler por meio de qualquer servidor MCP, local ou na nuvem, é enviado ao modelo com que você está conversando. Local muda quem armazena os seus dados e quem consegue alcançá-los. Não muda o que o modelo vê.
Este artigo separa essas duas coisas. Se o protocolo em si for novo para você, o que é um servidor MCP cobre o básico primeiro.
A especificação MCP, revisão 2026-07-28, define exatamente dois transportes padrão, e eles correspondem com clareza às duas palavras.
stdio, o local. O cliente inicia o servidor MCP como subprocesso e os dois conversam pela entrada e pela saída padrão desse processo, uma mensagem JSON-RPC por linha. Não há conexão de rede nem porta. Quando o cliente encerra, ele fecha o fluxo de entrada do servidor e o processo se desliga. É isso que «roda na sua máquina» significa em termos concretos.
Streamable HTTP, o da nuvem. O servidor é um processo independente que expõe
um único ponto de acesso HTTP, e cada mensagem é um POST HTTP para ele. O
cliente o alcança pela rede em uma URL do tipo https://mcp.example.com/mcp. É
o transporte por trás de todo botão de «conectar a sua conta».
A distinção é uma escolha de implantação, não uma diferença de capacidade. A especificação é explícita: a semântica do protocolo é idêntica em todos os transportes; um transporte define como as mensagens são delimitadas e entregues, não o que elas significam. Uma ferramenta que lê as suas transcrições de reunião faz o mesmo trabalho dos dois jeitos.
Esta é a pergunta que as duas palavras costumam substituir, e ela tem mais de duas respostas. Quatro partes podem, em tese, ler o que passa por uma conexão MCP.
| Quem | Servidor local (stdio) | Servidor na nuvem (HTTPS) |
|---|---|---|
| O fornecedor do servidor MCP | Não recebe os dados | Guarda-os e atende cada requisição |
| O provedor do seu modelo | Vê tudo o que o assistente lê | Vê tudo o que o assistente lê |
| O seu aplicativo de IA | Lê os dados localmente para montar o prompt | O mesmo |
| Quem tiver o token | Não existe token para roubar | Alcança os mesmos dados até ser revogado |
A linha do meio é a que surpreende as pessoas, e ela é igual nas duas colunas. Um servidor MCP não dá ao modelo um canal privado. Ele recupera texto e o entrega ao cliente, que o coloca no prompt. A partir daí os dados já saíram da sua máquina, não importa onde o servidor tenha rodado.
A primeira e a última linha são onde o local ganha de verdade. Com stdio não há conta, não há cópia guardada no disco de outra pessoa e não há credencial que possa ser roubada ou vazada em um incidente — porque não há nada a autorizar.
Existem aqui três formatos, não dois, e os fornecedores raramente isolam o do meio.
Servidor na nuvem, dados na nuvem. O fornecedor hospeda o servidor, você o autoriza com OAuth no navegador e o seu cliente faz uma chamada HTTPS sempre que precisa de algo. É o formato natural quando os seus dados já vivem na nuvem daquele fornecedor.
Processo local, dados na nuvem. O fornecedor entrega um servidor que você
mesmo executa: um comando npx, uvx ou docker iniciado pelo seu cliente de
IA, guardando uma chave de API. Nada disso torna os dados locais. O processo
roda no seu notebook e depois chama a API do fornecedor pela rede a cada
requisição. É este o caso que vale descartar quando alguém diz que o servidor
MCP dele é local.
Processo local, dados locais. Os dados já estão na máquina, então o servidor os lê sem nenhuma chamada de rede. É o único formato em que «local» descreve os dados, e não apenas o processo.
O que entrega é a credencial, não o comando. Um login pelo navegador significa que os dados são do fornecedor e você autoriza o acesso. Uma chave de API colada num arquivo de configuração significa que um processo local chama a API deles em seu nome. Nenhum dos dois casos é dado local.
Quando você passa por uma tela de OAuth para um servidor MCP na nuvem, está emitindo uma credencial contra a sua conta, e vale saber o que essa credencial permite fazer.
A especificação MCP apoia isso no OAuth 2.1. Os clientes devem enviar o
parâmetro resource da
RFC 8707 para que o token fique
vinculado a um servidor específico, e os servidores devem validar que um token
foi emitido para eles e não podem aceitar nem repassar nada além disso. Essa
mecânica existe para impedir que um token emitido para um serviço seja reusado
contra outro.
Três consequências práticas:
Nada disso se aplica ao stdio. A especificação de autorização é explícita ao dizer que cobre os transportes baseados em HTTP e que implementações que usam stdio não devem segui-la, buscando as credenciais no ambiente.
Local não é sinônimo de seguro, e a versão honesta desse argumento precisa dizer o que se troca em troca.
Normalmente não há camada de permissões. Como a especificação de autorização não se aplica, um servidor stdio costuma não ter noção de usuários nem de scopes. Em geral, qualquer coisa executada com a sua conta de usuário consegue iniciá-lo e chamar as ferramentas dele. Numa máquina compartilhada ou gerenciada, isso pesa.
Um servidor local escutando numa porta é outro bicho. Alguns servidores
descritos como locais na verdade escutam em HTTP. A especificação trata o caso
diretamente: os servidores devem validar o cabeçalho Origin para prevenir
ataques de DNS rebinding e, em uso local, devem se ligar apenas a 127.0.0.1 em
vez de 0.0.0.0. Sem essas proteções, ela alerta, invasores poderiam usar DNS
rebinding para interagir com servidores MCP locais a partir de sites remotos.
Você herda a cadeia de suprimentos. Um servidor iniciado com npx baixa e
executa código na sua máquina com as suas permissões. O
OWASP MCP Top 10, em beta em 2026,
lista ataques à cadeia de suprimentos e adulteração de dependências
(MCP04:2025) e o envenenamento de ferramentas (MCP03:2025) entre as suas dez
categorias — riscos
que uma instalação local carrega e um ponto de acesso hospedado não. A
especificação é direta sobre o caso geral: ferramentas representam execução de
código arbitrário, e as descrições do comportamento de uma ferramenta devem ser
tratadas como não confiáveis a menos que venham de um servidor confiável.
O MCP não acrescenta um modelo de permissões aos seus dados. Ele padroniza como as ferramentas são descritas e chamadas; aquilo em que uma ferramenta pode tocar é uma decisão de quem escreveu o servidor. Duas coisas decorrem disso, independentemente do transporte:
Quatro perguntas, respondíveis na página de configuração de qualquer fornecedor em cerca de um minuto.
https:// é um servidor na nuvem. Um
comando npx, uvx ou docker é um processo na sua máquina.Dito sem rodeios, porque a escolha não é de mão única:
A nuvem perde em um único eixo, mas é o eixo de que este artigo trata: uma cópia dos seus dados fica na infraestrutura de outra pessoa, alcançável com uma credencial.
Faça duas perguntas em vez de uma. Onde o servidor roda diz quem armazena os seus dados e quem consegue alcançá-los com um token. O que o assistente lê diz o que vai para o provedor do seu modelo — e essa resposta é a mesma dos dois jeitos.
Se o formato que você quer é processo local sobre dados locais, é isso que o
servidor MCP do Speak-Y faz: ele faz parte do aplicativo de desktop, se
instala em Configurações → Integrações com um clique e lê as gravações que
já estão na sua máquina, sem conta, sem chave de API e sem cópia hospedada. A
leitura funciona com o aplicativo fechado; as ferramentas que alteram algo
passam pelo aplicativo e pedem confirmação, e a opção --read-only limita um
cliente à leitura. O servidor é gratuito em todos os planos. A documentação do
MCP cobre a instalação manual, a política de privacidade
informa o que é armazenado e onde, e se você quiser ver como outras ferramentas
de notas respondem à mesma pergunta, nós comparamos os servidores MCP
delas lado a lado.
Um servidor local é um programa que o seu cliente de IA inicia no seu próprio computador e com o qual conversa pela entrada e pela saída padrão do processo, sem rede no meio. Um na nuvem é um serviço web que o cliente alcança por HTTPS, autorizado com OAuth. A especificação MCP chama esses dois de transportes stdio e Streamable HTTP.
Não. Um servidor local mantém os seus dados fora dos servidores do fornecedor, mas tudo o que o assistente lê por meio dele é enviado ao provedor do seu modelo como parte da conversa, exatamente como se você mesmo tivesse colado o texto. Local controla o armazenamento e o acesso, não o que o modelo vê.
Ele é mais privado, mas não automaticamente mais seguro. A especificação de autorização do MCP se aplica apenas aos transportes HTTP; aos servidores stdio ela manda buscar as credenciais no ambiente, então um servidor local costuma não ter camada de permissões própria. Em geral, qualquer coisa executada com o seu usuário consegue alcançá-lo.
Olhe as instruções de instalação. Uma URL https:// e um login pelo navegador indicam a nuvem do fornecedor. Um comando como npx, uvx ou docker indica um processo na sua máquina. Um processo local que guarda uma chave de API ainda chama a API do fornecedor, então o comando sozinho não diz onde os dados moram.
O Claude Desktop executa servidores locais diretamente, instalados como extensões de desktop. O ChatGPT se conecta a pontos de acesso HTTPS remotos em modo desenvolvedor, então um servidor stdio local precisa ser exposto antes por um túnel. O mesmo servidor pode, portanto, ser local em um cliente e remoto em outro.