The repository documents what it was fixing: base64 image transfer lost 95-98% of the data on large files — an 85KB image arriving as 1.5KB — and used 33% more memory doing it. Sending the file path lets WordPress's own uploader handle the bytes, so an 85KB image comes out at 50KB because it was optimised, not truncated.
A WordPress posting server built around one decision: images are passed as file paths, not base64. It reads the file from disk and sends it through WordPress's standard multipart media upload, which lets WordPress do its own optimisation and generate the responsive srcset. Based on prathammanocha's wordpress-mcp-server, with the image handling rewritten.
- `create-post` creates a post with images attached — `siteUrl`, `username`, `password`, `title`, `content`, `status` (draft, publish or private, defaulting to draft), and `images` entries carrying `filePath`, `placeholder` and an optional `filename`
- Images drop into the body wherever their placeholder appears, so `{IMAGE1}` in the content is where that image lands
- `list-posts` retrieves posts with pagination; `get-post` returns one post's full detail; `update-post` edits an existing post
Node.js v18 or newer, a WordPress site with the REST API enabled, and a WordPress application password. Clone the repository, run `npm install`, copy `.env.example` to `.env` and fill in the credentials, then `npm run build`. Point your client at `node` with the path to `build/posts-only.js`. Because images are read from disk, the paths you pass must be absolute and readable by the server process; upload size is bounded by WordPress's own `upload_max_filesize`, `post_max_size` and `memory_limit`. Documentation is in Japanese.