Posting to WordPress from an assistant usually means pasting HTML that the block editor then treats as one lump of classic content; writing blocks directly is what keeps the post editable afterwards. Read the supported block types before generating anything — that is the difference between content that lays out correctly and content that has to be rebuilt by hand. Permission questions resolve on the WordPress side, so give the connection an account with exactly the role you want it to have.
A WordPress content client that speaks blocks. Posts are created and updated in the Gutenberg format the block editor expects, and the block types available on the site can be read first so generated content uses ones that exist.
- Posts found by title or keyword, and any post fetched in full by its id
- New posts created as Gutenberg blocks rather than as classic HTML
- An existing post updated by id, again in block format
- The list of block types the site supports, which is what a generation step should consult before writing content
A WordPress site and an account on it: WORDPRESS_URL, WORDPRESS_USERNAME and WORDPRESS_APP_PASSWORD, either as environment variables or in a .env file the server looks for in a directory under your home folder or beside itself. Use an Application Password, generated under your profile in WordPress admin, rather than your login password. The server is cloned and run with node, and a setup script writes the credentials file for you. Which tools appear depends on the personality the server is launched with — but your WordPress user's own permissions still decide what actually succeeds, so a role that cannot publish will not publish however the server is configured.
One command plus a key — npx -y wordpress-mcp, then supply credentials