A hospedagem de servidores MCP no ChatGPT leva a implantação para o Sites, mas o acesso ainda define o limite

O ChatGPT agora oferece suporte a um fluxo de trabalho de servidor MCP do ChatGPT que permite criar, hospedar e implantar ferramentas por meio do Sites, sem exigir um provedor de hospedagem separado. A mudança elimina uma das maiores barreiras práticas em torno do Model Context Protocol, ou MCP, que permite que clientes de IA invoquem ferramentas externas por meio de uma interface compartilhada.

Uma publicação pública de Tibo Thibault destacou o recurso em 1º de outubro de 2026. A documentação atual da OpenAI confirma o fluxo de trabalho subjacente. Um usuário pode pedir ao ChatGPT ou ao Codex que adicione um servidor MCP a um Site, publique-o e instale o plugin resultante.

Isso torna o anúncio mais relevante do que outra atualização de um criador de sites. Até agora, um servidor MCP típico do ChatGPT exigia código, um endpoint acessível pela internet, infraestrutura de implantação e um processo de conexão separado. O Sites reúne várias dessas etapas em um único ambiente conversacional.

Portanto, a disputa importante não é entre o ChatGPT e outro modelo. É entre a implantação gerenciada e orientada por prompts e a rota convencional de MCP auto-hospedado. A OpenAI encurtou o caminho entre uma ideia e uma ferramenta instalada, mas permissões, testes e distribuição ainda determinam se essa ferramenta é útil.

O que mudou com a hospedagem de servidores MCP no ChatGPT

O ChatGPT Sites agora pode atuar tanto como a superfície da aplicação quanto como o host de ferramentas MCP usadas por meio de um plugin.

O ChatGPT Sites é o ambiente da OpenAI para criar e publicar sites interativos e aplicações leves. Os usuários descrevem o que querem, revisam uma prévia gerada, solicitam revisões e implantam o resultado em uma URL de Site.

O novo elemento é a possibilidade de adicionar ferramentas no lado do servidor a esse Site. O guia do Sites da OpenAI diz que os usuários podem pedir ao ChatGPT ou ao Codex que adicionem um servidor MCP a um Site novo ou existente. Eles devem descrever as informações que essas ferramentas podem ler e as alterações que podem fazer.

O MCP é um protocolo para expor ferramentas e dados a clientes de IA compatíveis. O servidor descreve as operações disponíveis, suas entradas e suas saídas. O ChatGPT pode então chamar essas operações quando um usuário faz uma solicitação relevante.

Por exemplo, o proprietário de um Site pode criar um painel de projeto e adicionar ferramentas para ler marcos e atualizar seu status. Publicar o Site cria um plugin associado que expõe essas ferramentas em conversas compatíveis do ChatGPT e do Codex.

Essa sequência comprime várias tarefas antes separadas:

• O usuário define o fluxo de trabalho desejado em uma conversa.

• O ChatGPT ou o Codex cria o Site e suas ferramentas MCP.

• O proprietário revisa o Site e testa seu comportamento.

• A publicação gera um Site ativo e seu plugin associado.

• O usuário instala e conecta esse plugin.

• O ChatGPT pode invocar suas ferramentas em conversas posteriores.

O Site continua sendo mais do que uma interface estática. Ele pode armazenar informações, apresentar uma visualização interativa e fornecer as operações expostas por meio do MCP. O exemplo da OpenAI descreve um manual de equipe com ferramentas para pesquisar e acessar seu conteúdo.

Esse padrão também se aplica a rastreadores de projetos, diretórios internos, calendários de lançamento, localizadores de documentos e painéis operacionais. Uma equipe poderia combinar essa abordagem com uma base de conhecimento pesquisável, desde que seus dados e permissões sejam projetados com cuidado.

O proprietário deve publicar o Site antes que o plugin associado apareça. Adicionar ou alterar ferramentas também exige outra publicação antes que essas mudanças fiquem disponíveis. Um rascunho salvo não altera silenciosamente o plugin ativo.

A OpenAI descreve o Sites como uma beta pública. Ele está disponível para espaços de trabalho do ChatGPT, contas Plus e contas Pro, embora a implementação possa não chegar a todas as contas simultaneamente. Administradores de espaços de trabalho podem controlar direitos de criação e publicação.

