Como expor uma Ability personalizada do WordPress por MCP

Uma Ability personalizada do WordPress pode ser projetada por um adaptador MCP, mas a exposição de transporte não deve ampliar seu contrato de permissão, validação, efeitos colaterais ou evidências.

A IA é mais útil aqui como organizadora de evidências, mecanismo de comparação e assistente de redação. Ela pode tornar uma tarefa complexa do WordPress mais fácil de inspecionar, mas não pode criar autoridade ausente, certificar fatos que não observou nem converter silenciosamente uma recomendação em permissão para agir.

Em uma frase: uma Ability personalizada do WordPress pode ser projetada por um adaptador MCP, mas a exposição de transporte não deve ampliar seu contrato de permissão, validação, efeitos colaterais ou evidências.

O que este guia ajuda você a realizar

Preparar e verificar uma Ability personalizada para descoberta e execução por MCP usando esquemas explícitos, permissões delimitadas, testes negativos e validação específica do cliente.

• Uma Ability personalizada testada com um contrato estável.
• Uma decisão de exposição MCP e um registro de configuração.
• Evidências de testes de descoberta, execução, negação e entrada malformada.
• Notas de configuração específicas do cliente que não impliquem compatibilidade universal.

O artefato concluído deve ser compreensível para a pessoa responsável pela decisão e reproduzível por alguém que não participou do prompt original. Uma resposta fluente não é suficiente. Cada conclusão relevante precisa de uma fonte, um escopo e um caminho de verificação. Quando as evidências não conseguem estabelecer algo, a saída correta é um desconhecido explícito ou uma hipótese testável.

Evidências e entradas a preparar

• Uma Ability do WordPress registrada e testada.
• A documentação atual do Adaptador MCP do WordPress e do cliente.
• A configuração de autenticação e identidade do WordPress.
• Fixtures locais ou de staging seguros.
• A cobertura instalada do WP Agent Control quando ela fornece a identidade do WordPress.

Antes de fornecer evidências a um assistente, remova credenciais, valores secretos e informações pessoais não relacionadas. Preserve os identificadores, versões, timestamps, localidade, unidades e rótulos de fonte necessários para interpretar o que restou. Uma captura de tela sem URL, estado ou data pode ser um contexto útil, mas raramente é autoridade suficiente para uma decisão de produção.

Não comece com uma solicitação ampla, como “revise isto”, “corrija isto” ou “melhore isto”. Defina a decisão que o trabalho deve apoiar, a população incluída, a fonte que tem autoridade para cada campo, as operações permitidas e as ações que continuam proibidas. O acesso autenticado ao WordPress ou uma exportação controlada é necessário para esta tarefa.

MCP é transporte e descoberta

Ele ajuda um cliente a entender e chamar ferramentas. Não substitui a autorização do WordPress, a validação da Ability ou uma aprovação responsável.

O suporte ao cliente é específico

Claude Code, Codex e outros clientes podem diferir em configuração, apresentação de ferramentas, UX de aprovação e suporte ao transporte. Teste cada caminho nomeado.

Uma recusa faz parte do contrato

Uma execução não autorizada deve falhar de forma previsível e ser documentada. Não amplie a identidade do WordPress para fazer uma demonstração funcionar.

Mantenha observação, inferência e autoridade separadas

Uma revisão controlada deve distinguir pelo menos quatro estados:

1. Observado: presente diretamente em um registro, arquivo, resposta, página renderizada ou teste executado identificado.
2. Inferido: uma interpretação plausível respaldada por evidências, mas não estabelecida diretamente.
3. Recomendado: uma decisão humana proposta ou próxima ação.
4. Autorizado e verificado: uma alteração aprovada separadamente, executada e então verificada em relação aos critérios de aceitação.

A saída da IA normalmente começa nos três primeiros estados. Ela não se torna autorizada apenas porque é detalhada, internamente consistente ou tecnicamente convincente. Preserve essa distinção em tabelas, relatórios, tickets e estudos de caso públicos.

Um fluxo de trabalho seguro

1. Conclua e teste a Ability subjacente antes da exposição por MCP.
2. Confirme a versão do adaptador, o transporte e o caminho de autenticação.
3. Exponha somente a Ability e os metadados pretendidos.
4. Conecte um cliente seguro a uma identidade dedicada do WordPress.
5. Teste a descoberta e uma fixture válida somente de leitura ou delimitada.
6. Teste solicitações não autorizadas, inválidas e fora do escopo.
7. Registre as versões do cliente, modelo, adaptador, WordPress e plugin.
8. Revogue a identidade de teste e retenha evidências reproduzíveis.

Essa sequência coloca deliberadamente uma revisão responsável entre a análise e a implementação. Se uma etapa posterior precisar de acesso mais amplo, crie uma nova tarefa, uma nova identidade ou uma alteração explícita de permissão. Não atualize silenciosamente a identidade analítica porque ela atingiu um limite correto.

Modelo de prompt

Substitua cada valor entre colchetes antes de usar o prompt. Não cole senhas, chaves de API, cookies de autenticação, registros privados de clientes ou informações pessoais não relacionadas.

Você está revisando [TASK SCOPE] para [SITE, REPOSITORY OR DATASET] usando somente as evidências fornecidas.

Objetivo:
Preparar e verificar uma Ability personalizada para descoberta e execução por MCP usando esquemas explícitos, permissões delimitadas, testes negativos e validação específica do cliente.

