WP-MCP

Gerencie e publique conteúdo WordPress diretamente do seu assistente de IA — sem necessidade de PHP. Suporta tanto STDIO quanto Streamable HTTP para ampla compatibilidade com clientes.

GitHub

Experimente este MCPPatrocinado

Documentação

wp-mcp

@rnaga/wp-mcp é um servidor Model Context Protocol (MCP) para WordPress que transforma seu site em uma superfície operável por IA. Ao expor primitivas CRUD do WordPress para clientes como o Claude Desktop, um assistente pode redigir um post sob demanda, refiná-lo colaborativamente e publicá-lo diretamente no seu banco de dados—sem precisar passar pelo wp-admin.

Aqui estão alguns cenários comuns que isso possibilita:

Redigir, revisar e publicar posts diretamente de clientes MCP, como o Claude Desktop.
Inspecionar usuários do WordPress, seus papéis e capacidades para auditar permissões do site ou gerar relatórios de acesso.

Construído sobre @rnaga/wp-node, o servidor vem com um conjunto de ferramentas MCP selecionadas que cobrem posts, usuários, comentários, termos, revisões, metadados, opções e configurações do site. O servidor MCP pode gerenciar as seguintes tabelas/recursos do banco de dados:

Recurso	O que você pode fazer
Posts	Criar, atualizar, ler ou excluir posts e suas revisões.
Comentários	Moderar tópicos de discussão ou injetar respostas geradas.
Usuários	Integrar contribuidores, ajustar papéis ou desativar contas com verificações nativas de capacidade.
Termos	Gerenciar categorias, tags e taxonomias personalizadas.
Metadados	Inspecionar, criar, atualizar ou excluir campos de meta de posts, usuários, comentários, termos e site.
Configurações e Opções	Alternar a configuração do site com segurança.

Você pode iniciar um servidor STDIO para acesso direto ao banco de dados ou hospedar um servidor MCP HTTP Streamable para acesso remoto. Para conveniência, adicione o proxy CLI sempre que seu cliente MCP precisar de uma ponte local para o servidor HTTP. O proxy se comporta como um servidor MCP local enquanto retransmite solicitações para o endpoint HTTP—perfeito para clientes que não possuem suporte a OAuth ou senha de aplicativo do WordPress—permitindo que você encaixe fluxos de trabalho MCP em pipelines editoriais existentes sem reimplementar a lógica de negócios do WordPress.

O projeto inclui uma CLI (wp-mcp) que ajuda você a:

configurar e iniciar um servidor MCP STDIO local que se conecta diretamente ao seu banco de dados WordPress;
criar e inicializar um servidor MCP HTTP Streamable baseado em Express (com boilerplate de env/TS);
autenticar em um ambiente WordPress remoto (OAuth ou senha de aplicativo) e executar um proxy JSON-RPC para que clientes MCP possam alcançá-lo com segurança;
inspecionar primitivas MCP disponíveis e gerenciar as credenciais armazenadas em ~/.wp-mcp.

Execute este comando para listar os comandos CLI disponíveis:

npx @rnaga/wp-mcp -- --help

Usage: <command> <subcommand> [options]

Commands:
   local            Local MCP (stdio) server commands
   utils            Utility commands for configuration, debugging, and MCP inspection
   http             Scaffold a TypeScript project for the MCP streamable HTTP server and related tooling.
   remote           Remote MCP server commands

Juntos, o servidor, os utilitários CLI e as ferramentas de proxy permitem que você faça CRUD de conteúdo WordPress, gerencie usuários e sincronize configurações por meio do padrão MCP sem reimplementar a lógica do WordPress.

Começando

Servidor STDIO local

Execute o servidor STDIO quando você puder acessar o banco de dados diretamente. A CLI inicia um processo MCP que assume um usuário WordPress localmente e expõe as ferramentas do seu site via STDIO para o cliente MCP.

flowchart LR
  client(["MCP Client<br/>(e.g. Claude Desktop)"])
  stdio(["Local STDIO MCP Server<br/>(wp-mcp CLI)"])
  db(["WordPress Database"])

  client <--> stdio
  stdio <--> db

