Checklist de Prontidão para Apps MCP da OpenAI

O SDK de Apps da OpenAI não é mais apenas uma curiosidade para desenvolvedores de widgets de demonstração. A documentação atual o descreve como uma estrutura para construir aplicativos para o ChatGPT, com um servidor MCP, metadados de ferramentas, UI incorporada, autenticação, testes e um caminho de submissão para distribuição pública. A questão prática para um fornecedor de SaaS ou equipe de plataforma interna não é "podemos fazer uma demonstração?" É "o que deve ser verdade antes que um administrador permita que o ChatGPT chame nossas ferramentas?"

Este guia responde a essa questão de prontidão para um piloto de aplicativo MCP interno. Ele é baseado na documentação oficial da OpenAI e em uma pequena verificação da API da OpenAI do Effloow Lab contra um plano de aplicativo de suporte a tickets sintético. A verificação do laboratório não conectou um aplicativo real ao Modo de Desenvolvedor do ChatGPT, não executou um locatário OAuth, não escaneou ferramentas ao vivo e não submeteu um aplicativo. Esses fatos de tempo de execução permanecem [DADOS NÃO DISPONÍVEIS].

Nota do laboratório público: /lab-runs/openai-apps-sdk-internal-mcp-app-readiness-2026

Por Que Isso Importa

O SDK de Apps muda a superfície de revisão para fornecedores de ferramentas de IA. Uma integração normal de API é julgada principalmente por endpoints, escopos, logs e tempo de atividade. Um aplicativo ChatGPT também deve ser julgado por quão bem o modelo descobre ferramentas, quão seguramente ele pede ações de escrita, como a UI incorporada se comporta na conversa e como os administradores controlam o acesso após a publicação.

Isso importa porque o Centro de Ajuda da OpenAI afirma que o suporte completo ao MCP, incluindo ações de escrita ou modificação, está sendo lançado em beta para os planos Business, Enterprise e Edu do ChatGPT. Ele também diz que administradores e proprietários controlam o modo de desenvolvedor e a publicação, enquanto os espaços de trabalho Enterprise e Edu recebem controles RBAC adicionais para acesso de desenvolvedor e disponibilidade de aplicativos. A disponibilidade Business, Enterprise e Edu deve ser tratada como uma orientação atual baseada em fonte, não uma garantia de que um espaço de trabalho ou conta específica tenha o recurso habilitado hoje.

Para os compradores, o risco é a aquisição por captura de tela. Um fornecedor pode mostrar um componente ChatGPT polido enquanto deixa as perguntas difíceis sem resposta: quem pode publicar o aplicativo, quais ferramentas estão congeladas após a aprovação, o que acontece quando o esquema MCP muda, como o refresh do OAuth é tratado e se as ações de escrita produzem logs de auditoria.

A recomendação do Effloow é tratar um piloto do SDK de Apps como um projeto de integração governado, não um lançamento de marketing. Comece com um caso de uso interno restrito, colete evidências em camadas e só passe de "pronto para fonte" para "pronto para piloto" após ter registros reais do Modo de Desenvolvedor e logs de chamadas de ferramentas.

O Que o SDK de Apps Realmente Adiciona

O SDK de Apps usa o MCP como a espinha dorsal entre o ChatGPT, seu servidor e sua UI. A documentação do SDK de Apps da OpenAI descreve o MCP como uma especificação aberta para conectar clientes LLM a ferramentas e recursos. Para o SDK de Apps, um servidor MCP mínimo anuncia ferramentas, aceita chamadas de ferramentas com argumentos estruturados e pode retornar componentes que o ChatGPT renderiza como uma interface.

Isso dá a um aplicativo ChatGPT três superfícies para revisar:

1. O contrato da ferramenta: nomes, descrições, esquemas de entrada, esquemas de saída, anotações e requisitos de autenticação.
2. O tempo de execução do servidor: endpoint HTTPS, transporte MCP, autorização, registro, limites de taxa, tentativas e isolamento de locatário.
3. A experiência do componente: UI incorporada, restauração de estado, minimização de dados, comportamento CSP e tratamento de erros.

