Teste de Simon da Anthropic expõe o atrito por trás de conexões MCP personalizadas

O observador da Anthropic Simon Willison conectou um servidor MCP personalizado ao Claude e ao ChatGPT, mas o experimento revelou dois caminhos de configuração muito diferentes. Seu teste de 29 de julho mostrou que interfaces de chat padrão podem usar ferramentas criadas por desenvolvedores, apesar de barreiras de produto, requisitos de hospedagem remota e trabalho de autorização.

O experimento anthropic simon importa porque o Model Context Protocol está indo além dos agentes de programação e dos arquivos de configuração de desktop. O MCP, um protocolo aberto para conectar aplicações de IA a ferramentas e dados externos, está chegando às janelas de chat do dia a dia. Isso amplia seu público, ao mesmo tempo que torna mais difíceis de ignorar as restrições no nível do produto.

O Claude apresenta a conexão como um conector personalizado. O ChatGPT coloca funcionalidades comparáveis por trás de seu sistema de apps e controles de desenvolvedor. Ambos podem acessar um servidor remoto, mas nenhum transforma esse servidor em um plug-in universalmente portátil. O protocolo padroniza a comunicação, enquanto cada host ainda controla descoberta, permissões, aprovações e disponibilidade.

O que o teste MCP de Simon Willison realmente mudou

Agora, um servidor MCP personalizado pode atender tanto Claude quanto ChatGPT sem exigir que os usuários saiam de suas conversas web padrão.

Willison documentou o processo em um teste MCP personalizado, publicado em 29 de julho de 2026. O resultado central foi simples. Um desenvolvedor pode hospedar um servidor MCP, registrá-lo nos dois serviços e expor suas ferramentas em suas interfaces de chat regulares.

Esse resultado diferencia o experimento de demonstrações anteriores de MCP centradas no Claude Code, em arquivos de configuração de desktop ou em clientes voltados a desenvolvedores. Esses ambientes já tornavam as conexões com ferramentas relativamente naturais. Produtos de chat padrão para consumidores aplicam outra camada de regras de conta e controles de interface.

O servidor precisa ser acessível remotamente. Um processo local que use o transporte padrão de entrada e saída não pode simplesmente aparecer em uma sessão de navegador. O host precisa de um endpoint HTTP acessível pela internet que implemente as partes do MCP esperadas por cada cliente.

O acesso remoto muda o modelo de implantação. Um desenvolvedor deixa de configurar um aplicativo para iniciar um processo confiável em um computador pessoal. Ele passa a operar um serviço de rede que precisa lidar com segurança de transporte, identidade, autorização, disponibilidade e, potencialmente, múltiplos usuários.

O Claude descreve essas integrações como conectores personalizados. A Anthropic afirma que eles podem conectar o Claude a ferramentas hospedadas e fontes de dados por meio de servidores MCP remotos. Sua atual orientação sobre conectores lista suporte do Claude e do Claude Desktop para contas individuais e de ambiente de trabalho elegíveis.

O ChatGPT descreve a mesma capacidade ampla por meio de apps personalizados e conectores MCP. A interface da OpenAI também diferencia criar um app, testá-lo, aprová-lo e disponibilizá-lo em um espaço de trabalho.

Essa diferença de nomenclatura é mais do que cosmética. “Conector” sugere uma ponte para um serviço existente. “App” sugere algo empacotado, revisado e distribuído por uma superfície de produto controlada pelo host. O MCP pode oferecer suporte a ambos os modelos, mas os rótulos moldam as expectativas dos usuários.

O servidor também precisa de definições de ferramentas úteis. Essas descrições informam ao modelo o que cada ferramenta faz, quando deve ser chamada e quais entradas aceita. Um endpoint tecnicamente válido ainda pode ter desempenho ruim quando suas ferramentas se sobrepõem ou usam descrições vagas.

O teste de Willison, portanto, demonstrou interoperabilidade na camada de protocolo, não comportamento idêntico entre produtos. Claude e ChatGPT podem descobrir as mesmas capacidades básicas. Ainda assim, podem selecionar ferramentas de forma diferente, solicitar aprovações distintas e apresentar resultados por interfaces diferentes.