A URL de implantação é uma URL de produção. A OpenAI aconselha os criadores a salvar uma versão e revisar as mudanças antes da implantação. Essa distinção importa porque a edição conversacional pode parecer informal, mesmo quando o software resultante tem usuários ativos.

O resultado é um caminho de implantação consideravelmente mais curto. Ele não elimina as operações de software, mas transfere muitas delas para um produto gerenciado e um fluxo de trabalho conversacional.

Por que a implantação orientada por prompts pressiona a rota auto-hospedada

O Sites transforma a implantação de MCP de um projeto de infraestrutura em uma tarefa de configuração de produto para muitos fluxos de trabalho menores.

Uma implantação remota convencional de MCP ainda exige um servidor funcional que o ChatGPT possa alcançar pela internet pública. O desenvolvedor precisa implementar ferramentas, expor um endpoint HTTPS, configurar autenticação e manter o serviço disponível.

O guia de início rápido do MCP da OpenAI ilustra essa rota. Os desenvolvedores instalam um kit de desenvolvimento de software MCP, criam um servidor, expõem um endpoint /mcp e conectam a URL pública por meio dos controles de desenvolvedor do ChatGPT.

Essa continua sendo a rota apropriada quando uma equipe precisa de infraestrutura personalizada, integrações complexas, escalabilidade independente ou controle sobre o runtime. Ela também dá aos desenvolvedores autoridade direta sobre cronogramas de implantação, logs, redes e armazenamento de dados.

No entanto, muitas ferramentas internas não começam com esses requisitos. Elas começam como solicitações restritas, como pesquisar em um manual, atualizar um marco ou recuperar um registro de projeto. O trabalho de infraestrutura pode exceder o escopo funcional da primeira versão.

O ChatGPT Sites mira essa lacuna. Um usuário pode descrever o Site, seus dados e as operações que o ChatGPT deve executar. O Codex pode então gerar a camada de ferramentas necessária e conectá-la a um plugin instalável.

Isso não torna o conhecimento de engenharia irrelevante. Muda o ponto em que esse conhecimento se torna necessário.

A primeira versão pode surgir por meio de uma criação guiada, em vez de uma pilha de implantação montada manualmente. A atenção de engenharia pode se deslocar para limites das ferramentas, autorização, tratamento de erros e qualidade dos dados.

Essa é a inversão central. O MCP foi projetado para padronizar conexões, mas operar um servidor ainda criava atrito para pessoas que queriam apenas um fluxo de trabalho focado. A OpenAI agora está usando um host gerenciado para reduzir essa carga operacional.

A pressão recai primeiro sobre padrões de hospedagem leves e protótipos internos. Um desenvolvedor talvez não precise mais de um projeto de nuvem separado apenas para testar se um fluxo de trabalho com três ferramentas resolve um problema real.

A pressão também alcança criadores de IA no-code e low-code. O ChatGPT agora conecta especificação conversacional, geração de aplicações, hospedagem e instalação de plugins em um único ambiente de conta. Isso reduz a distância entre um protótipo e uma ferramenta utilizável do ChatGPT.

Ainda assim, a auto-hospedagem mantém vantagens significativas. Um Site gerenciado não oferece automaticamente a flexibilidade de implantação, a observabilidade, a portabilidade ou a capacidade exigidas por todos os sistemas de produção.

A OpenAI também aplica limites de uso específicos por plano durante a beta pública. Esses limites abrangem o Sites em toda uma conta e podem afetar a capacidade de criar Sites, adicionar armazenamento ou manter um Site movimentado disponível publicamente.

A documentação orienta os usuários a verificar os limites exibidos em suas contas. Ela não fornece uma capacidade fixa que se aplique universalmente.

Essa incerteza impede uma conclusão simples de que o Sites substitui a hospedagem MCP convencional. Em vez disso, ele cria uma opção gerenciada padrão para implantações menores ou em estágio inicial.

Os desenvolvedores devem enxergar as duas rotas como compromissos operacionais distintos:

• Ferramentas hospedadas em Sites priorizam velocidade, implantação integrada e um fluxo de trabalho guiado.