O quickstart da OpenAI mostra um servidor MCP Todo expondo um /mcp endpoint, registrando ferramentas de aplicativo, retornando conteúdo estruturado e servindo um widget. O aplicativo de amostra exato não é um padrão de produção para suporte, CRM, faturamento ou dados de DevOps. Seu valor é arquitetônico: ele mostra que um aplicativo do SDK de Apps não é "apenas um prompt." É um servidor mais esquemas mais recursos de UI mais comportamento de implantação.

Para um fornecedor de SaaS, a primeira pergunta de prontidão é, portanto, simples: você pode descrever seu aplicativo sem mencionar o ChatGPT? Se a resposta for não, o aplicativo provavelmente é muito vago. O aplicativo deve ter um fluxo de trabalho de domínio claro, como:

• Pesquisar e resumir tickets de suporte.
• Criar uma resposta de cliente em rascunho.
• Abrir um ticket de incidente de implantação.
• Atualizar um estágio de CRM após confirmação do usuário.
• Buscar contexto de conta para uma conversa de triagem de suporte.

O aplicativo não deve começar com poderes amplos como "gerenciar todo o nosso sistema de clientes." Ferramentas amplas tornam a descoberta barulhenta, permissões difíceis de explicar e aprovações mais difíceis de auditar.

Evidências do Effloow Lab

O Effloow Lab realizou uma verificação limitada da API da OpenAI em 9 de junho de 2026 usando um plano de aplicativo de suporte a tickets sintético. O prompt pediu ao modelo para avaliar lacunas de prontidão para um aplicativo não confidencial com quatro ferramentas: search_tickets, get_ticket, create_ticket e update_ticket_status. O plano sintético incluiu OAuth 2.1 com PKCE, escopos tickets:read e tickets:write por usuário, um componente de detalhe de ticket incorporado e um alvo de piloto interno.

O artefato salvo registra o modelo gpt-5.5-2026-04-23, 270 tokens de entrada, 1.400 tokens de saída e status de resposta incompleto porque a saída atingiu o limite de tokens configurado. Isso significa que a saída do laboratório é útil para revelar lacunas prováveis, mas não é uma auditoria completa e não é evidência de que qualquer aplicativo real do ChatGPT funcione.

A verificação da API identificou cinco lacunas de alto valor:

• Nenhuma conexão real do Modo de Desenvolvedor foi testada.
• Nenhuma evidência de escaneamento de ferramentas ou validação de esquema existia.
• Nenhuma evidência de sessão MCP de ponta a ponta existia.
• O componente incorporado não foi verificado dentro do ChatGPT.
• O comportamento do locatário OAuth, a aplicação de escopos, a autorização por usuário e a instalação do administrador do espaço de trabalho permaneceram não comprovados.

Essas descobertas correspondem à ênfase da documentação oficial em testes, metadados OAuth, revisão de segurança e controles administrativos. Elas também mostram por que um comprador deve pedir artefatos de evidência, não apenas um roteiro de produto.

O artigo não afirmará que o Effloow instalou um aplicativo do SDK de Apps no ChatGPT, submeteu um aplicativo, verificou um fluxo de aprovação de espaço de trabalho ou testou o comportamento móvel. Esses fatos são [DADOS NÃO DISPONÍVEIS] para esta execução.

Lista de Verificação de Prontidão Principal

Use esta lista de verificação antes de chamar um projeto do SDK de Apps de "pronto para piloto."

A linha de item mais difícil geralmente não é o endpoint MCP. É a disciplina de evidência. Um fornecedor deve ser capaz de entregar um pequeno pacote de revisão:

• Links de origem para a documentação da OpenAI utilizada.
• Lista de ferramentas e exportação de esquema.
• Conjunto de prompt de ouro para seleção de ferramentas diretas, indiretas e negativas.
• Capturas de tela ou logs do Modo de Desenvolvedor do ChatGPT.
• OA