Para desenvolvedores, o fato mais memorável não é que as duas empresas oferecem suporte ao MCP de alguma forma. A mudança importante é que uma implementação hospedada agora pode alcançar usuários dentro dos dois principais produtos de chat. Isso torna práticos os testes entre produtos sem manter dois protocolos de integração totalmente separados.

Por que o resultado da Anthropic com Simon pressiona ambas as plataformas de IA

O MCP desloca parte da disputa competitiva da inteligência dos modelos para o controle sobre ferramentas, permissões e distribuição.

O resultado anthropic simon pressiona a Anthropic porque ela criou o MCP e promoveu o protocolo como um padrão aberto. O Claude precisa continuar sendo um cliente de referência convincente. Se servidores externos funcionarem de forma mais previsível em outros lugares, a autoria do protocolo não garantirá a preferência pela plataforma.

A OpenAI enfrenta a pressão oposta. Ela não originou o MCP, mas o ChatGPT tem um papel enorme como plataforma de aplicações. Os desenvolvedores esperarão que ele ofereça suporte a integrações que já funcionam com o Claude e outros clientes MCP.

Isso cria uma disputa clara entre portabilidade de protocolo e controle de plataforma. Os desenvolvedores querem descrever uma ferramenta uma vez e conectá-la a produtos compatíveis. Os operadores de plataforma querem decidir quais contas podem conectar servidores, quais ações são permitidas e como chamadas arriscadas são revisadas.

Atualmente, o Claude oferece um conceito direto de conector personalizado para vários tipos de conta. O uso no ambiente de trabalho introduz controles de administrador porque um conector pode expor dados da empresa ou executar ações. Um proprietário pode configurar a disponibilidade, enquanto usuários individuais ainda se autenticam com suas próprias permissões.

O ChatGPT aplica uma estrutura de implantação mais explícita. O atual guia do modo de desenvolvedor da OpenAI afirma que o suporte completo ao MCP está disponível na web para clientes Business e Enterprise ou Edu. Ele também descreve acesso mais limitado de leitura e busca para usuários Pro.

A distinção se torna importante quando um servidor expõe operações de escrita. Pesquisar uma coleção de documentos traz um perfil de risco. Atualizar registros de clientes, publicar conteúdo ou excluir um projeto traz outro.

A OpenAI afirma que ações de escrita e modificação podem acionar confirmação, dependendo da permissão, do contexto e do impacto potencial. Algumas ações especialmente arriscadas podem ser bloqueadas. Administradores do espaço de trabalho também controlam se um app passa de testes privados para disponibilidade aprovada.

A Anthropic também aconselha os usuários a inspecionar solicitações de ferramentas e habilitar apenas as ferramentas relevantes para uma conversa. Seu alerta reflete uma limitação básica das interfaces agênticas. Uma solicitação em linguagem natural nem sempre revela todas as ações externas que um modelo pode considerar necessárias.

Esses controles enfraquecem a promessa mais simples de portabilidade. Um desenvolvedor pode reutilizar o servidor, os esquemas e a base de autorização. Ele não pode presumir acesso equivalente, fluxos de usuário, comportamento de confirmação ou decisões do modelo.

Essa fragmentação não é necessariamente uma falha do protocolo. O MCP define uma linguagem compartilhada entre clientes e servidores. Ele não exige que todos os hosts adotem as mesmas políticas de produto.

Ainda assim, o atrito de produto pode determinar se a compatibilidade de protocolo importa na prática. Uma conexão escondida atrás de configurações de administrador alcançará menos usuários do que uma disponível em uma tela de configurações pessoais. Uma implementação somente leitura não pode substituir um concorrente que permite escritas cuidadosamente aprovadas.

A qualidade da invocação de ferramentas acrescenta outra fonte de pressão. O modelo precisa escolher a ferramenta correta, produzir argumentos válidos, interpretar erros e comunicar resultados. Oferecer suporte a um transporte MCP não garante a conclusão confiável da tarefa do usuário.

Por isso, os desenvolvedores devem testar os mesmos prompts nas duas plataformas. Um servidor pode expor ferramentas idênticas e ainda produzir padrões de chamada diferentes. Essas diferenças podem revelar se uma descrição é ambígua ou se um host aplica controles mais rígidos.

A questão competitiva mais ampla já não é se Claude ou ChatGPT podem chamar uma API. Ambas as plataformas podem. A questão é qual delas torna as capacidades externas compreensíveis, governáveis e confiáveis para usuários comuns.