Retorne os seguintes campos:
- Ability
- Versão do adaptador
- Cliente
- Transporte
- Identidade
- Permissão
- Resultado da descoberta
- Execução válida
- Execução negada
- Entrada inválida
- Evidência
- Limite conhecido

Regras:
1. Não exponha Abilities antes que seus testes diretos sejam aprovados.
2. Preserve exatamente os nomes, esquemas e identificadores das Abilities.
3. Não reivindique compatibilidade com clientes ou versões não testados.
4. Não use Full Power para contornar uma recusa.
5. Não inclua credenciais em exemplos de configuração.

Para cada constatação:
- identifique a fonte, registro, URL, arquivo, linha, ID de objeto, estado ou linha do conjunto de dados exatos;
- preserve datas, versões, unidades, localidade, identificadores e denominadores;
- separe observação, inferência, recomendação e desconhecido;
- declare quais evidências não estavam disponíveis;
- não altere o WordPress, código-fonte, dados comerciais, análises, sistemas externos ou conteúdo publicado.

Por que este prompt é estruturado dessa forma

O prompt cria um contrato de evidências antes de pedir recomendações. Ele torna os dados ausentes visíveis, reduz a chance de um modelo completar um registro incompleto com prosa plausível e produz uma saída que pode ser revisada sistematicamente. Campos estruturados também facilitam comparar execuções repetidas ou entregar um subconjunto aprovado a um fluxo de trabalho de implementação posterior.

Uma implementação de produção pode adicionar esquema JSON, entradas de ferramentas tipadas ou validação automatizada. Esses mecanismos melhoram a consistência, mas não estabelecem que a evidência de origem é verdadeira, completa ou atual. A revisão humana e a verificação específica do sistema continuam necessárias.

Limite de acesso recomendado

Use Depende do estágio autorizado separadamente para o estágio descrito neste guia. As capacidades exatas disponíveis para uma identidade devem vir da versão instalada do produto, do contrato de cobertura publicado e do método de conexão realmente em uso.

O que deve permanecer fora desta tarefa

• Execução em produção
• Divulgação de credenciais
• Exposição ampla de ferramentas
• Escalonamento de permissões
• Alegações de compatibilidade universal

Uma ação recusada pode ser uma evidência útil de que o limite de controle está funcionando. Não responda a uma recusa esperada concedendo uma conta ampla de administrador ou Full Power. Primeiro determine se a ação pertence ao mandato atual. Se pertencer, crie um estágio autorizado separadamente com a capacidade necessária mais restrita.

Como o WP Agent Control se encaixa

A pasta privada guiada para Claude Code ou Codex usa REST do WordPress e uma senha de aplicativo com perfil dedicado somente para leitura. Os perfis existentes Read Only, Draft, Content Editor e Publisher permanecem nas opções avançadas. Não são convertidos automaticamente para OAuth nem recebem o modelo remoto de tarefas e aprovação exata.

Obtenha informações estruturadas do site e inspecione páginas publicadas selecionadas após conectar. Essa leitura pública não exige tarefa temporária. Você também pode visitar páginas públicas sem o plugin; o Agent Control acrescenta acesso estruturado e continuidade para o trabalho autorizado no WordPress.

Conectar sua IA: docs first profile · Ver recursos e compatibilidade: coverage

Lista de verificação

• ☐ A tarefa, população, período, ambiente e decisão são explícitos.
• ☐ Cada observação relevante está vinculada a evidências exatas ou rotulada como hipótese.
• ☐ IDs estáveis, URLs, versões, datas, unidades, localidades e denominadores são preservados.
• ☐ Evidências ausentes e limites de cobertura permanecem visíveis.
• ☐ A identidade analítica ou de pesquisa não realizou nenhuma mutação proibida.
• ☐ Um responsável qualificado revisou as implicações de segurança, acessibilidade, legais, comerciais ou de lançamento quando aplicável.
• ☐ Qualquer implementação possui mandato separado, nível de acesso, backup e plano de verificação.
• ☐ Identidades temporárias, fixtures e evidências sensíveis são revogadas, redefinidas ou descartadas após a tarefa.

Modos de falha comuns

• Desenvolvimento com transporte primeiro: a equipe depura o MCP enquanto o contrato da Ability subjacente ainda está instável.
• Excesso da conta de demonstração: uma identidade ampla de administrador oculta falhas de permissão e cria documentação insegura.
• Confusão entre clientes: uma configuração testada em um cliente é copiada para outro com semântica de configuração diferente.
• Efeitos colaterais silenciosos: uma ferramenta descrita como analítica altera o WordPress ou um sistema externo.

Uma falha transversal recorrente é a deriva de permissões: a tarefa inicial encontra um limite, e o operador amplia o acesso antes de determinar se a operação ausente é necessária, compatível ou segura. Isso destrói o valor de evidência da recusa e torna resultados posteriores difíceis de atribuir.

Nota avançada

Trate o MCP como uma projeção de um contrato de Ability governado. Os metadados de descoberta, a autorização de execução e a restituição observada devem ser testados como camadas separadas para que uma alteração de transporte não possa ampliar silenciosamente a autoridade operacional.

Guias relacionados

• Guia da API Abilities do WordPress para fluxos de trabalho de IA
• Como criar uma matriz de testes de permissões do WordPress para agentes de IA
• Como conectar o Claude Code ao WordPress
• Como conectar o Codex ao WordPress

Continuar

Continue com o guia de apoio mais relevante e use o guia de níveis de acesso antes de qualquer tarefa autenticada. Quando o acesso temporário ao WordPress não for mais necessário, termine revogando a identidade.