Execute a CLI para configurar a conexão com o banco de dados:
```
npx @rnaga/wp-mcp -- local config-set
```
A CLI solicita host, port, database name, user e password. Se o seu banco de dados exigir SSL, você pode fornecer caminhos de arquivo CA, cert e key para proteger o acesso remoto. Execute npx @rnaga/wp-mcp local config a qualquer momento para revisar os valores salvos.
Configure seu cliente MCP para iniciar o servidor. Para Claude Desktop, abra Configurações → Desenvolvedor → Editar Config e adicione isso ao seu claude_desktop_config.json:
```
{
  "mcpServers": {
    "wp-mcp": {
      "command": "npx",
      "args": ["-y", "@rnaga/wp-mcp", "--", "local", "start"],
      "env": {
        "LOCAL_USERNAME": "wp-admin"
      }
    }
  }
}
```
Ative o servidor: Salve o arquivo de configuração, depois saia e reinicie seu cliente MCP (por exemplo, Claude Desktop). As ferramentas do WordPress agora aparecerão no indicador MCP no canto inferior direito da entrada de chat.

Importante: Substitua wp-admin pelo seu nome de usuário do WordPress. O servidor usa isso para determinar quais primitivas MCP estão disponíveis com base nas capacidades do usuário no WordPress. Por exemplo, papéis de administrador têm acesso total a todas as primitivas (criar, atualizar, excluir posts, gerenciar usuários, etc.), enquanto papéis de assinante veem apenas ferramentas limitadas. Esse filtro baseado em capacidades evita a execução acidental de operações privilegiadas. Para ver quais primitivas estão disponíveis e as capacidades e papéis necessários para cada uma:
```
npx @rnaga/wp-mcp -- utils list-prims
```
Isso exibe uma tabela mostrando o nome da primitiva, título, descrição, capacidades necessárias e papéis permitidos.

Opcional: Forneça um manifesto de configuração do WordPress se o seu projeto definir um (por exemplo, src/_wp/config/wp.json). Defina LOCAL_CONFIG no objeto env acima para o caminho absoluto do seu arquivo de configuração. Se você não tiver uma configuração personalizada, omita essa variável de ambiente completamente. Para o esquema do manifesto de configuração, veja https://rnaga.github.io/wp-node/docs/getting-started/configuration.

Testando o servidor MCP:

Use o MCP Inspector para testes interativos e depuração:
```
npx -y @modelcontextprotocol/inspector npx @rnaga/wp-mcp local start -u wp-admin
```
Isso abre uma interface visual em http://localhost:6274 onde você pode explorar as ferramentas disponíveis, testá-las com diferentes argumentos e inspecionar as respostas do servidor.

Nota: O Inspector persiste o painel "Variáveis de Ambiente" no armazenamento do navegador entre sessões. Se você adicionou anteriormente uma entrada PATH lá durante a solução de problemas, exclua-a manualmente na interface — um valor obsoleto pode ocultar o ambiente que o servidor realmente precisa e não será substituído por flags da CLI ou alterações de script.

Referência de uso para flags da CLI e variáveis de ambiente:

Variável de ambiente	Flag da CLI	Propósito	Quando é lida
`LOCAL_USERNAME`	`--username <value>` / `-u <value>`	Nome de usuário do WordPress a assumir	Usado por `local start` para selecionar o usuário WP cujos papéis e capacidades determinam as primitivas MCP disponíveis.
`LOCAL_CONFIG`	`--file <path>` / `-f <path>`	Localização do manifesto de configuração do WordPress	Usado por `local start` para apontar o hook de inicialização para um JSON de configuração WP personalizado.
`DB_ENVIRONMENT`, `WP_DB_HOST`, `WP_DB_PORT`, `WP_DB_NAME`, `WP_DB_USER`, `WP_DB_PASSWORD`, `LOCAL_MULTISITE`, `LOCAL_DEFAULT_BLOG_ID`, `LOCAL_DEFAULT_SITE_ID`, `LOCAL_SSL_ENABLED`, `LOCAL_SSL_CA_FILEPATH`, `LOCAL_SSL_CERT_FILEPATH`, `LOCAL_SSL_KEY_FILEPATH`	(assistente via `local config-set`)	Detalhes da conexão com o banco de dados local	Carregados pelo armazenamento de segredos antes de `local start`; preencha-os com `local config-set` ou exporte-os antecipadamente.

Servidor MCP HTTP Streamable

Use o servidor HTTP quando precisar expor MCP pela Internet ou permitir que colegas remotos se conectem. A CLI cria um aplicativo Express (veja src/http/express/index.ts) que expõe tanto o transporte HTTP de streaming MCP quanto o fallback SSE, reutilizando o mesmo registro de primitivas.