Um protocolo ainda produz duas experiências de configuração

O MCP reduz o código de integração duplicado, mas não elimina as etapas operacionais em torno de uma conexão segura.

Para o Claude, o caminho básico passa por Configurações e Conectores. Um usuário adiciona um conector personalizado, fornece o endereço do servidor remoto e conclui a autenticação quando o servidor a exige. Proprietários de ambientes de trabalho podem precisar habilitar ou configurar primeiro o conector.

A documentação de servidores da Anthropic orienta os desenvolvedores para a especificação de autorização do protocolo e exemplos dos SDKs oficiais. Ela também observa suporte aos atuais padrões de autorização remota.

Para o ChatGPT, o caminho passa por Apps e configurações avançadas. O usuário ou administrador habilita o acesso de desenvolvedor, cria um app, informa a URL remota do MCP, escolhe a autenticação e aceita o aviso associado a um servidor personalizado.

Administradores de espaços de trabalho Business podem criar e implantar apps para seu espaço de trabalho. Ambientes Enterprise e Edu adicionam controles baseados em funções para desenvolvedores e usuários. Essas regras tornam a conexão parte da governança organizacional, e não apenas uma configuração pessoal.

O núcleo técnico compartilhado é um endpoint MCP remoto. Servidores remotos modernos costumam usar Streamable HTTP, um transporte que carrega mensagens MCP por solicitações HTTP e respostas em streaming. Esse endpoint precisa oferecer suporte às trocas de inicialização e descoberta de ferramentas esperadas por clientes compatíveis.

As mensagens MCP usam JSON-RPC 2.0, um formato estruturado para solicitações, resultados, notificações e erros. O protocolo define como um cliente descobre e invoca ferramentas. Ele não define a lógica de negócio subjacente a cada ferramenta.

Considere um servidor privado de pesquisa. Ele pode oferecer uma ferramenta para pesquisar documentos armazenados e outra para recuperar um registro completo. Claude e ChatGPT podem descobrir essas definições no mesmo endpoint.

O desenvolvedor ainda precisa decidir quem pode pesquisar quais registros. Essa decisão pertence ao servidor e à sua camada de autorização. Ocultar uma ferramenta na interface de um cliente não substitui a aplicação do controle de acesso na fonte dos dados.

OAuth torna-se central quando o servidor lida com dados específicos de usuários. O cliente conduz o usuário por um fluxo de autorização, recebe um token de acesso e apresenta esse token ao chamar o servidor MCP protegido. Em seguida, o servidor valida o token antes de retornar os dados.

A especificação de autorização do MCP exige metadados de recurso protegido para implantações de autorização HTTP compatíveis. Esses metadados informam a um cliente onde estão localizados os serviços de autorização. Isso oferece suporte à descoberta sem codificar permanentemente cada pareamento entre cliente e servidor.

É nesse ponto que uma prova rápida se torna um projeto real de engenharia. O servidor precisa de um endereço HTTPS estável, metadados corretos, tratamento de redirecionamentos, validação de tokens e escopos adequados. Também precisa de mensagens de erro que os clientes consigam interpretar quando a autorização falhar.

O registro de clientes pode criar outro problema de compatibilidade. Alguns sistemas oferecem suporte a registro dinâmico ou documentos de metadados de cliente. Outros esperam um identificador de cliente criado antecipadamente. Um servidor projetado com base em uma premissa pode precisar de adaptação antes que ambos os produtos de chat se autentiquem corretamente.

Uma implementação prática deve começar com uma ferramenta restrita e somente de leitura. Por exemplo, uma equipe poderia expor notas de projeto aprovadas por meio de uma única função de busca. Os usuários poderiam pedir a qualquer assistente para encontrar decisões anteriores sem conceder direitos de atualização ou exclusão.

Esse caso de uso também cria uma ponte natural para uma base de conhecimento pessoal ou de equipe. O MCP pode fornecer a camada de acesso, enquanto o sistema subjacente continua responsável por indexação, permissões, retenção e qualidade das fontes.

Depois que o caminho de leitura funcionar, os desenvolvedores podem adicionar ações mais precisas. Cada ferramenta de escrita deve ter uma finalidade evidente e escopo limitado. “Atualizar o status de uma tarefa” é mais fácil de revisar do que “executar uma operação arbitrária de projeto”.