• Ferramentas auto-hospedadas priorizam controle de infraestrutura, arquitetura personalizada e operações independentes.

• Plugins hospedados em Sites herdam os controles de conta e espaço de trabalho da OpenAI.

• Servidores auto-hospedados ainda herdam requisitos de conexão, autorização e revisão do ChatGPT.

Para muitas equipes, a escolha dependerá menos da geração de código do que da governança. Criar uma ferramenta MCP está se tornando mais fácil. Decidir quem pode invocá-la continua sendo a decisão de produto mais difícil.

Como o Site se torna um plugin instalável

O fluxo de trabalho vincula um Site publicado a um plugin, mas instalação e autorização continuam sendo etapas separadas.

O guia de hospedagem da OpenAI descreve uma sequência específica. O criador começa com um Site de sua propriedade, pede ao ChatGPT ou ao Codex que adicione ferramentas MCP, revisa-as e publica o Site.

Depois que a configuração do MCP é concluída, o ChatGPT apresenta um cartão de plugin associado àquele Site. O criador pode revisar o cartão, selecionar Install e concluir o fluxo de conexão.

O plugin instalado pode então ser mencionado em uma conversa compatível do ChatGPT ou do Codex. O ChatGPT também pode selecionar um plugin instalado quando ele corresponder à solicitação do usuário.

Essa etapa de empacotamento importa porque um endpoint MCP bruto e uma experiência distribuível no ChatGPT não são idênticos. O plugin fornece uma unidade reconhecível que os usuários podem instalar, encontrar, selecionar e gerenciar.

Os plugins podem incluir habilidades, aplicações conectadas, ferramentas apoiadas por MCP e extensões interativas. Uma aplicação MCP hospedada em Site se torna um componente dentro desse sistema de empacotamento mais amplo.

O diretório atual de plugins aparece no ChatGPT para web, desktop e dispositivos móveis. No entanto, a OpenAI alerta que capacidades individuais podem variar conforme a superfície, conta, região, plano, função e configuração do espaço de trabalho.

Essa ressalva é importante. Um plugin aparecer no diretório não garante que todas as ferramentas ou visualizações incluídas funcionem de modo idêntico em todos os lugares.

Aplicações MCP locais ilustram a distinção. A OpenAI diz que uma aplicação local pode ser executada por meio de um plugin no ChatGPT Desktop. Salvar esse plugin em uma conta não torna suas ferramentas locais disponíveis na web ou em dispositivos móveis.

A hospedagem no Sites resolve essa limitação ao fornecer um runtime remoto. Ainda assim, o suporte preciso do plugin em cada superfície depende de suas capacidades incluídas e da disponibilidade atual do produto.

O Site associado também tem seu próprio modelo de acesso. Um destinatário pode precisar de permissão para visualizar o Site, permissão para usar o plugin e autorização para qualquer serviço conectado.

Instalar o plugin não ignora essas camadas. Compartilhar apenas um Site não compartilha o plugin, e compartilhar um plugin não concede acesso a dados não relacionados.

Essa separação protege contra uma suposição fácil, mas perigosa. Uma ferramenta poder ser instalada não significa que ela possa ler tudo o que seu criador pode ler.

Cada usuário pode precisar conectar uma conta elegível. Quando um Site acessa aplicações conectadas, os visitantes usam suas próprias conexões e suas permissões existentes.

Considere um painel de projeto conectado a um rastreador de issues. O Site poderia mostrar issues atribuídas e expor uma ação de atualização. Um destinatário deveria ver apenas os registros permitidos pela sua conta no rastreador de issues.

O mesmo princípio se aplica a repositórios de documentos, registros de clientes e manuais internos. O Site fornece a interface e as ferramentas hospedadas, mas o serviço subjacente continua sendo um limite de autorização.

Esse modelo cria uma rota mais prática para ferramentas pessoais e de espaço de trabalho. Ele também introduz um problema de solução de falhas em múltiplas camadas quando o acesso falha.

Uma chamada de ferramenta com falha pode se originar do Site, da conexão do plugin, de uma função no workspace, da aplicação subjacente ou da conta do provedor do usuário. Os criadores precisarão testar cada camada de forma independente.