Crie um projeto
```
npx @rnaga/wp-mcp -- http init
```
O assistente solicita detalhes da conexão com o banco de dados, cria um projeto wp-node e fornece boilerplate Express além da configuração TypeScript para o transporte HTTP.

Layout resultante:
```
├── _wp
│   ├── config
│   │   ├── index.d.ts
│   │   └── wp.json
│   └── settings.ts
├── .env
├── .gitignore
├── index.ts
├── package-lock.json
├── package.json
├── src
│   └── index.ts
└── tsconfig.json
```
Preencha .env com os valores solicitados pelo gerador e quaisquer variáveis de ambiente específicas de HTTP listadas posteriormente neste documento.
Execute o servidor em desenvolvimento
```
npm run dev
```
Isso depende de ts-node para que você possa iterar sem pré-compilar.
Compile e execute em produção
```
npm run build
npm run start
```
A saída compilada inicia o mesmo servidor Express que createHttpServer conecta na biblioteca.

Conecte-se via CLI de Proxy Remoto

Use o proxy remoto quando seu cliente MCP só entender STDIO ou não tiver suporte completo a OAuth, mas o ambiente WordPress estiver disponível via HTTP. O proxy mantém as credenciais em ~/.wp-mcp e retransmite solicitações MCP para o servidor remoto com o cabeçalho Authorization correto.

flowchart LR
  client(["MCP Client<br/>(e.g. Claude Desktop)"])
  proxy(["CLI Proxy<br/>(handles OAuth<br/>or WP Application Password)"])
  server(["MCP HTTP Server<br/>(Express instance in this repo)"])
  db(["WordPress Database"])

  client <--> proxy
  proxy <--> server
  server <--> db

Autentique uma vez

