- O modo Developer é um recurso beta que oferece um cliente MCP completo (leitura/escrita) para todas as ferramentas, voltado a desenvolvedores que querem testar com segurança configurações avançadas de conectores
- Ao usar, é preciso ter atenção aos riscos de prompt injection e MCP malicioso, além de erros destrutivos em ações de escrita; por isso, o processo de revisão e aprovação de payloads antes da chamada de ferramentas é importante
- A ativação é feita em Settings → Connectors → Advanced → Developer mode na web, e é possível adicionar servidores MCP remotos para importar ferramentas e gerenciar alternâncias
- Durante a conversa, ao selecionar Developer mode e instruir explicitamente conectores e ferramentas, fica mais fácil escolher a ferramenta correta; técnicas de prompt como schema de entrada e definição de ordem são eficazes
- Ações de escrita exigem aprovação por padrão, e ferramentas sem a anotação readOnlyHint são tratadas como ferramentas de escrita; por isso, é necessário operar com cautela do ponto de vista de prevenção de uso indevido e proteção de dados
Visão geral
- Definição: o Developer mode do ChatGPT é um modo beta que fornece a função de cliente com permissões de leitura/escrita para todos os conectores e ferramentas MCP conectados
- Público-alvo: disponível para usuários Pro/Plus que saibam configurar e testar conectores com segurança
- Atenção: há riscos de segurança como prompt injection, destruição de dados por erros de escrita do modelo e MCP voltado ao roubo de informações
Ativação e importação de MCP
- Caminho de ativação: ative em Settings → Connectors → Advanced → Developer mode
- Adicionar servidor MCP: ao registrar um servidor MCP remoto na aba Connectors das configurações, ele aparece no seletor de ferramentas do Developer mode na conversa
- Protocolo: suporte a SSE e streaming HTTP
- Autenticação: suporte a OAuth ou sem autenticação
- Sincronização de ferramentas: na tela de detalhes do conector, é possível usar o toggle On/Off das ferramentas e o Refresh para buscar a lista e as descrições mais recentes
Diretrizes de uso de ferramentas na conversa
- Chamada explícita: instrua de forma específica, como em “use update_record do conector Acme CRM para …”
- Proibir alternativas: explicite condições de proibição, como “não use navegação embutida, use apenas Acme CRM”, para evitar confusão
- Diferenciar ferramentas semelhantes: defina regras de prioridade, como “para reuniões, priorize Calendar.create_event; Reminders.create_task é proibido”
- Fixar schema de entrada e ordem: detalhe a sequência de chamadas e o formato do payload, como “primeiro Repo.read_file { path }, depois Repo.write_file …”
- Preferência por conectores aninhados: declare políticas de origem dos dados, como “para dados de permissão, priorize CompanyDB; só use a fonte auxiliar em caso de falha”
- Melhorar a orientação ao modelo: se o servidor MCP fornecer descrições de ferramenta e comentários de parâmetros orientados a ação com ‘Use this when …’, a precisão na escolha da ferramenta melhora
Exemplos de prompt
- Criar agenda: “crie uma reunião amanhã às 15h PT por 30 minutos com Calendar.create_event; não use outras ferramentas de agendamento”
- Criar PR: “use GitHub.open_pull_request para feat-retry → main, especificando título e corpo, e não faça push direto para main”
Fluxo de revisão e aprovação
- Verificação de chamada de ferramenta: expanda as entradas e saídas JSON de cada chamada para fazer validação de payload e debug
- Ações de escrita exigem aprovação por padrão: como entradas incorretas podem levar a destruição ou vazamento de dados, é necessário reconfirmar antes do envio
- Identificação de somente leitura: apenas ferramentas com a anotação readOnlyHint são tratadas como ferramentas de leitura; ferramentas sem anotação são consideradas de escrita
- Opção de lembrar aprovação: durante a conversa, é possível lembrar aprovação/negação de ferramentas específicas, mas isso deve ser permitido apenas para aplicações confiáveis
- Escopo da sessão: ao iniciar uma nova conversa ou recarregar a página, a memória de aprovação é reiniciada
Modelo de risco e práticas de segurança
- Defesa contra prompt injection: não confie em resultados/conteúdos de MCP sem validação e evite a exposição de segredos e tokens
- Princípio do menor privilégio: exponha ferramentas de escrita com o mínimo de permissões e configure ações de alto risco para exigir aprovação explícita
- Higiene de conectores: documente com clareza descrições de ferramentas, schemas e casos de erro para reduzir uso indevido e seleção incorreta de ferramentas embutidas
Dicas operacionais
- Guia de seleção de ferramentas: inclua nas descrições “quando esta ferramenta deve ser usada” e casos proibidos/de borda para deixar claras as heurísticas de seleção do modelo
- Desenho de sequência: fixe no prompt o ciclo leitura → validação → escrita para garantir transições de estado seguras
- Métricas de monitoramento: registre taxa de falha, taxa de rollback e tentativas de contornar aprovações para observar o risco operacional
Resumo
- O Developer mode é um poderoso recurso beta capaz de chamar todas as ferramentas MCP com leitura/escrita
- Para segurança e proteção, são essenciais instruções explícitas, processo de aprovação, menor privilégio e melhora na qualidade das descrições das ferramentas
- Com disciplina adequada de prompts e um fluxo de revisão, torna-se possível fazer automação end-to-end de tarefas e orquestração precisa de conectores
Ainda não há comentários.