A experiência de instalação, portanto, representa um progresso real do produto, mas não portabilidade universal. A OpenAI unificou o fluxo de criação e empacotamento, mantendo domínios de segurança distintos.

As permissões são o limite do produto

O recurso mais forte do novo fluxo de trabalho também é seu maior risco: uma ferramenta gerada em conversa pode executar ações reais.

Os criadores precisam decidir se cada ferramenta apenas lê informações ou também pode modificá-las. Uma operação de busca e uma operação de atualização podem aparecer lado a lado, mas trazem consequências operacionais diferentes.

A OpenAI orienta os criadores a revisar o conteúdo do Site e o comportamento das ferramentas antes de compartilhar o acesso. Especificamente, pede que considerem se os usuários devem apenas ler dados ou também realizar ações de escrita.

O acesso de escrita pode incluir alterar um marco, criar um registro, enviar informações ou atualizar conteúdo armazenado. Essas operações exigem mais escrutínio do que uma interface gerada pode sugerir.

Uma prévia refinada do Site não prova que suas regras de acesso estejam corretas. Tampouco prova que cada entrada produza a ação esperada no servidor.

Os criadores devem testar registros representativos, níveis de permissão, dados ausentes, entradas inválidas e ações negadas. Também devem verificar os resultados abrindo o Site depois que uma ferramenta realizar uma alteração.

Os controles empresariais adicionam outra camada. A OpenAI afirma que diversas permissões de plugins podem ser gerenciadas de modo independente, incluindo usar plugins, enviar plugins, criar plugins com MCP, compartilhar plugins e publicá-los em um diretório do workspace.

Algumas permissões ficam desativadas por padrão em ambientes Enterprise. Um administrador pode precisar habilitar a função relevante antes que um criador possa publicar um Site ou compartilhar seu plugin.

Esse design limita a distribuição acidental, mas também pode fazer o recurso parecer inconsistente entre contas. Um usuário pode criar e instalar uma ferramenta imediatamente, enquanto outro não consegue ver os controles necessários.

O acesso público merece ainda mais cuidado. A alegação social original sugeria que um criador poderia restringir uma ferramenta a pessoas selecionadas ou compartilhá-la com o mundo. A documentação oficial sustenta o compartilhamento controlado no workspace e uma rota separada de envio público.

Ela não descreve o compartilhamento de plugins pessoais como universalmente aberto. Atualmente, usuários Pro e de contas pessoais não podem convidar diretamente outros usuários do ChatGPT para um plugin hospedado em um Site por meio de um link de compartilhamento.

Membros Business e Enterprise podem compartilhar com colegas, sujeitos às permissões do workspace. Os destinatários precisam ter acesso tanto ao plugin quanto ao Site e, depois, devem instalá-lo e conectá-lo por conta própria.

A distribuição pelo diretório público segue outro processo. Os desenvolvedores enviam um plugin para revisão, atendem aos requisitos de identidade e permissões e só publicam após aprovação.

Os requisitos de revisão da OpenAI exigem um endpoint MCP real e acessível publicamente para envios remotos. A revisão pode inspecionar esquemas de ferramentas, modelos de segurança, anotações, tratamento de dados dos usuários e comportamento esperado.

As orientações de revisão também distinguem operações somente de leitura, destrutivas e de mundo aberto. Essas classificações afetam como os revisores entendem o comportamento e os riscos de uma ferramenta.

Uma ferramenta não pode se tornar somente de leitura apenas porque sua descrição a chama de inofensiva. Suas anotações declaradas e seu comportamento real precisam estar alinhados.

Esse padrão é tão relevante para ferramentas geradas pelo Site quanto para servidores codificados manualmente. A criação em linguagem natural pode reduzir o esforço de implementação, mas não substitui um modelo de segurança preciso.

A maior questão em aberto é quão confiavelmente criadores comuns reconhecerão limites inseguros para ferramentas. Desenvolvedores sabem que uma função de atualização aparentemente pequena pode acionar sistemas posteriores ou expor campos sensíveis.

Usuários menos técnicos podem se concentrar em saber se o fluxo funciona. Talvez não inspecionem campos excedentes nas respostas, efeitos colaterais indiretos ou regras de autorização inconsistentes.