Comece registrando o proxy com credenciais de senha de aplicativo do WordPress ou um fluxo de dispositivo OAuth para que ele possa assinar solicitações em nome do seu cliente MCP.
- Senha de aplicativo do WordPress
```
npx @rnaga/wp-mcp -- remote login password
```
  Forneça a URL de autorização do seu servidor (por exemplo, http://localhost:3000) e depois insira o nome de usuário e a senha de aplicativo do WordPress. As credenciais são armazenadas com segurança para que execuções futuras do proxy possam fornecer autenticação HTTP Basic automaticamente (as senhas de aplicativo do WordPress são transmitidas via esquema Basic).
  
  Inspecione os valores armazenados com:
```
npx @rnaga/wp-mcp -- remote config
```
- Fluxo de dispositivo OAuth
```
npx @rnaga/wp-mcp -- remote login oauth
```
  A CLI chama /auth/device/start, imprime o código do usuário e abre a URL de verificação no seu navegador. Após concluir o fluxo do dispositivo, os tokens de acesso e atualização são gravados em ~/.wp-mcp. Você pode executar novamente remote config ou remote revoke-token conforme necessário.
Use npx @rnaga/wp-mcp -- remote config-clear se precisar remover segredos armazenados.
Inicie o proxy

Configure o Claude Desktop (ou outro cliente MCP) da mesma forma que faz para o servidor STDIO local, mas aponte o comando para o proxy:

{
  "mcpServers": {
    "wp-mcp": {
      "command": "npx",
      "args": ["-y", "@rnaga/wp-mcp", "--", "remote", "proxy"],
      "env": {
        "REMOTE_AUTH_TYPE": "oauth",
        "REMOTE_URL": "https://wp-mcp.example.com/mcp"
      }
    }
  }
}

Ajuste o REMOTE_AUTH_TYPE (oauth ou password) e o REMOTE_URL para corresponder ao seu endpoint remoto. Você também pode passá-los em tempo de execução com --authType e --remoteUrl. O proxy valida suas credenciais salvas, atualiza tokens OAuth quando estão a cinco minutos da expiração e então expõe um servidor MCP STDIO local que delega cada chamada ao transporte HTTP remoto.

Uma vez em execução, seu cliente fala STDIO localmente enquanto o proxy retransmite o tráfego para o servidor Express remoto.

Internals do Servidor HTTP Streamable

A implantação HTTP Streamable agrupa middleware Express que inicializa um contexto WordPress em cada solicitação, registra tanto os transportes HTTP de streaming quanto SSE, e adiciona camadas de cache e manipuladores de metadados OAuth. O servidor remoto opera como um servidor de recursos OAuth 2.0 — os clientes devem fornecer um token de portador ou uma senha de aplicativo do WordPress, e o servidor nunca se comporta como um cliente OAuth. Os metadados de descoberta são servidos de /.well-known/oauth-protected-resource, mantendo a implementação alinhada com a RFC 9728.

O auxiliar de código de dispositivo da CLI (npx @rnaga/wp-mcp -- remote login oauth) estende as ferramentas MCP com um fluxo amigável ao terminal. Ele fala com os endpoints /auth/device/* do servidor, armazena os tokens resultantes no cofre de segredos (~/.wp-mcp) e permite que o proxy atualize e anexe credenciais de portador automaticamente.

Controle de Acesso

A camada HTTP aplica autenticação em /mcp e /sse para que apenas chamadores autorizados possam negociar sessões. Ela suporta:

Tokens Bearer OAuth – validados por meio do provedor configurado, com tokens de acesso mapeados para usuários do WordPress antes da inicialização da sessão MCP.
Senhas de Aplicativo do WordPress – aceitas por meio de autenticação HTTP Basic e verificadas antes que o usuário do WordPress seja assumido no lado do servidor.

Requisições bearer com falha recebem cabeçalhos WWW-Authenticate compatíveis com RFC 6750 que incluem o URI de autorização e os escopos solicitados, para que os clientes possam se recuperar de forma graciosa.

Endpoints

Caminho	Propósito
`/mcp`	Transporte MCP HTTP streamable para requisições cliente-servidor e gerenciamento do ciclo de vida da sessão.
`/sse`	Transporte SSE legado para clientes que exigem eventos enviados pelo servidor.
`/messages`	Permite que clientes SSE enviem mensagens de usuário de volta ao servidor.
`/auth/device/start`	Inicia o fluxo de autorização de dispositivo OAuth.
`/auth/device/poll`	Consulta a conclusão do fluxo de dispositivo OAuth e retorna tokens.
`/auth/refresh`	Troca um token de atualização por um novo token de acesso.
`/auth/revoke`	Revoga um token de acesso no provedor.
`/auth/userinfo`	Retorna o usuário do WordPress associado ao cabeçalho Authorization fornecido.
`/auth/password`	Valida uma Senha de Aplicativo do WordPress e retorna o usuário associado.
`/.well-known/oauth-protected-resource`	Serve metadados de recurso OAuth para ferramentas de descoberta.

Provedores OAuth suportados

O servidor inclui perfis de provedor para GitHub, Google e Auth0. Cada perfil encapsula a emissão de código de dispositivo, consulta de tokens, atualização e lógica de revogação que podem ser conectados ao instanciar o servidor HTTP. Para usar um sistema de identidade diferente, forneça sua própria implementação de provedor por meio do mesmo hook e mantenha o restante da implantação inalterado.

Configurando provedores OAuth

Para habilitar a autenticação OAuth, você precisa registrar um aplicativo com o provedor escolhido e configurar as credenciais nas suas variáveis de ambiente.

Configuração OAuth do GitHub

Crie um OAuth App: Navegue até Configurações do Desenvolvedor do GitHub > OAuth Apps > "Novo OAuth App"
Configure seu aplicativo:
- Nome do Aplicativo: O nome de exibição do seu aplicativo
- URL da Página Inicial: A página inicial do seu aplicativo
- URL de Callback de Autorização: Seu endpoint de callback OAuth
Obtenha as credenciais: Após a criação, anote seu Client ID e gere um Client Secret

Defina as variáveis de ambiente:

OAUTH_CLIENT_ID=your_github_client_id
OAUTH_CLIENT_SECRET=your_github_client_secret

Documentação: Documentação de OAuth Apps do GitHub

Configuração OAuth do Google

Acesse o Google Cloud Console: Vá para Google Cloud Console
Crie credenciais OAuth: Navegue até Menu > APIs & Serviços > Credenciais > Criar Credenciais > ID do cliente OAuth
Configure a tela de consentimento OAuth: Defina o nome do aplicativo, e-mail de suporte ao usuário e configurações de público
Selecione o tipo de aplicativo: Escolha o tipo apropriado (Aplicativo Web, Aplicativo de Desktop, etc.)
Obtenha as credenciais: Anote seu Client ID e Client Secret

Defina as variáveis de ambiente:

OAUTH_CLIENT_ID=your_google_client_id
OAUTH_CLIENT_SECRET=your_google_client_secret

Documentação: Configurando OAuth 2.0 no Google Cloud

Configuração OAuth do Auth0

Crie o aplicativo: Registre um Aplicativo Nativo no seu Painel do Auth0
Configure os tipos de concessão: Em Configurações do Aplicativo > Avançado > Tipos de Concessão, habilite:
- Código de Dispositivo (obrigatório para o fluxo de dispositivo)
- Token de Atualização (opcional, para atualização de token)
Habilite OIDC Conformant: Em Configurações do Aplicativo > Avançado > OAuth, garanta que OIDC Conformant esteja habilitado
Configure as conexões: Configure e habilite pelo menos uma conexão para o aplicativo
Obtenha as credenciais: Anote seu Client ID, Client Secret e Domínio

Defina as variáveis de ambiente:

OAUTH_DOMAIN=your-tenant.us.auth0.com
OAUTH_CLIENT_ID=your_auth0_client_id
OAUTH_CLIENT_SECRET=your_auth0_client_secret

Documentação: Fluxo de Autorização de Dispositivo do Auth0

Referência de uso para variáveis de ambiente

O servidor HTTP carrega sua configuração de variáveis de ambiente—tipicamente por meio de um arquivo .env local, ambiente de processo herdado ou configurações fornecidas pela sua plataforma de hospedagem.

Variável de ambiente	Propósito	Exemplo de valor	Quando é lida
`OAUTH_RESOURCE_URL`	URL pública do recurso protegido	`https://mcp.example.com`	Incluída nos metadados de recurso OAuth e nas verificações de proteção contra rebinding de DNS.
`OAUTH_RESOURCE_NAME`	Nome de exibição do recurso protegido	`Example WordPress MCP`	Retornado nos metadados de descoberta.
`OAUTH_SCOPES_SUPPORTED`	Escopos suportados pelo recurso, separados por vírgula	`openid,offline_access,posts.read`	Anunciado nos metadados de descoberta e nos cabeçalhos `WWW-Authenticate`.
`OAUTH_SERVICE_DOCUMENTATION_URL`	Link de documentação para o recurso	`https://docs.example.com/mcp`	Retornado nos metadados de descoberta.
`OAUTH_AUTHORIZATION_URL`	URL do servidor de autorização	`https://auth.example.com`	Enviado aos clientes em cabeçalhos de erro e usado pela CLI ao inicializar fluxos de dispositivo.
`OAUTH_CLIENT_ID`	Identificador do cliente OAuth	`mcp-remote-server`	Passado ao provedor ao solicitar códigos de dispositivo ou atualizar tokens (dependente do provedor).
`OAUTH_CLIENT_SECRET`	Segredo do cliente OAuth (se necessário)	`super-secret-value`	Usado para provedores que esperam clientes confidenciais durante a atualização de token.
`ALLOWED_CORS_ORIGINS`	Origens HTTP permitidas para CORS, separadas por vírgula	`https://claude.ai,https://inspector.modelcontext.com`	Configura a política CORS do servidor HTTP.
`ENABLE_DNS_REBINDING_PROTECTION`	Habilita a proteção contra rebinding de DNS para transporte HTTP	`true`	Habilita a proteção contra rebinding de DNS para o transporte HTTP streamable.
`OAUTH_DOMAIN`	Domínio OAuth (específico do Auth0)	`sample.us.auth0.com`	Usado quando o Provedor Auth0 para construir URLs de dispositivo e token.

Se uma variável for omitida, o servidor recorre a padrões seguros (por exemplo, CORS padrão para *, proteção contra rebinding de DNS desabilitada e metadados OAuth ignorados). Defina apenas os valores que seu provedor exige.

Desenvolvendo Primitivas MCP Personalizadas

O Model Context Protocol define três primitivas de primeira classe: ferramentas (ações chamáveis), recursos (ativos legíveis expostos por URI) e prompts (sequências de mensagens modeladas). defaultMcpPrimitives neste pacote atualmente inclui implementações de ferramentas, mas o mesmo padrão de decorador + registro permite expor recursos e prompts também. O fluxo de trabalho abaixo cobre a estruturação, a criação de uma classe e a conexão dela a cada transporte.

1. Estruture um projeto

Use a CLI para inicializar a estruturação TypeScript e instalar dependências.

Servidor STDIO local

npx @rnaga/wp-mcp -- local init

O comando implementado em src/cli/local.cli.ts instala @rnaga/wp-node e @rnaga/wp-mcp, coloca um src/index.ts inicial, copia tsconfig.json, cria um .gitignore e adiciona scripts dev, build e start ao package.json.

Layout resultante:

├── package.json
├── src
│   └── index.ts
├── tsconfig.json
└── package-lock.json

Servidor HTTP streamable

npx @rnaga/wp-mcp -- http init

Este subcomando (veja src/cli/http.cli.ts) executa os prompts do WordPress, instala as mesmas dependências, copia o modelo HTTP src/index.ts e anexa as configurações específicas do MCP ao .env ou .env.<environment>. Após a estruturação terminar, você pode executar npm run dev para iniciar o transporte Express.

2. Implemente uma classe de primitiva

Crie um arquivo como src/mcp/example-suite.mcp.ts e adicione uma classe decorada com @mcp e @mcpBind. Cada método @mcpBind recebe a instância do servidor MCP mais metadados de tempo de execução, para que você possa registrar ferramentas, recursos ou prompts em um só lugar.

Veja o repositório @modelcontextprotocol/typescript-sdk para uso completo do SDK e exemplos de registro de primitivas.

import { z } from "zod";

import { mcp, mcpBind } from "@rnaga/wp-mcp/decorators";
import { Mcps } from "@rnaga/wp-mcp/mcp";
import type * as types from "@rnaga/wp-mcp/types";

@mcp("example_suite", {
  description: "Example bundle showing tools, resources, and prompts.",
})
export class ExampleSuiteMcp {
  @mcpBind("example_tool", {
    title: "List Options",
    description: "Return the WordPress options table as JSON.",
    capabilities: ["read"],
  })
  example(...args: types.McpBindParameters) {
    const [server, username, meta] = args;

    server.registerTool(
      meta.name,
      {
        title: meta.title,
        description: meta.description,
        inputSchema: undefined,
      },
      async () => {
        const wp = await Mcps.getWpContext(username);
        const options = await wp.utils.crud.options.getAll();

        return {
          content: [
            {
              type: "text",
              text: JSON.stringify(options, null, 2),
            },
          ],
        };
      }
    );

    return server;
  }
}

Cada manipulador recebe a mesma tupla:

server – a instância McpServer de @modelcontextprotocol/sdk/server/mcp.js, que expõe registerTool, registerResource e registerPrompt.
username – a identidade do WordPress anexada à sessão; passe-a para Mcps.getWpContext para aplicar verificações de capacidade ao acessar APIs do WordPress.
meta – os metadados do decorador (name, title, description, capacidades, papéis) que você pode reutilizar ao registrar primitivas.

Mcps.getWpContext produz o contexto @rnaga/wp-node hidratado. Use-o dentro de ferramentas, recursos ou prompts para chamar auxiliares de CRUD, coletar metadados do site ou aplicar lógica adicional antes de retornar respostas MCP.

3. Registre a classe com o ponto de entrada do servidor

Ambos os transportes expõem um array mcps; anexe sua classe para que o servidor a conecte ao iniciar. Todas as primitivas registradas dentro dos métodos da classe (ferramentas, recursos, prompts) ficam disponíveis para clientes MCP conectados.

Servidor STDIO local

import { createLocalServer } from "@rnaga/wp-mcp/cli/local";
import { ExampleSuiteMcp } from "./example-suite.mcp";

(async () => {
  const mcpServer = await createLocalServer({
    username: process.env.LOCAL_USERNAME,
    mcps: [ExampleSuiteMcp],
  });

  // connect transport...
})();

Servidor HTTP streamable

import { MemoryCache } from "@rnaga/wp-mcp/http/cache/memory-cache";
import { createHttpServer } from "@rnaga/wp-mcp/http/express";
import { ExampleSuiteMcp } from "./example-suite.mcp";

const app = createHttpServer({
  cacheClass: MemoryCache,
  mcps: [ExampleSuiteMcp],
});

Inicie o servidor (npm run dev localmente ou npm start após a compilação) e as ferramentas, recursos e prompts registrados aparecem para qualquer cliente MCP conectado por meio do proxy local ou transporte HTTP.

Registro MCP

Este servidor é publicado no Registro do Model Context Protocol, tornando-o facilmente descobrível e instalável por clientes MCP.

Você pode encontrar o servidor em: https://registry.modelcontextprotocol.io/v0/servers?search=wp-mcp&version=latest

A entrada do registro inclui detalhes de configuração, variáveis de ambiente necessárias e instruções de instalação.