Servidor MCP do Cursor com um ponto vermelho, uma lista de ferramentas vazia ou falhas silenciosas? Leia os logs, corrija erros de PATH e de JSON, ajuste os escopos do token do GitHub, as portas do Figma e os erros do navegador no Playwright, depois teste qualquer servidor com o inspector para que seu agente volte a usar as ferramentas.
Você cola um bloco de servidor em mcp.json, reinicia o Cursor, e o painel de configurações mostra um ponto vermelho ou um ponto verde ao lado de uma lista de ferramentas vazia. O agente segue como se seu servidor do GitHub, do Figma ou do Playwright nunca tivesse existido. Esse silêncio é o que torna a depuração do MCP tão irritante: nada trava, nada se explica, e a correção costuma ser uma linha que você não consegue enxergar pela tela de configurações.
Este artigo percorre as falhas por trás de servidores MCP do Cursor que não funcionam, na ordem que as encontra mais rápido. A primeira seção traz quatro verificações que valem para todos os servidores. Depois vêm as armadilhas específicas do GitHub, do Figma e do Playwright, em seguida os limites de ferramentas, os pedidos de aprovação e uma forma de testar qualquer servidor fora do editor. Cada correção nomeia o sintoma correspondente, para que você vá direto àquela que bate com sua tela.
💡 Uma nota sobre versões: o Cursor e os três servidores mudam rapidamente. Rótulos de menu, flags e URLs mudam entre as versões, então, quando um nome na sua tela for diferente do que está nesta página, confie na saída do seu log mais do que neste artigo.
Antes de culpar um servidor específico, descarte os problemas que quebram todos eles de uma vez. Na maioria dos casos, um destes quatro é o culpado.
Abra o painel Output no Cursor e escolha o canal de logs do MCP no menu suspenso. O nome exato muda entre as versões, mas ele fica junto dos outros canais de Output. O log mostra o comando que o Cursor executou e tudo o que o servidor escreveu em stderr antes de parar. Três mensagens explicam a maioria das falhas:
spawn npx ENOENT: o Cursor não consegue encontrar o executável. Vá para a correção de PATH abaixo.MCP error -32000: Connection closed: o processo iniciou e encerrou na hora, geralmente por causa de um token ausente, de um argumento incorreto ou de uma falha ao iniciar.Request timed out: o servidor está ativo, mas lento, geralmente porque npx está baixando um pacote na primeira execução.💡 Dica: copie as últimas 30 linhas do log antes de mudar qualquer coisa. Cada reinício apaga as evidências de que você precisa se o seu primeiro palpite estiver errado.
O Cursor lê dois arquivos: ~/.cursor/mcp.json, para todos os projetos, e .cursor/mcp.json, dentro do projeto atual. Ambos precisam de JSON estrito, o que significa sem comentários, sem vírgulas sobrando e somente aspas retas. Uma única vírgula fora do lugar pode fazer o Cursor ignorar o arquivo inteiro, sem uma mensagem clara.
{
"mcpServers": {
"github": {
"command": "docker",
"args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"],
"env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_TOKEN}" }
}
}
}
Para verificar um arquivo, execute node -e "JSON.parse(require('fs').readFileSync('.cursor/mcp.json','utf8'))". Ele não imprime nada quando o JSON é válido e aponta a posição exata quando não é. Versões recentes do Cursor expandem os placeholders ${env:NAME} a partir do seu ambiente. Se a sua versão passar o texto literal, o servidor recebe um token falso e falha com um erro de autenticação, então teste com um valor real em um arquivo local, que não seja versionado.
O Cursor aberto pelo dock, pelo menu Iniciar ou pelo Spotlight não lê o perfil do seu shell. Ferramentas instaladas com nvm, fnm ou Homebrew podem ficar invisíveis para ele, mesmo funcionando no seu terminal, e o log mostra spawn npx ENOENT. Substitua o comando simples por um caminho absoluto. Execute which npx no macOS e no Linux, ou where npx no Windows, e cole o resultado:
"command": "/Users/you/.nvm/versions/node/v22.11.0/bin/npx"
O Windows adiciona uma segunda armadilha. npx é um script .cmd, e alguns lançadores não conseguem executá-lo diretamente. Envolva-o em cmd, e sempre passe -y, para que o npx nunca pare para pedir permissão para um download que ninguém consegue ver:
"command": "cmd",
"args": ["/c", "npx", "-y", "@playwright/mcp@latest"]
Editar o arquivo nem sempre reinicia um servidor em execução. Desligue e ligue o servidor em Cursor Settings, Tools & MCP (versões antigas o chamam simplesmente de MCP), ou execute Developer: Reload Window na paleta de comandos. Se o estado antigo persistir, feche o Cursor por completo. Um processo que ficou para trás pode segurar uma porta ou um perfil do navegador e fazer uma inicialização nova falhar por motivos que nada têm a ver com sua configuração.
O GitHub mantém o próprio servidor no repositório github/github-mcp-server, em duas formas: uma local, que roda no Docker, e uma hospedada. Se sua configuração ainda aponta para o antigo pacote npm @modelcontextprotocol/server-github, saia dele. Esse pacote foi descontinuado em favor do servidor próprio do GitHub, e o mais novo recebe as correções e as novas ferramentas.
A falha mais comum do GitHub é um servidor que conecta sem problemas, enquanto cada chamada de ferramenta retorna 401, 403 ou um 404 intrigante. Um 404 em um repositório privado geralmente significa que o token não consegue vê-lo, não que o repositório não exista. Verifique quatro coisas:
repo, e de read:org se você consultar dados da organização.💡 Dica: teste o token fora do Cursor com
curl -H "Authorization: Bearer $GITHUB_TOKEN" https://api.github.com/user. Um perfil em JSON significa que o token funciona, e seu problema está na configuração.
O servidor local precisa do Docker. Três linhas de log apontam para cá: docker: command not found, Cannot connect to the Docker daemon e um timeout enquanto a imagem é baixada. Inicie primeiro o Docker Desktop e depois execute docker pull ghcr.io/github/github-mcp-server uma vez em um terminal, para que o Cursor nunca espere pelo primeiro download. Verifique também a flag -i nos seus args. Ela mantém o stdin aberto, e sem ela o servidor encerra no instante em que inicia. Atrás de um proxy corporativo, o pull de ghcr.io pode falhar mesmo quando outros pulls do Docker funcionam.
Se o Docker continuar dando problemas, mude para o servidor hospedado. Ele não precisa de Docker, de Node nem de configuração de PATH:
"github": {
"url": "https://api.githubcopilot.com/mcp/",
"headers": { "Authorization": "Bearer ${env:GITHUB_TOKEN}" }
}
Um 401 aponta para o token, e um timeout aponta para um proxy ou firewall. O servidor do GitHub também expõe um grande número de ferramentas, o que importa para os limites discutidos mais adiante. O README dele documenta os toolsets, definidos pela variável de ambiente GITHUB_TOOLSETS no servidor local ou por um cabeçalho X-MCP-Toolsets no remoto, para que você carregue apenas repos, issues e pull_requests e deixe o restante de fora.
O Figma oferece duas rotas. A primeira é um servidor local que roda dentro do aplicativo de desktop do Figma. A segunda é um servidor hospedado, com login no navegador. Nomes, portas e caminhos mudaram desde o lançamento, então confirme-os na documentação atual do Figma quando algum passo abaixo não bater com sua tela. As falhas se dividem em três grupos.
O servidor local fica dentro do aplicativo de desktop, não na aba do navegador. O app precisa estar aberto, um arquivo de design precisa estar carregado, e o servidor MCP precisa estar ativado no painel de inspeção do Dev Mode ou nas preferências, dependendo da sua versão. O Figma também vinculou o acesso ao MCP a planos pagos e a tipos específicos de assento, então confirme que seu assento permite isso antes de gastar uma hora na configuração. Quando o app está fechado, o Cursor mostra uma conexão recusada, que parece um servidor quebrado, mas na verdade é um processo ausente.
O servidor local escuta na porta 3845. Versões mais novas respondem em /mcp, e as antigas usavam /sse. Uma configuração que ainda traz o caminho antigo recebe um 404 ou um handshake recusado:
"figma": { "url": "http://127.0.0.1:3845/mcp" }
Use 127.0.0.1 no lugar de localhost. Em algumas máquinas, localhost resolve primeiro para IPv6, e um servidor vinculado a IPv4 recusa essa rota. Se a porta estiver ocupada, descubra quem a usa com lsof -i :3845 no macOS e no Linux, ou netstat -ano | findstr 3845 no Windows. Para a rota hospedada, aponte o Cursor para https://mcp.figma.com/mcp e conclua o login no navegador quando for solicitado. Fechou a aba de login por engano? Desligue e ligue o servidor para reiniciar o processo.
As ferramentas locais agem sobre sua seleção atual ou sobre um link para um frame. Se você pedir ao agente para "construir esta tela" sem nada selecionado, ele recebe uma resposta vazia, o que parece um servidor morto, enquanto a conexão está perfeitamente saudável. Selecione um frame no Figma ou cole o link do frame no seu prompt. Se um frame muito grande der timeout, selecione uma seção menor e construa a tela em partes.
💡 Dica: depois de cada alteração no Figma, faça primeiro uma pergunta simples ao agente, como o nome do frame selecionado. Uma resposta correta prova que toda a cadeia funciona antes de você pedir um layout completo.
O @playwright/mcp da Microsoft é a escolha habitual, e a configuração mínima é curta:
"playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] }
Como ele inicia um navegador de verdade, falha de mais maneiras que os outros dois servidores.
Uma linha de log como Executable doesn't exist ou Chromium distribution 'chrome' is not found significa que nenhum navegador compatível está instalado. Por padrão, o servidor pede o Chrome. Instale o Chrome do jeito normal ou execute npx playwright install chrome em um terminal. O servidor também traz uma ferramenta browser_install, então você pode dizer ao agente para chamá-la quando esse erro aparecer. Para usar outro motor, adicione --browser firefox ou --browser webkit aos args e instale esse motor da mesma forma.
A sessão padrão usa uma pasta de perfil persistente. Uma segunda janela do Cursor, ou um processo do Chrome deixado para trás por uma execução que travou, trava essa pasta, e o log diz que o navegador já está em uso e sugere a flag --isolated. Feche os processos perdidos ou adicione a flag para que cada sessão comece com um perfil novo, em memória:
"args": ["@playwright/mcp@latest", "--isolated"]
Sessões isoladas não guardam logins. Se você precisa continuar conectado a um site, dê ao servidor um perfil dedicado com --user-data-dir.
Contêineres, WSL, sessões SSH e máquinas de CI geralmente não têm tela, então adicione --headless. Como último recurso, dentro de um contêiner rodando como root, --no-sandbox remove o erro do sandbox, ao custo de um isolamento mais fraco. Verifique também a versão do Node, porque o pacote espera o Node 18 ou superior. Por fim, a primeira execução baixa o pacote e inicia um navegador, o que pode exceder o timeout do Cursor. Execute npx @playwright/mcp@latest --help uma vez em um terminal para aquecer o cache, e a próxima inicialização a partir do Cursor será rápida.
Algumas falhas deixam todos os pontos verdes. O servidor está conectado e o agente nunca o usa. Duas causas explicam a maioria desses casos.
Ferramentas demais carregadas. O Cursor já avisou quando a contagem combinada de ferramentas de todos os servidores cresce muito, com um teto histórico em torno de 40 ferramentas, que pode ser diferente na sua versão. Só o GitHub pode expor dezenas. Quando o total ultrapassa o limite, ferramentas de alguns servidores podem nunca chegar ao modelo. Desative os servidores que você não precisa no projeto atual, use os toolsets do GitHub e mantenha enxutos os arquivos .cursor/mcp.json no nível do projeto.
Modo errado ou aprovação sem resposta. As ferramentas do MCP rodam no modo Agent. No modo Ask, o modelo não consegue chamá-las. Por padrão, cada chamada pede aprovação, e se você rolar a tela para longe do pedido, o chat parece travado. Aprove a chamada ou ative a execução automática para os servidores em que você confia. Também abra a entrada do servidor e confirme que nenhuma ferramenta individual foi desligada.
💡 Dica: um bom prompt de teste é explícito: "Use a ferramenta playwright para abrir example.com e me diga o título da página." Citar o servidor elimina qualquer dúvida sobre qual ferramenta o modelo deve escolher.
Execute o MCP Inspector. O inspector oficial inicia qualquer servidor e lista suas ferramentas sem a interferência do Cursor:
npx @modelcontextprotocol/inspector npx -y @playwright/mcp@latest
Se o servidor conecta e lista as ferramentas ali, mas não no Cursor, o problema está no ambiente do Cursor: PATH, variáveis de ambiente ou o arquivo de configuração. Se falha também no inspector, o problema está no servidor ou na sua máquina, e o texto do erro geralmente o identifica.
Deixe um LLM ler os logs. Logs longos são cansativos, e um modelo de linguagem encontra rapidamente a linha relevante. Com o Claude Sonnet 5 no PicassoIA:
REDACTED.O GPT 5.6 Sol serve bem como uma segunda opinião em casos teimosos, e o Gemini 3.5 Flash faz uma primeira triagem rápida de logs muito longos. Tudo o que você cola em um modelo hospedado sai da sua máquina, então oculte segredos antes, sempre.
| Sintoma | Causa provável | Correção |
|---|---|---|
spawn npx ENOENT | O Cursor não encontra o Node no PATH | Use o caminho absoluto para npx |
Connection closed logo após iniciar | Token ausente ou falha ao iniciar | Leia o stderr no log, verifique os valores de env |
| Ferramentas listadas, chamadas retornam 401 ou 403 | Token do GitHub expirado ou com escopo insuficiente | Gere o token de novo e autorize para SSO |
docker: command not found | Docker ausente ou parado | Inicie o Docker Desktop, faça o pull prévio da imagem |
| Figma recusa a conexão | App de desktop fechado ou servidor MCP desligado | Abra um arquivo de design, ative o servidor |
| Figma retorna 404 | Caminho antigo /sse | Troque a URL para /mcp |
| Executável do Playwright ausente | Nenhum navegador compatível instalado | Execute npx playwright install chrome |
| Navegador do Playwright já em uso | Pasta de perfil travada | Feche os processos perdidos ou adicione --isolated |
| Ponto verde, agente ignora as ferramentas | Ferramentas demais, ou modo Ask | Reduza os servidores, mude para o modo Agent |
Quando seus servidores estiverem funcionando, o MCP fica interessante muito além do código. O PicassoIA também expõe seus modelos de geração por meio de uma conexão MCP própria e de uma API para desenvolvedores, baseada em quatro modelos: PicassoIA Image, Image Editor Pro, PicassoIA Video e Seedance 2.5 Lite para vídeo com áudio. Você configura a conexão na página MCP da sua conta em picassoia.com/en/mcp/accounts, e ela se comporta como qualquer outro servidor no Cursor, então todas as verificações acima também se aplicam a ela.
Um limite vale a pena conhecer quando os trabalhos parecem travar: uma conta roda até 5 predições ao mesmo tempo, compartilhadas entre todas as suas credenciais e conexões MCP. Um sexto trabalho espera na fila, e a partir do editor isso pode parecer um servidor travado.
Você não precisa de um servidor MCP para começar, no entanto. Abra o aplicativo web, escreva um prompt e veja um resultado em segundos:
Escolha uma necessidade real do seu último projeto, como uma imagem de destaque para um README, um cabeçalho para um post de blog ou uma foto de produto fictícia para uma demonstração, e gere três versões. Compare-as, mude um detalhe por vez e fique com a que se encaixa. Abra o Picasso IA, escreva seu primeiro prompt e veja como fica seu próximo projeto.
Escolha seu idioma