O fluxo gerenciado da OpenAI pode oferecer proteções, mas a documentação ainda atribui ao criador a responsabilidade pelos testes. Ela orienta os proprietários a revisar ferramentas, testar dados de exemplo e verificar resultados antes do compartilhamento.

Isso faz da governança a verdadeira restrição à adoção. Uma ferramenta útil precisa ter tanto uma capacidade clara quanto um limite de permissão defensável.

Casos de uso de servidor MCP do ChatGPT começam pequenos

Os melhores usos iniciais são fluxos de trabalho estreitos, com limites de dados evidentes, ações reversíveis e resultados que os usuários possam inspecionar.

Um manual de equipe é o exemplo mais claro da OpenAI. Um Site pode apresentar o manual, enquanto ferramentas MCP permitem que o ChatGPT pesquise seu conteúdo e recupere seções relevantes durante uma conversa.

Esse caso de uso tem um corpus definido e uma saída relativamente simples. O criador pode comparar a resposta do ChatGPT com o Site subjacente e identificar informações ausentes ou incorretas.

Um painel de projeto oferece um segundo padrão. Ferramentas de leitura poderiam recuperar marcos, responsáveis, bloqueios ou prazos. Uma ferramenta de escrita controlada poderia atualizar o status de um marco após a confirmação do usuário.

Esse fluxo oferece verificação visível. O usuário pode reabrir o painel e confirmar que o registro solicitado foi alterado corretamente.

Localizadores de documentos oferecem outro ponto de partida prático. Um Site poderia expor ferramentas que pesquisam pastas aprovadas, retornam títulos correspondentes e abrem registros aos quais o usuário atual tem acesso.

Essas ferramentas se tornam mais valiosas quando combinadas com boa organização de informações. Um fluxo de trabalho de conhecimento pessoal ou de equipe ainda depende de material-fonte preciso, permissões estáveis e limites claros de recuperação.

Diretórios internos, calendários de lançamento e relatórios de status também se encaixam no modelo. Cada um pode usar um pequeno conjunto de ferramentas com entradas delimitadas e saídas compreensíveis.

Fluxos de trabalho de maior risco exigem mais cautela. Uma ferramenta que envia mensagens, exclui registros, publica conteúdo, altera permissões ou inicia tarefas externas pode produzir consequências fora do Site.

Essas ações devem expor parâmetros claros e exigir confirmação apropriada. Os criadores devem evitar combinar acesso amplo a dados com autoridade ampla de escrita em um único protótipo inicial.

O Site também deve revelar estado suficiente para que os usuários verifiquem os resultados. Uma confirmação conversacional não é evidência suficiente de que uma ação externa foi concluída corretamente.

É aqui que a hospedagem de servidores MCP do ChatGPT difere de um gerador de sites convencional. A saída não é apenas conteúdo ou código de interface. Ela pode se tornar um participante operacional em conversas futuras.

Isso cria um efeito cumulativo. Depois de instalado, o plugin pode ser selecionado sempre que o ChatGPT o considerar relevante ou quando um usuário o mencionar diretamente.

Os metadados, portanto, importam. Os nomes e as descrições das ferramentas devem tornar o escopo pretendido claro. Descrições ambíguas podem levar à seleção da ferramenta errada ou incentivar solicitações inadequadas.

O ambiente gerenciado também muda a iteração. Os criadores podem pedir ao ChatGPT ou ao Codex que adicionem uma nova ferramenta, revisem uma ação existente ou alterem a interface do Site.

Essas mudanças não entram em produção automaticamente. O proprietário deve publicar o Site novamente e, em seguida, confirmar que o plugin expõe a versão esperada da ferramenta.

Esse requisito de publicação cria um ponto de controle útil. As equipes podem revisar capacidades alteradas antes que elas cheguem aos usuários.

No entanto, ele também cria uma possível confusão de versões. Um rascunho do Site, um Site publicado e um plugin instalado podem não refletir sempre o mesmo comportamento esperado.

As equipes devem manter notas de versão simples, casos de teste nomeados e um responsável por cada ferramenta. Mesmo um pequeno plugin interno se beneficia de saber qual versão os usuários estão invocando no momento.