As descrições das ferramentas merecem o mesmo cuidado que um contrato de API. O modelo vê essas descrições ao decidir se deve chamar uma função. Nomes vagos aumentam a chance de seleção incorreta, chamadas repetidas ou acesso desnecessário a dados.

Os esquemas de entrada também devem rejeitar ambiguidades. Uma ferramenta que altera uma conta deve exigir um identificador estável da conta. Ela não deve depender apenas do nome de um cliente que possa corresponder a vários registros.

As respostas devem retornar informações estruturadas suficientes para que o modelo explique o que aconteceu. Uma ferramenta de escrita pode incluir o objeto alterado, seu estado anterior e o novo estado. Isso ajuda o host a apresentar uma confirmação significativa.

Os testes precisam cobrir mais do que chamadas bem-sucedidas. Os desenvolvedores devem testar tokens expirados, permissões revogadas, dependências indisponíveis, entradas malformadas e tentativas de acessar registros de outro usuário. Os dois hosts podem apresentar essas falhas de maneiras diferentes.

Isso explica por que adicionar um servidor personalizado pode parecer demorado apesar de um protocolo aberto. O MCP elimina uma categoria de duplicação de integração. Ele não elimina implantação, identidade, revisão de segurança, configuração de produto ou garantia de qualidade.

A Troca Real É Entre Portabilidade e Confiança

A mesma abertura que permite que um servidor alcance vários assistentes também coloca esse servidor em uma posição privilegiada entre usuários, modelos e sistemas sensíveis.

Um servidor MCP personalizado pode ver as entradas enviadas por suas ferramentas. Ele pode retornar conteúdo que o modelo trata como contexto. Se expuser ações, também poderá alterar dados externos sob a identidade do usuário.

Essa combinação cria vários limites de confiança. Os usuários precisam confiar no provedor de chat, no operador do servidor MCP, no serviço conectado e na implementação de autorização. As organizações também precisam confiar nas descrições que orientam o comportamento do modelo.

A injeção de prompt é uma grande preocupação. Uma instrução maliciosa pode ser incorporada a dados recuperados por uma ferramenta, como um documento, ticket de suporte ou página da web. O modelo pode interpretar esse conteúdo como uma orientação, em vez de material não confiável.

O risco cresce quando várias ferramentas estão disponíveis. Conteúdo recuperado pode tentar persuadir o modelo a chamar outra ferramenta com argumentos sensíveis. Portanto, uma operação de leitura pode se tornar a etapa inicial de uma sequência de escrita não intencional.

Tanto a Anthropic quanto a OpenAI alertam os usuários para conectar apenas servidores confiáveis. Esse conselho é necessário, mas confiança não é um controle de segurança completo. Mesmo um servidor bem-intencionado pode conter erros de autorização ou ações excessivamente amplas.

O servidor deve validar cada solicitação de forma independente. Ele nunca deve presumir que uma chamada é segura porque Claude ou ChatGPT a gerou. As confirmações do host podem ajudar os usuários, mas não substituem verificações de acesso no servidor.

O tratamento de tokens exige cuidado especial. A especificação MCP proíbe o repasse de tokens, em que um servidor encaminha a outro um token destinado a um serviço. Os tokens devem ter um público definido, e o servidor receptor deve verificar esse público.

O princípio do menor privilégio oferece o ponto de partida mais claro. Um conector de pesquisa deve solicitar acesso de leitura antes de pedir acesso de escrita. Uma ferramenta de calendário não deve solicitar direitos de exclusão quando só precisa listar disponibilidade.

As operações de escrita também se beneficiam de semântica restrita. Uma ferramenta chamada delete_everything é obviamente perigosa, mas funções administrativas amplas podem esconder exposição semelhante por trás de nomes mais amigáveis. Cada ação deve corresponder a uma intenção do usuário que possa ser revisada.

Operações de alto impacto devem oferecer suporte à idempotência, que impede que repetições acidentais produzam várias alterações. Um modelo pode tentar novamente após uma resposta pouco clara. Sem proteções, uma tarefa solicitada pode criar registros ou mensagens duplicados.

