Um servidor MCP local e um remoto parecem idênticos depois de em funcionamento: a mesma lista de ferramentas no cliente, a mesma conversa, o mesmo resultado. A diferença está no que entregou para lá chegar. Um servidor local é um programa na sua máquina que o cliente inicia e com o qual fala por entrada e saída padrão, e o que entrega é uma linha de comando. Um servidor remoto é o endpoint HTTPS de outra pessoa, e o que entrega é uma credencial — juntamente com tudo o que ela destranca, durante todo o tempo em que a deixar viva.
Por isso a pergunta útil antes de colar um URL numa caixa de diálogo de conector não é «este servidor é de confiança», à qual ninguém consegue responder a partir de uma página de listagem. São três perguntas mais estreitas que têm respostas consultáveis: a que está limitado o token, onde ir para o retirar, e o que o catálogo onde encontrou o servidor verificou de facto. As respostas abaixo assentam na especificação MCP e na documentação dos fabricantes tal como estavam em 16 de agosto de 2026.
A revisão atual da especificação, 2026-07-28, trata os dois transportes como contextos de segurança diferentes. A autorização é opcional no MCP, e onde se aplica está explícito: as implementações que usam um transporte HTTP devem seguir a especificação OAuth, ao passo que as implementações stdio não devem segui-la de todo e devem obter as credenciais do ambiente. O HTTP+SSE, o transporte remoto antigo, está descontinuado; Streamable HTTP é o que se deve esperar.
| Local (stdio) | Remoto (Streamable HTTP) | |
|---|---|---|
| O que entrega | Um comando que o seu cliente vai executar | Um URL e, normalmente, uma concessão OAuth |
| Onde o código corre | A sua máquina, a sua conta de usuário | Infraestrutura operada por outra pessoa |
| Credenciais | Retiradas do ambiente | Token de acesso ligado a esse único servidor |
| O que «desligar» faz | Deixa de iniciar um processo | Apaga a cópia do token no cliente; a concessão pode sobreviver |
| Pior caso se o autor for hostil | Código arbitrário com os seus privilégios | Tudo o que os scopes aprovados alcançam |
Nenhuma das colunas é a segura. Um servidor local é código arbitrário a correr como você — e é precisamente por isso que a especificação exige que um cliente que ofereça configuração local num clique mostre o comando exato que vai executar, sem truncar, e obtenha aprovação explícita primeiro. Um servidor remoto não põe código na sua máquina, mas move os seus dados para um operador e deixa um caminho de acesso que sobrevive à sua atenção. Os dois falham em direções diferentes; a nossa comparação do que cada tipo consegue ver trata isso em mais detalhe.
O modelo de autorização é OAuth 2.1, e a parte que vale a pena perceber como
usuário é a ligação de audiência. Os clientes têm de implementar Resource
Indicators for OAuth 2.0 (RFC 8707): o parâmetro resource tem de ser enviado
tanto no pedido de autorização como no pedido de token, nomeando o servidor
específico a que o token se destina. Os servidores têm de validar que os tokens
foram emitidos para si, aceitar apenas tokens válidos para os seus próprios
recursos, e não devem aceitar nem encaminhar quaisquer outros. Passar o token de
um cliente para uma API a jusante — o «token passthrough» — é pura e
simplesmente proibido.
Ou seja, um token corretamente implementado não serve de nada noutro servidor. Isso fecha a repetição, a reutilização de credenciais entre serviços e uma classe de ataques de delegado confuso — e absolutamente nada sobre o próprio operador. A ligação de audiência diz onde o token funciona, não o que a empresa do outro lado faz com aquilo que as suas ferramentas vão buscar em seu nome. A isso responde a política de privacidade dela, não o protocolo.
É nos scopes que a sua exposição se decide de facto. A especificação empurra os
servidores para o menor privilégio: scopes_supported deve ser o conjunto
mínimo necessário à funcionalidade básica, com tudo o resto pedido de forma
incremental quando uma operação privilegiada é tentada pela primeira vez. Os
servidores que seguem isto pedem pouco à partida; os que não seguem mostram uma
única tela de consentimento com tudo listado. Essa tela é o último ponto em que
a decisão é sua.
Há duas superfícies de revogação, e a maioria das pessoas só usa a primeira.
No assistente. No Claude, os conectores personalizados ficam em Customize > Connectors, onde se adiciona um colando o URL do servidor; os usuários do Free estão limitados a um. É nessa mesma página que se desliga, e onde se ativam ou desativam as ferramentas individuais do servidor em vez de as aceitar todas. A Anthropic afirma a sua posição de confiança sem rodeios no centro de ajuda: os conectores personalizados permitem ligar o Claude a serviços arbitrários que não foram verificados pela Anthropic. No ChatGPT, os servidores remotos chegam pelo modo de programador — Settings → Security and login, na web, aceitando endpoints SSE e streaming HTTP. A própria documentação da OpenAI chama-lhe poderoso mas perigoso, nomeia a injeção de prompt e as ações de escrita destrutivas entre os riscos, e exige confirmação para ações de escrita por padrão.
No serviço onde deu a autorização. Esta é a que as pessoas saltam. Apagar o conector remove a cópia do token do seu cliente; a concessão registada na sua conta Google, GitHub, Atlassian ou Notion é um objeto separado com o seu próprio tempo de vida, e um token de atualização associado a ela pode sobreviver ao conector durante muito tempo. A orientação da Anthropic diz exatamente isso — revogue desligando o conector nas definições do Claude ou nas definições de segurança do serviço de terceiros. Faça as duas coisas, e encontre essa página de aplicativos ligados antes de ligar.
O registro MCP oficial em registry.modelcontextprotocol.io é o sítio natural
para encontrar servidores, e é fácil ler de mais numa listagem. A carta do seu
grupo de trabalho é específica. Publicação e confiança cobrem fluxos de
autenticação — GitHub OAuth, GitHub OIDC, verificação por DNS e HTTP — mais a
propriedade de espaços de nomes, ferramentas de moderação e sinalização pela
comunidade. Explicitamente fora de âmbito: classificar implementações de
servidores MCP ou escolher entre elas em nome de clientes ou usuários finais, e
hospedar, distribuir ou executar código de servidor, porque o registro é um
catálogo de metadados, não um registro de pacotes.
Assim, um espaço de nomes verificado prova que quem publicou a entrada controla a organização GitHub ou o domínio que está no nome. Isso é um sinal real: torna o typosquatting mais difícil e dá-lhe alguém a quem pedir contas. Não é uma revisão de código, nem uma auditoria de segurança, nem um aval — identidade estabelecida, comportamento ainda desconhecido.
Vale a pena levar um princípio da especificação para cada ligação: as descrições do comportamento das ferramentas, incluindo as anotações, devem ser consideradas não confiáveis a menos que venham de um servidor de confiança, e os hosts têm de obter consentimento explícito do usuário antes de invocar qualquer ferramenta. A descrição de uma ferramenta é texto que uma parte remota escreve e o seu modelo lê — a definição de entrada não confiável, e a razão pela qual «o servidor disse que era só de leitura» não é um controlo de segurança.
O precedente concreto é a CVE-2025-6514, publicada em 9 de julho de 2025 contra
o mcp-remote, o proxy que muitos clientes usavam para alcançar servidores
remotos. Classificada em 9,6, permitia que um servidor malicioso conseguisse
injeção de comandos do sistema operativo na máquina que se ligava, através de um
valor authorization_endpoint forjado no fluxo OAuth — afetando as versões
0.0.5 até 0.1.16 e corrigida na 0.1.16. Nada tinha de ser aprovado num chat:
ligar era o ataque inteiro. Tudo o que um servidor remoto envia são dados que o
seu software analisa, e a própria ligação faz parte da sua superfície de ataque.
Tudo o que está acima é o preço de alcançar algo que vive genuinamente na nuvem de outra pessoa — o seu sistema de tickets, o seu CRM, o seu calendário. É um preço razoável para esses e um preço estranho para arquivos que já estão no seu disco, e é por isso que o Speak-Y traz um servidor local em vez de um endpoint hospedado.
O seu servidor MCP é um processo que o seu cliente inicia na sua máquina. Ler
não precisa de mais nada em execução: resultados de pesquisa, transcrições,
resumos de reuniões e itens de ação saem diretamente da biblioteca no mesmo
computador, sem token emitido e sem nenhum retransmissor pelo meio. Os comandos
que alteram alguma coisa — etiquetar uma gravação, nomear participantes,
partilhar num canal de equipa — passam pelo aplicativo em execução, são
declarados ao seu cliente como alteradores de dados para que ele pergunte
primeiro, e ficam registados onde os pode desligar. Acrescentar --read-only
aos argumentos do servidor significa que os comandos que alteram nunca chegam
sequer a ser publicados a esse cliente — uma garantia mais forte do que uma
descrição que promete bom comportamento. A instalação é um clique a partir de
Configurações → Integrações, gratuita em todos os planos, incluindo o Free.
A troca funciona nos dois sentidos: um servidor local não consegue servir o ChatGPT numa aba do navegador, e só corre onde o aplicativo corre. Se essa restrição importa, que clientes conseguem iniciar um servidor local é a comparação a ler a seguir — e se a pergunta é o que um assistente deve poder alterar depois de ligado, onde fica a linha no acesso de escrita cobre isso. A visão geral do MCP lista o que o servidor do Speak-Y expõe.
Um servidor local é um programa na sua própria máquina que o cliente inicia e com o qual fala por entrada e saída padrão — o que entrega é uma linha de comando, e nenhum token é emitido. Um servidor remoto é um endpoint HTTPS operado por outra pessoa: o que entrega é uma credencial, normalmente um token de acesso OAuth 2.1, e os dados que as ferramentas tocam viajam para a infraestrutura desse operador.
Segundo a especificação de autorização do MCP, o token está ligado a um servidor e a um conjunto de scopes. Os clientes têm de enviar um indicador de recurso RFC 8707 que nomeie o servidor tanto no pedido de autorização como no pedido de token, e o servidor tem de validar que os tokens foram emitidos para si — não pode aceitar nem encaminhar qualquer outro token. Isso impede que o token seja reutilizado noutro serviço. Não diz nada sobre o que o operador faz com os dados que as suas próprias ferramentas vão buscar em seu nome.
Em dois sítios, e a maioria das pessoas só faz o primeiro. Remover o conector no seu assistente apaga a cópia do token que o cliente tem; a concessão OAuth registada no serviço onde deu a autorização é um objeto separado e normalmente sobrevive. A orientação da própria Anthropic diz para revogar permissões desligando o conector nas definições do Claude ou nas definições de segurança do serviço de terceiros. Encontre a página de aplicativos ligados do fornecedor antes de ligar, não depois.
Não. O registro verifica a propriedade do espaço de nomes — um nome io.github.* através da autenticação do GitHub, um nome baseado em domínio através de verificação por DNS ou HTTP — o que prova que quem publica controla esse nome. A sua carta coloca explicitamente fora de âmbito classificar implementações de servidores ou escolher entre elas, e afirma que o registro é um catálogo de metadados, não um registro de pacotes: não hospeda, não distribui nem executa código de servidor.
Apenas o que os scopes que aprovou alcançam. O risco é os scopes serem mais amplos do que a tarefa: um token concedido para uma caixa de correio ou um disco inteiros fica disponível para todas as ferramentas que esse servidor expõe, enquanto a concessão durar. Leia a tela de consentimento em vez da página de marketing, e use os controlos por ferramenta onde o cliente os tiver — as definições de conectores do Claude permitem ativar e desativar ferramentas uma a uma, e o modo de programador do ChatGPT exige confirmação para ações de escrita por padrão.