O melhor primeiro projeto, portanto, não é o assistente mais abrangente imaginável. É um fluxo de trabalho focado em que o proprietário possa responder claramente a quatro perguntas:

• Quais informações a ferramenta pode ler?

• O que ela pode alterar?

• Quem pode invocá-la?

• Como os usuários podem verificar o resultado?

Se essas respostas continuarem vagas, uma implantação mais rápida apenas levará a incerteza à produção mais cedo.

Três sinais mostrarão se Sites muda a adoção de MCP

O próximo teste não é quantos Sites serão gerados, mas quantas ferramentas hospedadas se tornarão fluxos de trabalho confiáveis e repetíveis.

O primeiro sinal é a confiabilidade entre superfícies. A OpenAI afirma que o diretório de plugins está disponível na web, em desktop e em dispositivos móveis, enquanto recursos individuais podem variar entre essas superfícies.

Observe se as ferramentas hospedadas no Site se comportam de forma consistente em cada cliente compatível. Instalação, autorização, seleção de ferramentas e saída consistentes reforçariam o argumento para Sites como uma camada geral de implantação de MCP.

Diferenças persistentes entre superfícies enfraqueceriam esse argumento. Os criadores ainda precisariam definir expectativas separadas para usuários de desktop, web e dispositivos móveis.

O segundo sinal é a adoção no workspace. Ambientes Business e Enterprise oferecem compartilhamento controlado, mas os administradores controlam as permissões necessárias.

Observe se as organizações habilitam a criação de Sites, a criação de plugins MCP e o compartilhamento no workspace para grupos amplos de funcionários. A adoção além das equipes de desenvolvimento mostraria que a implantação conversacional atende a uma necessidade operacional genuína.

Políticas padrão restritivas produziriam o resultado oposto. Sites poderiam continuar sendo uma ferramenta de prototipagem se as equipes de segurança não conseguirem auditar com confiança ações geradas e dados conectados.

O terceiro sinal é a qualidade dos plugins públicos. Distribuição privada e publicação pública são caminhos diferentes, e o envio ao diretório inclui uma revisão formal.

Observe plugins apoiados por Sites que evoluem de experimentos pessoais para produtos públicos aprovados. Sua confiabilidade, divulgações de privacidade, práticas de suporte e satisfação dos usuários testarão o modelo gerenciado sob demanda real.

Um fluxo constante de ferramentas aprovadas reforçaria a alegação da OpenAI de que Sites pode apoiar mais do que demonstrações internas. Falhas repetidas de permissão ou comportamento pouco claro das ferramentas exporiam os limites da implantação orientada por prompts.

A incerteza restante é, portanto, prática, não conceitual. A OpenAI documentou o fluxo de criar, hospedar, publicar, instalar e compartilhar. O mecanismo é real.

O que ainda não foi estabelecido é quão bem ele lida com tráfego contínuo, autorização complexa, depuração operacional e manutenção de longo prazo entre muitos criadores.

Para desenvolvedores, o próximo passo imediato é testar um fluxo de trabalho delimitado em comparação com a rota convencional auto-hospedada. Compare o tempo de configuração, a clareza das permissões, o diagnóstico de erros, o controle de atualizações e a cobertura de clientes.

Para compradores empresariais, a prioridade é a governança. Revise quais funções podem criar ferramentas, quem aprova ações de escrita, como as contas conectadas se comportam e quais evidências os usuários recebem após as alterações.

Para trabalhadores do conhecimento, a oportunidade é direta. Um painel interno útil ou uma coleção de referências agora pode se tornar uma ferramenta conversacional sem começar como um projeto de infraestrutura independente.

A mudança dos servidores MCP do ChatGPT importa porque a implantação está se aproximando da própria solicitação. A questão decisiva é se as equipes conseguem manter acesso, testes e propriedade igualmente próximos. Escolha um fluxo de trabalho estreito, defina seus limites antes de criar e teste-o com usuários que tenham permissões diferentes. Essas evidências revelarão se Sites é apenas uma hospedagem mais rápida ou uma rota nova e duradoura para criar ferramentas de IA.