Blog

  • Two Fictional Campaigns, One WordPress Experiment

    What does it take to build a campaign website through a conversation with an AI coding agent? On MCP Test Site, two fictional candidates provided a practical way to explore that question.

    Rowan Ellis and Morgan Hale were created for mock campaigns set in Maine State Senate District 2. Each received a campaign landing page, a separate Contact Us page, generated imagery, and navigation connecting the campaign section to the wider website.

    The candidates, biographies, and platforms are invented. Their purpose is to demonstrate how Codex can help build and refine WordPress content through the Model Context Protocol, or MCP.

    Two candidates with distinct identities

    The first campaign introduced Rowan Ellis, a fictional progressive candidate with an imagined background in community organizing and public-library programs. Rowan’s message—“A fairer Maine. A future we build together.”—frames a platform covering affordable housing, accessible health care, fair working conditions, public services, climate action, and civil rights.

    The design uses deep green, soft cream, and gold accents. A large opening banner establishes the candidate’s name and message, while a portrait contained within the outline of Maine gives the page a distinctive visual identity.

    The second campaign introduced Morgan Hale, a fictional conservative opponent. Morgan’s invented biography describes a small-business owner and former volunteer fire-department treasurer. Her message—“A stronger Maine. Rooted in responsibility.”—introduces priorities including responsible budgets, public safety, small businesses, parental involvement in education, individual liberty, and local control.

    Morgan’s campaign uses navy, cream, and burgundy accents. It follows the first campaign’s overall structure while giving the candidate her own voice and imagery.

    Using two different platforms made the exercise more useful: the same page patterns had to accommodate distinct content and visual identities.

    Building with WordPress blocks

    The pages were assembled using WordPress block markup. Headings, paragraphs, buttons, images, quotations, and grouped sections form the main content. Custom HTML and CSS supply details such as the photo backgrounds, portrait placement, navigation cards, and responsive layouts.

    This approach keeps much of the content in familiar WordPress blocks while allowing more control over presentation.

    Each campaign begins with a prominent hero banner containing the candidate’s name, a short message, and links to explore the page or open the contact section. Below it, three navigation cards guide visitors to the biography, policy priorities, and explanation of the demonstration.

    The pages also use contrasting section backgrounds and constrained text widths to make longer passages easier to read. Rowan’s layout was additionally explored in a separate draft with alternating policy blocks, showing how the presentation could be revised while preserving the campaign copy.

    Creating the images

    AI-generated images supplied the visual assets for the mock campaigns, including candidate portraits inside Maine’s silhouette and community scenes for the banner backgrounds.

    Morgan’s image prompts specified neighbors outside a Maine hardware store and a discussion around a community-hall table. They also requested compositions suitable for a headline overlay, without readable signs or logos.

    The images were uploaded to the WordPress media library. Descriptive alternative text and captions identified the generated assets and their fictional purpose.

    Dark color overlays on the background photographs help the white banner text remain readable. The portrait appears alongside the text on wider screens and moves beneath it on smaller screens.

    Connecting the pages

    Building the landing pages was only part of the work. Each campaign also needed a matching Contact Us page, working links, and a place in the site’s navigation.

    The contact pages continue the visual language of their respective campaigns, including photo-backed banners and consistent typography. Their copy invites questions and interest in involvement while identifying the fictional campaign context.

    Navigation work included links in the site header and footer. Because the site uses the Twenty Twenty-Five block theme, this involved WordPress navigation blocks and template parts as well as page content.

    Where MCP fit into the process

    MCP provided the connection through which Codex could inspect WordPress content and use the site’s available abilities to create or update pages. The build also used the WordPress REST API for tasks such as uploading local images and editing navigation content.

    The process was iterative: inspect the existing structure, write the content, generate assets, assemble the pages, connect the links, and refine the layout. Responsive CSS added smaller-screen arrangements, and the page styles included visible keyboard-focus indicators.

    The result is a pair of fictional campaign sections that demonstrate more than automated copywriting. They show how conversational instructions can guide content, imagery, layout, and WordPress integration—and how an established design can become the starting point for a second, distinct page.

  • How This WordPress Website Was Configured to Be Editable by Codex

    This website doubles as a working experiment: can Codex manage WordPress content directly from a conversation? After configuring a WordPress MCP endpoint and correcting the client connection, Codex successfully discovered the available abilities and read the site’s information. This article documents that setup and the troubleshooting that made it work.

    The components that connect Codex to WordPress

    The site has two active plugins: MCP Adapter (version 0.6.1) and Enable Abilities for MCP (version 2.13.0). The adapter bridges WordPress abilities to the Model Context Protocol, or MCP. The companion plugin exposes additional operations, including reading posts and pages, creating drafts, updating content, and working with metadata.

    The connection follows a simple path: Codex sends an authenticated MCP request over HTTPS, the adapter routes it to a WordPress ability, and WordPress returns the result. Each operation still depends on the available ability and the permissions of the authenticated account. Installing the adapter alone does not make every part of a website editable.

    The WordPress endpoint

    The MCP server for this site is available at https://mcp-test.lucdaigle.net/wp-json/mcp/mcp-adapter-default-server. The site also exposes the ordinary WordPress REST API at /wp-json/.

    During the first checks, both the homepage and REST API returned HTTP 200. That established that the site was reachable, but it did not establish an authenticated MCP connection. The MCP endpoint returned HTTP 401 when accessed without credentials, so authentication had to be tested separately.

    Configuring Codex

    On this Windows computer, the connection was added to C:\Users\luc\.codex\config.toml. The final configuration uses a direct HTTP connection:

    [mcp_servers.mcp-test-wp-site]
    url = "https://mcp-test.lucdaigle.net/wp-json/mcp/mcp-adapter-default-server"
    http_headers = { Authorization = "Basic <base64-encoded-username:application-password>" }

    The placeholder above must be replaced with the credential value for the intended WordPress account. For WordPress application-password authentication, the value represents the Base64 encoding of username:application-password. The actual credential is deliberately omitted from this article. Base64 is an encoding, so the encoded value must be treated as a secret too.

    Codex supports an HTTP server URL and an http_headers map directly. This avoids starting a local proxy process for this connection. After updating the configuration, Codex was restarted and the connection was tested again.

    Two problems in the original configuration

    The initial entry used npx mcp-remote to connect to the endpoint. However, npx was not available on the command path visible to the testing session. That made the local launcher a likely startup blocker. Switching to Codex’s native HTTP connection removed that dependency.

    The other problem was confirmed by an authentication test. The saved credential had been sent with Authorization: Bearer. A read-only request to the WordPress current-user endpoint returned HTTP 401 with Bearer authentication and HTTP 200 when the same value was sent with Authorization: Basic. For this credential, Basic was the working scheme.

    These were separate checks: a website can load normally while the MCP client cannot start, and an MCP endpoint can exist while its authentication header is wrong.

    Verifying the working connection

    After the configuration change and restart, Codex could access the adapter’s three MCP tools: ability discovery, ability information, and ability execution. Discovery returned the core WordPress abilities and the companion plugin’s ewpa/ abilities.

    Codex then inspected the schema for core/get-site-info and executed it with a request for the site name, URL, and WordPress version. The response reported MCP Test Site, https://mcp-test.lucdaigle.net, and WordPress 7.1.2. This verified that a real ability could execute through the configured MCP connection.

    What editing through Codex now means

    The discovered abilities include operations for creating and updating posts, creating pages, managing taxonomy terms, and reading or writing selected metadata. Codex can inspect an operation’s input schema, prepare its parameters, and invoke it through the adapter. The exposed abilities determine the scope of those changes; this connection does not establish unrestricted access to theme files or arbitrary server code.

    A practical content workflow is to ask Codex to prepare a post, save it as a draft, and review it in WordPress before publishing. This post was prepared for that draft workflow using the same connection it describes.

    References

    WordPress MCP Adapter describes the bridge between WordPress abilities and MCP. The official Codex MCP documentation explains HTTP server configuration and authentication headers.