Os logs de auditoria são igualmente importantes. Os operadores precisam saber qual usuário autorizou uma chamada, qual ferramenta foi executada, qual objeto foi alterado e se o host informou a confirmação. Os logs devem evitar reter conteúdo desnecessário de prompts ou segredos.

Os operadores de servidores devem separar dados voltados ao usuário de instruções de controle. Os resultados das ferramentas podem rotular claramente textos não confiáveis e retornar campos estruturados quando possível. Os modelos continuam vulneráveis à manipulação, mas um design cuidadoso de saída reduz ambiguidades.

As plataformas de host também enfrentam questões não resolvidas. Seus prompts de aprovação devem fornecer informações suficientes para que os usuários entendam uma ação. Um pedido genérico para “permitir acesso à ferramenta” oferece pouca proteção quando a ferramenta pode executar várias operações.

O comportamento da ferramenta pode mudar após a conexão. A Anthropic observa explicitamente que desenvolvedores de servidores podem alterar ferramentas sem aviso. Um usuário que aprovou um conector de busca inofensivo pode posteriormente encontrar recursos mais amplos no mesmo endpoint.

Versionamento e revisão podem reduzir esse risco. As organizações podem fixar implantações, monitorar mudanças de esquema e exigir outra revisão quando uma ferramenta obtém acesso de escrita. Operadores de servidores públicos podem publicar registros de alterações e manter escopos estáveis.

Há também uma questão de privacidade relacionada à movimentação de dados. Uma empresa pode permitir que seu assistente pesquise registros internos enquanto proíbe que esses registros cheguem a outro processador. A localização de hospedagem e a política de retenção do servidor MCP passam a fazer parte da decisão.

Portanto, uma implantação segura exige mais do que uma conexão válida. As equipes devem documentar categorias de dados, ações permitidas, escopos de autenticação, regras de retenção, contatos para incidentes e procedimentos de revogação. Elas também devem testar como cada host informa o uso de ferramentas.

A demonstração anthropic simon prova que a conectividade entre plataformas é possível. Ela não prova que todo servidor acessível seja adequado para produção. Compatibilidade é o início da avaliação, não o fim.

Essa distinção importa para trabalhadores do conhecimento que desejam que seu assistente preferido acesse notas privadas ou histórico de projetos. Um conector pode reduzir a cópia entre ferramentas. Também pode ampliar o caminho pelo qual contextos sensíveis transitam.

As equipes que avaliam essa troca devem começar com informações que podem se dar ao luxo de expor sob acesso controlado. Uma coleção pesquisável de documentação de engenharia aprovada é mais segura do que uma porta de entrada irrestrita para todos os sistemas internos.

Em seguida, elas podem medir se o assistente encontra fontes corretas, respeita permissões e explica claramente o uso das ferramentas. A expansão deve seguir evidências, não a mera disponibilidade de um endpoint MCP.

O Que o Experimento Simon da Anthropic Indica para Observar em Seguida

O próximo teste do MCP é saber se servidores entre plataformas se tornarão produtos comuns, em vez de integrações especializadas montadas por meio de configurações avançadas.

O primeiro sinal é a convergência em torno da autorização remota. Claude e ChatGPT precisam conectar usuários com segurança sem exigir trabalho de registro personalizado para cada combinação. A adoção mais ampla se fortalecerá se uma implantação OAuth compatível com o padrão funcionar de forma confiável em ambos.

Se a autorização continuar repleta de exceções específicas de cliente, a alegação de portabilidade enfraquece. Os desenvolvedores ainda reutilizarão partes do servidor, mas manterão instruções separadas de configuração, metadados e caminhos de solução de problemas.

A evidência mais forte virá de serviços comuns que publiquem um endpoint remoto com instruções verificadas para vários assistentes. Esses serviços não devem exigir que os usuários colem chaves de API de longa duração nas configurações de chat. O consentimento baseado no navegador deve conceder escopos restritos e revogáveis.

O segundo sinal é como a OpenAI amplia o acesso completo ao MCP. A documentação atual distingue suporte completo para contas gerenciadas de ambiente de trabalho de recursos Pro mais limitados. Uma rota pessoal mais ampla colocaria pressão direta sobre a experiência de conectores personalizados do Claude.

