A pergunta parece daquelas que têm uma resposta por empresa, e não tem. Em 2026 a linha divisória passa entre superfícies, não entre fabricantes: o aplicativo de desktop do ChatGPT consegue iniciar um servidor MCP na sua máquina, o ChatGPT numa aba do navegador não consegue. O Claude Code e o Claude Desktop conseguem ambos. Todos os editores de código com cliente MCP — Cursor, VS Code, Zed, Devin Desktop — conseguem. Tudo o que corre na nuvem de outra pessoa, por definição, não consegue.
Essa distinção pesa mais do que parece. Um servidor local é um programa que o seu cliente inicia e com o qual fala por entrada e saída padrão; nenhuma porta fica aberta, nenhuma credencial é emitida e os seus dados nunca saem da máquina a caminho das ferramentas do assistente. Um servidor remoto é um URL, o que significa um operador, um token e um caminho de rede. Escolher um cliente é, portanto, em parte uma escolha sobre onde os seus dados têm de estar antes de um assistente os poder usar.
Este é um levantamento de quem suporta o quê, verificado na documentação de cada fabricante em 15 de agosto de 2026. Se o protocolo em si for novidade, o que é um servidor MCP cobre o vocabulário; se já escolheu um cliente e só precisa do caminho de configuração, configuração de MCP no VS Code, Zed e Devin Desktop é a versão arquivo a arquivo.
| Cliente | stdio local | Remoto | Como pergunta |
|---|---|---|---|
| Claude Code | Sim | HTTP, SSE, WebSocket | Pergunta; servidores de âmbito de projeto precisam de aprovação prévia |
| Claude Desktop | Sim | Sim | Aprovação explícita antes de cada ação |
| Aplicativo de desktop do ChatGPT | Sim | Sim | Quatro modos de aprovação, partilhados com o Codex |
| Codex CLI / extensão de IDE | Sim | Sim | default_tools_approval_mode |
| ChatGPT na web | Não | Sim, apenas HTTPS | Ao nível do conector, dependente do plano |
| Cursor | Sim | SSE, Streamable HTTP | Pergunta por padrão; os Run Modes permitem listas de permissões |
| VS Code | Sim | HTTP | Confiar no servidor uma vez, depois a cada invocação |
| Zed | Sim | Sim | Pergunta antes de qualquer ação de ferramenta |
| Devin Desktop | Sim | Streamable HTTP, SSE | Pergunta por padrão; regras por ferramenta |
Uma linha desta tabela é a razão de ser deste artigo.
Procure por esta pergunta e vai encontrar afirmações confiantes nos dois sentidos, muitas vezes em páginas atualizadas este ano. Ambas foram verdade em algum momento, e é por isso que persistem.
O estado atual, segundo a documentação da própria OpenAI: «O aplicativo de
desktop do ChatGPT, o Codex CLI e a extensão de IDE suportam servidores MCP e
partilham a configuração MCP do mesmo host Codex.» Essa configuração partilhada
vive em ~/.codex/config.toml, ou num .codex/config.toml de âmbito de projeto
para projetos confiáveis, e suporta explicitamente «servidores STDIO: servidores
que correm como um processo local (iniciado por um comando)».
Ou seja, o aplicativo de desktop é um cliente MCP local. Configure um servidor uma vez e o CLI, a extensão do editor e o aplicativo de desktop passam todos a vê-lo — não é preciso configurar três vezes.
O ChatGPT na web é um produto diferente com uma resposta diferente. Ali um conector personalizado é um servidor MCP remoto alcançado por HTTPS com SSE ou Streamable HTTP: cola-se um URL, não se aponta para um comando. O ChatGPT corre na nuvem da OpenAI, por isso só alcança servidores expostos à internet, e ter um local significa pôr um túnel à frente dele. Os conectores personalizados também dependem do plano — disponíveis em Plus, Pro, Business, Enterprise e Edu, não em Free nem Go.
Nenhuma das duas metades da resposta que circula está errada. São respostas a perguntas diferentes, e a pergunta que vale a pena fazer é em frente a qual ChatGPT se está sentado.
O Claude Code aceita servidores stdio com claude mcp add --transport stdio e
remotos por HTTP, SSE — descontinuado em favor do HTTP — e WebSocket. A
configuração tem três âmbitos: local, de projeto (.mcp.json, versionado) e de
usuário (~/.claude.json). Um .mcp.json versionado não se liga em silêncio:
os servidores que vêm dele ficam em «Pending approval» até que se execute o
Claude interativamente num espaço de trabalho confiável e se aprovem, o que é um
padrão sensato para um arquivo que chega com um git clone.
O Claude Desktop lê o claude_desktop_config.json — no macOS em
~/Library/Application Support/Claude/, no Windows em %APPDATA%\Claude\ — e
inicia cada servidor configurado quando o aplicativo arranca. O modelo
documentado é a aprovação por ação: «Todas as ações exigem a sua aprovação
explícita antes da execução, garantindo que mantém o controlo total sobre aquilo
a que o Claude pode aceder e que pode modificar.» As extensões instaladas a
partir de Settings → Extensions são a versão empacotada da mesma coisa, e é por
isso que as instalações num clique e o JSON escrito à mão acabam no mesmo sítio.
O Cursor documenta três transportes — stdio, SSE e Streamable HTTP — com
configuração de projeto em .cursor/mcp.json e global em ~/.cursor/mcp.json.
Quanto ao consentimento é explícito: «Por padrão, o Cursor pede aprovação antes
de usar ferramentas MCP.» A automação é opcional, através dos Run Modes, onde as
ferramentas MCP em lista de permissões correm imediatamente no modo Auto-review
e tudo o resto passa por um classificador.
O VS Code suporta servidores HTTP remotos e servidores stdio locais,
configurados ao nível do espaço de trabalho em .vscode/mcp.json ou ao nível do
usuário através do comando MCP: Open User Configuration. Acrescenta um passo
que os outros não sublinham: antes de um servidor arrancar pela primeira vez é
preciso confirmar que se confia nele, com a opção de rever a configuração a
partir da caixa de diálogo. A confiança é uma propriedade do servidor, não de
cada chamada.
O Zed configura servidores MCP em Settings → AI → MCP Servers, aceitando uma
forma command/args/env para os servidores locais e uma forma
url/headers para os remotos. As permissões são as mais granulares do grupo:
agent.tool_permissions.default pede aprovação antes de executar qualquer ação
de ferramenta, incluindo chamadas a ferramentas MCP, e podem escrever-se regras
individuais contra mcp:<server>:<tool_name> — dá para pré-aprovar a leitura e
manter uma pergunta em tudo o que escreve.
O Devin Desktop é aquele cujo nome mudou. A Cognition renomeou o Windsurf para Devin Desktop em 2 de junho de 2026 através de uma atualização over-the-air; planos, extensões, atalhos de teclado e ligações MCP existentes transitaram sem ação do usuário, e o agente local Cascade foi substituído pelo Devin Local, com o Cascade descontinuado em 1 de julho de 2026. O suporte a MCP sobreviveu intacto: os servidores «podem ser configurados de duas formas: como um comando local (transporte stdio) ou como um servidor remoto (transporte HTTP)», com arquivos de usuário, de projeto e de substituição local ignorados pelo git, e as ferramentas MCP pedem aprovação por padrão. Se estiver a seguir um tutorial antigo do Windsurf, os conselhos sobre o protocolo continuam válidos e só mudaram o nome do produto e os caminhos dos arquivos.
Todos os clientes desta comparação perguntam por padrão. Essa é a boa notícia, e é também onde se esconde o detalhe útil, porque perguntar a cada chamada é inutilizável e não perguntar em nenhuma é inseguro. A questão de desenho interessante é o que um cliente faz entre esses dois extremos.
Há três mecanismos em uso, e a maioria dos clientes combina-os:
.mcp.json funcionam assim.writes do Codex «pergunta para ferramentas
que não estão marcadas como só de leitura» — procurar é silencioso, alterar
não é.mcp:<server>:<tool_name> do Zed e o
tools.<tool>.approval_mode do Codex deixam decidir ferramenta a ferramenta,
que é o único mecanismo suficientemente preciso quando um mesmo servidor
oferece os dois tipos.A assimetria é a parte que vale a pena entender, porque depende de o servidor ser honesto sobre quais das suas ferramentas alteram coisas. Um servidor que declara tudo como só de leitura anula todas as políticas do cliente acima dele. Quando se liga um servidor que não se escreveu, essa declaração faz parte daquilo em que se está a confiar — o mesmo juízo tratado em o que torna seguro o acesso de escrita por MCP.
Os servidores locais não são automaticamente a melhor escolha, e uma comparação que concluísse o contrário estaria a vender alguma coisa.
Um servidor remoto é a forma certa quando os dados, para começar, não estão na sua máquina — um rastreador de issues hospedado, uma API de pagamentos, um painel de monitorização. Pôr um processo local à frente de um serviço na nuvem acrescenta um salto e não resolve nada. Os servidores remotos também funcionam a partir de um navegador, de um telefone e do computador de um colega sem que ninguém instale nada, e um operador corrige um erro para toda a gente de uma só vez. Se a restrição da sua equipa é «tem de funcionar para cinquenta pessoas sem direitos de administrador», só remoto não é uma limitação, é o requisito.
Os servidores locais ganham num conjunto de casos mais estreito mas mais nítido: os dados já estão na máquina, são sensíveis ao ponto de se preferir que não viajem, ou não existe versão hospedada a que ligar. As gravações das suas próprias reuniões são as três coisas ao mesmo tempo.
O servidor MCP do Speak-Y é um processo stdio local, e é isso que o coloca na coluna da esquerda da tabela para todos os clientes que a têm. O seu assistente procura gravações e lê transcrições, resumos e itens de ação diretamente da biblioteca na sua máquina, sem retransmissão pela nuvem no caminho e sem nada para tunelar.
A separação entre leitura e escrita alinha-se com os mecanismos de cliente
descritos acima. Ler não exige mais nada em execução. Os comandos que alteram
alguma coisa — etiquetas, títulos, nomes de participantes, retranscrição,
partilha num canal de equipa — passam pelo aplicativo Speak-Y em execução, são
declarados ao seu cliente MCP como alteradores de dados, para que ele pergunte
antes de os executar a menos que conceda permissão permanente, e ficam
registados no aplicativo, onde também podem ser desligados. Se preferir que um
assistente só possa ler, iniciar o servidor com --read-only na configuração
desse cliente faz com que os comandos que alteram nunca lhe sejam sequer
publicados.
A instalação é feita num clique a partir de Configurações → Integrações, e é gratuita em todos os planos, incluindo o Free — o que não é a norma entre os tomadores de notas de reuniões, onde o MCP costuma ficar atrás de um nível pago na nuvem.
Para o ChatGPT em concreto, a consequência prática de tudo o que ficou dito é que o aplicativo de desktop é a superfície a usar. Partilha a configuração do Codex, por isso o servidor que se adiciona para o Codex CLI já lá está. O guia ChatGPT Desktop e os seus dados pessoais percorre essa configuração e, para pesar as duas formas uma contra a outra de modo mais geral, MCP local versus na nuvem trata do que cada uma expõe e a quem.
Depende de qual ChatGPT se trata. O aplicativo de desktop consegue: partilha a configuração MCP com o Codex CLI e a extensão de IDE através do mesmo host Codex, e essa configuração suporta servidores STDIO iniciados por um comando na sua máquina. O ChatGPT na web não consegue — um conector web é um servidor MCP remoto alcançado por HTTPS, por isso um servidor local tem primeiro de ser exposto através de um túnel. Verificado em 15 de agosto de 2026.
Um servidor stdio local é um programa que o cliente inicia na sua máquina e com o qual fala por entrada e saída padrão. Nada fica à escuta numa porta de rede e nenhum dado sai do computador para o alcançar. Um servidor remoto é um endpoint HTTPS ao qual o cliente se liga pela internet, normalmente autenticado com um token, e os seus pedidos viajam até quem quer que o opere.
Todos os clientes principais perguntam por padrão, mas a granularidade difere. O Cursor pede aprovação antes de usar ferramentas MCP por padrão e executa de imediato, no modo Auto-review, as ferramentas que estão em lista de permissões; o Zed pergunta antes de qualquer ação de ferramenta e aceita regras por ferramenta como mcp:server:tool_name; o Codex tem quatro modos de aprovação, dos quais writes só pergunta para ferramentas que não estejam marcadas como só de leitura. Os servidores também podem marcar ferramentas individuais como só de leitura, para que o cliente saiba quais são seguras.
Não. A Cognition renomeou o Windsurf para Devin Desktop em 2 de junho de 2026 através de uma atualização over-the-air, e o agente local antes chamado Cascade foi substituído pelo Devin Local, com o Cascade descontinuado em 1 de julho de 2026. Planos, extensões, atalhos de teclado e ligações MCP existentes transitaram sem qualquer ação do usuário.
Todos os desta comparação que conseguem executar um servidor local, porque o servidor MCP do Speak-Y é um processo local e não um endpoint hospedado: Claude Code, Claude Desktop, o aplicativo de desktop do ChatGPT e o Codex, Cursor, VS Code, Zed e Devin Desktop. É gratuito em todos os planos, incluindo o Free, e instala-se num clique a partir de Configurações → Integrações.