Este artigo explica como operar WordPress em produção (Hostinger e similares) a partir do Cursor, usando SSH, WP-CLI e um MCP fino, sem instalar plugin de agente no site. Serve a freelas e agências que já usam o IDE e não querem mudar a superfície do cliente. O laboratório público é o próprio IA+WP.
No local, tema e conteúdo já fluem no Cursor. Em produção, o contexto muda: outra porta SSH, LiteSpeed no lugar do cache flush do core, e a decisão de não instalar plugin de agente só para o IDE falar com o WordPress. Se você não controla o stack de plugins do cliente, o canal é SSH, não o Adapter oficial.
Documentei o caminho que testei no próprio IA+WP em produção: SSH + WP-CLI no servidor, registry multi-site, guardrail de escrita e MCP fino no Cursor. Não é improvisação no ar. É operação com canal e limites.
O gap: agente no IDE, site na shared
No local (Studio ou Local) o wp está perto. Em shared Hostinger o wp também existe, mas atrás de SSH. A maior parte dos tutoriais de “Cursor + WordPress” para no Adapter oficial (plugin + Application Password): ótimo para produto e sites sob seu controle total. No dia a dia de freela/agência, instalar isso em todo cliente só para o seu Cursor é invasivo.
Eu precisei do contrário: diagnosticar e operar sem mudar a superfície do site. O IA+WP (iaewp.com.br) é o laboratório público desse fluxo, alinhado ao pilar IA e WordPress: a combinação estratégica de 2026.
O que o diagnóstico mostrou (fatos, não slide)
Com o canal só em leitura, o IA+WP mostrou (agosto/2026):
| Item | Em produção no IA+WP |
|---|---|
| WordPress | 7.0.2 |
| Tema ativo | digital-vanguard 0.2.0 (tema próprio) |
| Cache | LiteSpeed Cache 7.8.1 |
| SEO | The SEO Framework (Autodescription) 5.1.4 |
| Segurança | Wordfence + WPS Hide Login |
| Backup | UpdraftPlus |
| Analytics | Site Kit |
| Outros | Jetpack, Hostinger, CompressX, Social Sharing Block |
| Conteúdo | 1 post publicado (o artigo pilar) · páginas Home, Blog, Privacidade, Termos |
wp-remote com 3 tools; ao lado, o mesmo diagnóstico resumido em tabela no chat.Stack moderna, tema de bloco, performance e segurança no ar, e zero superfície de agente no servidor. O agente fala com o site pelo mesmo wp que você usaria no SSH.
Arquitetura do canal
Cursor → MCP (opcional) → Proa (CLI) → SSH → wp no servidor → WordPressTrês peças:
- Registry privado (
wp-sites.json): slug, host, porta, path. Chave SSH. Sem senha no arquivo. - CLI Proa:
proa ia-wp plugin list, o mesmo hábito mental dostudio wp/ Local. - MCP fino: só tools globais (
list_sites,site_info,wp_cli). Receita de um projeto específico não entra no catálogo de tools do MCP.
O código aberto está em github.com/silvaitamar/proa-wp. A primeira lição veio de colocar receita demais no MCP.
Lição de arquitetura: MCP global ≠ receita de projeto
No primeiro protótipo, uma tool de “cores de badge de categoria” entrou no MCP. Funcionava no site que tinha aqueles term metas. No segundo site do registry (o próprio IA+WP), gerava falsos positivos: o agente via a tool e tentava usá-la onde o tema não implementa isso.
Regra:
| Camada | O quê |
|---|---|
| MCP | O que serve a qualquer site com SSH + wp |
| CLI + docs | Flags e receitas atrás de capabilities no registry |
Com vários sites no mesmo Cursor, o MCP deixa de ser um pacote por cliente. Com o catálogo limpo, falta o segundo limite: a escrita.
Guardrail: ler por padrão, escrever com intenção
O wrapper exige --write (no MCP: write: true) para mutação. Default = diagnóstico. Ainda assim: sem db reset, sem search-replace em massa, sem eval solto “porque o agente quis”. O agente acelera; você autoriza o que altera o site em produção.
No IA+WP, depois de mudar conteúdo ou opções visíveis, o purge que importa costuma ser o do LiteSpeed (litespeed-purge), não só cache flush do core. O core limpa o próprio cache; o visitante ainda pode ver a página antiga servida pelo LiteSpeed. Isso entra no menu de ops, não como tool mágica.
No dia a dia, isso vira um menu curto.
Menu curto (o que eu exercito de verdade)
| Ops | Exemplo |
|---|---|
| Diagnóstico | option get home, core version, theme list, plugin list |
| Conteúdo | post get / post list |
| Cache | litespeed-purge (quando o plugin expõe) |
| SEO | post meta do plugin ativo (no IA+WP: Autodescription), com copy já revisado |
| Meta de termo | term meta get/update quando o tema usa |
Quoting importa (hex, espaços, PowerShell→WSL). O que falhou uma vez vira nota operacional; na segunda, o agente não cai no mesmo erro.
No chat, o pedido muda de forma.
O que muda no chat
Em vez de “cola esse bash”, o pedido vira:
Via MCP, no site do IA+WP,
option get homee plugins ativos. Sem write.
Tools em sequência. Paralelo em SSH/stdio trava. Depois de editar o server MCP, às vezes só desligar e ligar o servidor MCP ou subir a versão no mcp.json reinicia o processo de verdade.
O que este artigo não é
- Substituto de revisão humana em SEO ou conteúdo
- “Cursor controla meu WordPress” via plugin no ar do cliente
- Curso genérico de Cursor
- WebMCP (tools no browser do visitante): outro problema
Limite honesto
Do que já está fechado: SSH Hostinger, registry com mais de um site, CLI com --write, MCP com tools globais, Proa público em MIT, diagnóstico ao vivo do IA+WP (WP 7.0.2 + stack acima).
Ainda em evolução: hábitos de sync entre o que uso no dia a dia e o que está no GitHub, e mais sites no registry. O Adapter oficial do WordPress continua backlog separado deste canal de ops.
Perguntas frequentes
Dá para usar Cursor no WordPress em produção sem instalar plugin de MCP?
Sim. O caminho deste artigo é SSH + WP-CLI no servidor, com um MCP opcional no Cursor que só dispara o CLI. Nada de plugin de agente no site do cliente.
Como rodar WP-CLI na Hostinger via SSH a partir do Cursor?
Com chave SSH no hPanel (porta típica 65002), um registry com host/path do site e um wrapper (Proa/`proa`) que entra no servidor e executa wp. No Cursor, o MCP fino chama esse mesmo wrapper.
Qual a diferença entre o MCP Adapter no site e um canal SSH + WP-CLI?
O Adapter oficial (plugin + Application Passwords) é ótimo quando você controla o produto e aceita superfície nova no WordPress. O canal SSH + WP-CLI opera o wp que já existe na shared, sem instalar agente no ar do cliente.
O que é o Proa (proa-wp) e quando usar?
Proa é o motor open source (MIT) desse fluxo: CLI + MCP fino + docs. Use quando quiser o mesmo hábito do studio wp / Local, mas apontado para produção via SSH. Código: github.com/silvaitamar/proa-wp.
Por que não colocar receita de um cliente dentro do MCP global?
Porque o agente vê a tool em todos os sites do registry e tenta usá-la onde não cabe. MCP fica genérico; receitas de projeto ficam no CLI + capabilities + docs.
Como evitar que o agente escreva em produção sem autorização?
Default é leitura. Mutação exige --write (ou write: true no MCP). Ainda assim: sem db reset, sem search-replace em massa, sem eval solto. Você autoriza o que altera o site em produção.
Por onde começar
Se você mantém WordPress em Hostinger (ou similar) e já paga Cursor: comece pelo SSH e por option get home. Só depois MCP. Só depois receitas de projeto.
Para o quadro maior (IA + WordPress + soberania do ativo), leia o pilar IA e WordPress: a combinação estratégica de 2026.
Código e docs de operação: Proa no GitHub.
Quer o mesmo canal no Claude Code, no Codex ou em outro fluxo de agente? Abra uma issue no repositório (pedido de agente ou fluxo). Priorizamos o que for genérico e reutilizável; playbooks de um projeto específico ficam fora do escopo público.
Para acompanhar o eixo IA + agentes no ecossistema: entre na lista VIP do IA+WP.