Uma ênfase contínua na implantação por administradores apontaria para uma estratégia diferente. Os apps do ChatGPT funcionariam principalmente como software corporativo governado, enquanto Claude poderia manter um caminho mais direto para experimentação individual.

Nenhuma das rotas é automaticamente melhor. Empresas frequentemente precisam de aprovação, auditabilidade e controles de função. Desenvolvedores independentes valorizam um caminho curto entre um servidor implantado e uma conversa funcional.

O terceiro sinal é como ambas as plataformas lidam com ações de escrita. Busca e recuperação geram demonstrações úteis, mas as ações determinam se o MCP se torna uma verdadeira camada de aplicação. Elas também criam os problemas mais difíceis de segurança e interface.

Observe resumos de permissão mais claros, prévias de ação, políticas de confirmação e registros de auditoria. Um host que explica bem os efeitos externos pode tornar ferramentas de escrita mais utilizáveis sem fingir que elas não apresentam riscos.

Os desenvolvedores também devem observar se os hosts expõem diagnósticos melhores. Falhas de conexão frequentemente reduzem várias causas possíveis a um único erro. O problema pode envolver negociação de transporte, metadados de autorização, configuração de redirecionamento, público do token ou validação do esquema da ferramenta.

Diagnósticos melhores encurtariam o caminho entre um servidor local funcional e uma integração remota confiável. Eles também reduziriam a pressão sobre operadores de servidores para fazer engenharia reversa das diferentes expectativas dos hosts.

Sistemas de registro e descoberta representam outra camada importante. Um protocolo aberto não informa aos usuários quais servidores são confiáveis. Diretórios selecionados podem ajudar, mas também dão aos proprietários das plataformas outro ponto de controle.

Um servidor listado por um host pode continuar sendo uma conexão personalizada manual em outro. Os desenvolvedores então enfrentam um problema de distribuição, mesmo quando sua implementação é portátil. Prazos de revisão e regras de listagem podem se tornar diferenciais competitivos.

Portanto, os usuários devem distinguir compatibilidade de servidor de disponibilidade de servidor. Um serviço pode funcionar tecnicamente com Claude e ChatGPT, mas continuar difícil de encontrar ou restrito por uma política de espaço de trabalho.

A mesma distinção se aplica ao suporte de interface. MCP Apps podem retornar interfaces interativas em hosts compatíveis, enquanto servidores básicos de ferramentas trocam principalmente dados estruturados e texto. Diferentes níveis de suporte podem fazer uma integração parecer mais rica, apesar de usar o mesmo protocolo subjacente.

Para criadores, a estratégia imediata é conservadora. Hospede um servidor remoto compatível com o padrão, comece com uma ferramenta de leitura restrita e teste prompts idênticos nos dois produtos. Registre todas as diferenças em autenticação, descoberta, invocação e tratamento de erros.

Em seguida, introduza uma ação de escrita limitada com autorização explícita. Confirme que novas tentativas não duplicam alterações e que a revogação funciona. Revise exatamente o que cada plataforma mostra antes de a ação ser executada.

Para organizações, a decisão deve começar pelo fluxo de trabalho, e não pelo entusiasmo com o MCP. Identifique uma tarefa repetida em que o acesso via chat reduza a alternância real entre ferramentas ou o esforço de busca. Em seguida, defina o menor escopo de dados e ações necessário para concluí-la.

Um bom candidato pode pesquisar documentos técnicos aprovados e retornar links para as fontes. Outro pode redigir uma atualização de projeto sem publicá-la. Ambos geram valor enquanto mantêm as alterações finais sob controle humano.

A frase de busca “anthropic simon” provavelmente atrairá leitores interessados no experimento específico de Simon Willison. Seu valor duradouro vai além da sequência de configuração. O teste revela onde termina a padronização de protocolos e começa a política das plataformas.

O MCP ultrapassou uma fronteira importante ao chegar às interfaces padrão do Claude e do ChatGPT. A próxima questão é se conectar um servidor confiável se tornará algo simples, previsível e visível para usuários comuns.

Os desenvolvedores já podem ajudar a responder a essa pergunta. Escolha um fluxo de trabalho de baixo risco, crie um endpoint remoto com permissões restritas e compare ambos os hosts usando os mesmos prompts de teste. As diferenças mostrarão se o MCP está oferecendo portabilidade prática ou apenas uma base técnica compartilhada.