Uma lista ranqueada dos melhores servidores MCP para o Codex, do OpenAI Docs MCP e Context7 ao GitHub, Playwright, Chrome DevTools e Figma. Inclui trechos de config.toml prontos para colar, configurações de aprovação que mantêm o acesso de escrita sob controle e um jeito de adicionar geração de imagens ao seu conjunto de ferramentas.
O Codex escreve código bem sozinho. O que ele não consegue fazer sozinho é ler a documentação da versão da biblioteca que você instalou esta manhã, abrir um pull request, clicar pelo seu checkout ou olhar para o erro que disparou em produção há uma hora. Os servidores MCP fecham essa lacuna. Cada um entrega ao Codex um conjunto de ferramentas pelo Model Context Protocol, e o punhado certo transforma um assistente capaz em um que consegue levar um chamado da descrição até a mudança integrada.
Este ranking é construído em torno do que os desenvolvedores usam em projetos reais: documentação, controle de código-fonte, navegadores, arquivos de design e rastreamento de erros. Ele parte da própria documentação do Codex da OpenAI, que indica uma lista curta de servidores recomendados, e depois acrescenta os extras que merecem um lugar em um fluxo de trabalho real. Ao longo do caminho, você recebe config.toml trechos para colar, uma forma de manter as permissões apertadas e um olhar sobre como adicionar geração de imagens ao mesmo conjunto de ferramentas.
💡 Resposta rápida: instale primeiro o OpenAI Docs MCP, o Context7, o GitHub e o Playwright. Adicione o Chrome DevTools, o Figma e o Sentry somente quando um projeto precisar deles.
O Codex lê suas configurações de ~/.codex/config.toml. Esse arquivo único é compartilhado pela CLI, pela extensão da IDE e pelo aplicativo de desktop, então um servidor que você registra uma vez aparece em todos os lugares. Cada servidor ganha sua própria tabela [mcp_servers.<name>], e o Codex se conecta aos habilitados na inicialização.
Um servidor MCP é um pequeno programa, ou um endpoint hospedado, que anuncia uma lista de ferramentas. O Codex se conecta, lê essa lista e pode chamar essas ferramentas no meio de uma tarefa. Um servidor do GitHub expõe ações de pull request. Um servidor de documentação expõe busca. O Codex decide quando chamar uma ferramenta, e suas configurações de aprovação decidem se ele precisa perguntar antes.
O efeito prático são menos suposições. Em vez de escrever com base em uma versão de API que ele lembra, o assistente consulta. Em vez de dizer que uma correção "deveria funcionar", ele abre um navegador e verifica.
O transporte depende dos campos que você escreve. Um command significa que o Codex inicia um processo stdio local. Um url significa que ele se comunica com um servidor HTTP streamable remoto.
| Servidor stdio | Servidor HTTP streamable | |
|---|---|---|
| Selecionado por | command | url |
| Executa | Um processo local que o Codex inicia | Um serviço remoto |
| Configuração típica | Pacote npx mais args | OAuth ou um token bearer |
| Credenciais | env ou env_vars | auth (OAuth por padrão) ou bearer_token_env_var |
| Ideal para | Consultas de documentação, navegadores, arquivos locais | Serviços hospedados como rastreadores de problemas |
💡 Para servidores remotos que usam OAuth, execute
codex mcp loginuma vez. Dentro da interface de terminal,/mcpmostra quais servidores estão ativos agora.
A ordem abaixo segue duas regras. Servidores que apenas leem ficam acima dos que escrevem. Servidores que tiram o Codex de informações desatualizadas ficam acima dos que apenas economizam um clique. Cinco dos seis vêm diretamente da lista que a OpenAI recomenda na documentação do Codex.
| Posição | Servidor | Ideal para | Risco de escrita |
|---|---|---|---|
| 1 | OpenAI Docs MCP | Respostas atuais sobre a API e o Codex da OpenAI | Muito baixo |
| 2 | Context7 | Documentação de bibliotecas por versão | Muito baixo |
| 3 | GitHub | Pull requests, issues, execuções de CI | Médio |
| 4 | Playwright | Controlar um navegador real | Médio |
| 5 | Chrome DevTools | Console, rede, desempenho | Baixo |
| 6 | Figma | Construir a partir de arquivos de design reais | Baixo |
Um ranking só diz o que é bom em geral. O que você instala primeiro depende do projeto diante de você:
| Tipo de projeto | Instale primeiro | Adicione depois |
|---|---|---|
| App front-end de uma pessoa só | Context7, Playwright, Chrome DevTools | Figma |
| Serviço de API no back-end | Context7, GitHub, Sentry | Um servidor de banco de dados somente leitura |
| Repositório de equipe com CI | GitHub, Linear, Context7 | Playwright, Sentry |
Se o próprio app chama APIs da OpenAI, adicione o OpenAI Docs MCP a qualquer linha. Ele custa quase nada e evita toda uma classe de bugs de parâmetros desatualizados.
O Codex conhece o que foi treinado para conhecer, e isso pode estar defasado em relação a um parâmetro renomeado ou a um novo endpoint. O servidor de documentação da OpenAI permite que ele consulte a documentação atual em vez de adivinhar. Ele só lê, então há quase nada que possa dar errado.
Se o seu app chama APIs da OpenAI, ou se você faz perguntas ao Codex sobre a própria configuração, esta é a instalação de maior retorno da lista. Ela ganha o primeiro lugar por ser ao mesmo tempo útil e quase sem riscos.
O Context7 busca documentação atual e específica por versão de bibliotecas e frameworks e a coloca no contexto sob demanda. Ele ataca a falha mais comum de agentes: escrever com confiança para uma API que mudou duas versões principais atrás.
Um comando o registra:
codex mcp add context7 -- npx -y @upstash/context7-mcp
Ou escreva a mesma coisa à mão, com uma janela de inicialização mais longa para o primeiro download de npx:
[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
startup_timeout_sec = 20
💡 Adicione uma linha ao seu
AGENTS.md, como "use o Context7 para a documentação das bibliotecas", para que o Codex recorra a ele sem que você precise pedir toda vez.
Para a maioria das equipes, o servidor oficial do GitHub é a conexão de maior impacto depois da documentação. O Codex pode ler e comentar pull requests, pesquisar código em vários repositórios, triar issues e inspecionar execuções de CI com falha. Isso transforma "por que o build está vermelho?" de uma caça de dez minutos entre abas em um único prompt.
Também é o primeiro servidor desta lista que pode alterar coisas, então configure-o com cuidado:
[mcp_servers.github]
url = "https://api.githubcopilot.com/mcp/"
bearer_token_env_var = "GITHUB_MCP_TOKEN"
default_tools_approval_mode = "prompt"
Confirme o endpoint no README do próprio GitHub antes de copiar, porque URLs hospedadas podem mudar. Guarde o token em uma variável de ambiente, limite-o aos repositórios em que você realmente trabalha e comece com acesso de leitura.
O servidor Playwright da Microsoft dá ao Codex um navegador real para controlar. Ele abre páginas, preenche formulários, clica em controles, lê a página pela árvore de acessibilidade e mantém o estado do navegador durante uma sessão de depuração. A diferença aparece na redação da resposta: "eu fiz a mudança" vira "eu fiz a mudança e confirmei que ela renderiza".
[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]
Use-o para fluxos de checkout, validação de formulários e qualquer coisa em que o bug só aparece depois de três cliques. Como ele pode enviar formulários e clicar em botões, aponte-o para um site de staging, não para a produção.
A documentação da OpenAI lista o Chrome DevTools e o Playwright como alternativas, mas eles resolvem problemas diferentes. O Playwright automatiza um fluxo. O DevTools inspeciona uma página. Quando a pergunta é "por que isso está lento?" ou "qual é esse erro no console?", o servidor do DevTools permite que o Codex olhe o painel de rede, o console e os dados de desempenho, em vez de raciocinar apenas a partir do código-fonte.
Muitos projetos acabam usando os dois. Se você só puder escolher um, fique com o Playwright para trabalho no estilo de testes e com o DevTools para bugs de desempenho e renderização.
Sem um servidor de design, o Codex constrói a partir de uma captura de tela ou da sua descrição, e o espaçamento se desvia. Com o servidor do Figma, ele consegue puxar informações estruturadas do próprio arquivo: layout, espaçamento, cores e estrutura de componentes. O resultado é um primeiro rascunho muito mais próximo do que o designer entregou.
Ele fica em último na lista curta apenas porque importa para menos projetos. Em uma equipe de front-end com um arquivo de design vivo, ele pode subir para o segundo lugar.
Quando os seis principais estiverem estáveis, algumas conexões extras valem a pena em tipos específicos de trabalho. Consulte a documentação atual de cada fornecedor para o endpoint e os escopos de permissão, já que essas coisas mudam mais rápido do que um post de blog consegue acompanhar.
O Sentry publica um servidor MCP que pode entregar ao Codex stack traces e erros recentes, então um relato de bug começa com a falha real, e não com uma paráfrase. O Linear também publica um, que permite ao Codex ler o texto do chamado e os critérios de aceitação antes de escrever qualquer coisa. Juntos, eles fecham o ciclo: o erro diz o que quebrou, o chamado diz o que significa "corrigido".
Servidores de banco de dados merecem um alerta. Um servidor conectado a um banco de produção transforma um erro de digitação em um incidente. Aponte-o para uma réplica somente leitura ou para uma cópia local, e mantenha todas as ferramentas de escrita desabilitadas.
Você pode adicionar servidores de duas formas, e elas produzem o mesmo resultado.
A linha de comando é o caminho mais rápido para um único servidor:
# local stdio server
codex mcp add playwright -- npx @playwright/mcp@latest
# remote streamable HTTP server
codex mcp add github --url https://api.githubcopilot.com/mcp/
# see what is configured, and log in to OAuth servers
codex mcp list
codex mcp login github
codex mcp add grava no mesmo config.toml, e você pode passar --env NAME=VALUE para servidores locais que precisam de variáveis de ambiente. Execute codex mcp --help para a lista completa de comandos.
Depois de cada instalação, faça as mesmas três verificações antes de confiar em um servidor:
/mcp e confirme que o servidor aparece como ativo.Se a primeira etapa falhar, a causa costuma ser um timeout na inicialização, uma variável de ambiente ausente ou um pacote que precisa do primeiro download. Resolva isso antes de adicionar o próximo servidor, assim você sempre sabe qual mudança quebrou o quê.
Para uma stack que você vai reutilizar, edite o arquivo. Isso também permite definir as opções que a CLI não pergunta. Estas são as que mais importam:
| Campo | Padrão | O que faz |
|---|---|---|
startup_timeout_sec | 10 | Quanto tempo o Codex espera para um servidor iniciar |
tool_timeout_sec | 60 | Quanto tempo uma única chamada de ferramenta pode durar |
enabled | on | Desliga um servidor sem apagá-lo |
required | off | Faz a inicialização falhar se o servidor não puder ser inicializado |
enabled_tools | all | Lista de permissão das ferramentas que o Codex pode usar |
disabled_tools | none | Lista de bloqueio das ferramentas que o Codex não pode usar |
default_tools_approval_mode | varies | auto, prompt, writes ou approve |
Cada servidor conectado amplia o que o assistente pode tocar. Alguns hábitos mantêm isso sob controle.
Um servidor pode expor dezenas de ferramentas, e você raramente precisa de todas. Use enabled_tools para listar exatamente o que o Codex pode chamar, ou disabled_tools para remover as poucas perigosas. Uma lista menor de ferramentas também significa menos texto para o modelo ler e menos escolhas erradas.
Marque required = true apenas para servidores sem os quais uma tarefa não pode funcionar. Se um servidor que seria apenas um extra falhar ao iniciar, você quer que o Codex continue, e não que pare.
O campo default_tools_approval_mode aceita quatro valores na documentação: auto, prompt, writes e approve. Leia a página de referência para o comportamento exato de cada um antes de confiar em algum. Como regra prática, use um modo que pergunte para qualquer servidor que possa criar, editar ou apagar coisas, e deixe os servidores de documentação somente leitura em uma configuração mais flexível.
💡 Uma política inicial sensata: servidores de documentação em um modo relaxado, GitHub e Playwright configurados para perguntar, servidores de banco de dados somente leitura com escrita desabilitada.
O Codex pode escrever uma página de destino, mas não consegue pintar a imagem principal. O PicassoIA oferece uma conexão MCP e uma API para desenvolvedores, para que um assistente possa gerar visuais como parte da mesma tarefa. Os detalhes da conexão ficam na página de conexões MCP da sua conta no PicassoIA, que exige login.
Quatro modelos estão disponíveis pela API e pela conexão MCP:
A URL do servidor não é publicada nas páginas públicas do PicassoIA, então copie-a da sua conta. Se ela fornecer uma URL remota, registre-a com a flag --url mostrada acima e depois confirme que ela aparece em /mcp antes de construir um fluxo de trabalho em cima dela.
A API é assíncrona: você cria uma previsão, consulta o status dela e depois busca o resultado. Planeje considerando estes limites:
Aqui vai um padrão de prompt que vale testar quando a conexão estiver funcionando: peça ao Codex para construir a seção principal de uma página, depois para chamar a ferramenta de imagem com um prompt fotográfico em 16:9 que combine com o tema da página e, por fim, para referenciar a URL da imagem retornada no markup. Uma tarefa só, sem trocar de aba, e o briefing da imagem vem do mesmo contexto do texto.
Se uma chamada de geração expirar dentro do Codex, aumente tool_timeout_sec para esse servidor. Páginas de preços e documentação da API descrevem o acesso em termos um pouco diferentes, então confira os requisitos do plano para a sua conta antes de depender disso.
Para o lado de texto, o PicassoIA também hospeda modelos de chat como GPT 5.6 Sol e Claude Sonnet 5, úteis para rascunhar um AGENTS.md ou comparar duas abordagens antes de passar a tarefa para o Codex.
bearer_token_env_var ou env_vars para que os segredos fiquem fora de um arquivo que você possa commitar.npx baixa um pacote, e dez segundos podem ser pouco. Aumente startup_timeout_sec./mcp. Um servidor que falhou silenciosamente ao iniciar parece exatamente um servidor que o Codex decidiu não usar.Escolha três servidores da lista curta, registre-os e dê ao Codex uma tarefa real: um teste que falha, uma dependência desatualizada, uma página com aparência errada no celular. Em uma hora você saberá quais merecem o lugar.
Depois, dê mais um passo. Abra o PicassoIA, gere uma imagem principal com o PicassoIA Image e a coloque na página que o Codex acabou de construir. Experimente prompts diferentes, teste o editor sobre o resultado e veja quanto de um lançamento dá para concluir em uma única sentada.
Escolha seu idioma
