mcp-wordpress: Skill for Claude Code

MCP Release QA

Test the server that users will run. A schema review or a passing unit test is not runtime evidence.

This skill complements security review. It focuses on protocol behavior, published-contract drift, transport correctness, and reproducible release evidence.

Rules

• Run checks against a fresh server process built from the candidate revision.
• Keep initialize, notifications/initialized, discovery, and invocation in the same session. A new process is a new STDIO session.
• Treat source registrations as implementation truth and public documentation as a contract that must match it.
• Record exact commands and raw responses. Do not replace missing evidence with "looks correct."
• Do not invoke mutation-capable tools against production data. Use fixtures, a sandbox, or stop and name the missing safe test environment.
• Derive the expected capability inventory from the candidate source on every run.

1. Establish the release surface

Identify:

• candidate commit and build command;
• server entry point and transport: STDIO, Streamable HTTP, or SSE;
• supported MCP protocol versions;
• source files that register tools, resources, resource templates, and prompts;
• generated catalogs, manifests, README tables, and install instructions;
• existing protocol, integration, and smoke-test commands.

Prefer repository-native commands. Inspect package.json, pyproject.toml, Makefile, CI workflows, and contributor instructions before inventing a test harness.

2. Start a clean server

Build the candidate and start the documented entry point with test-safe configuration. Capture:

• the exact command;
• commit SHA;
• environment variable names, with values redacted;
• stdout, stderr, and exit status;
• the endpoint or child-process transport used by the client.

For STDIO, stdout is protocol-only. Logs, banners, and stack traces belong on stderr. For HTTP transports, record the status, relevant MCP headers, and session identifier handling without printing credentials.