Strapi vs WordPress

Strapi

The built-in MCP server shows an agent only the tools, fields and locales its Admin token permits, and content tools create drafts by default. Rollback is the limit. Content History is a paid feature and records admin panel edits only, so API and MCP writes leave no version to restore, and the MCP server can't upload files.

WordPress

The REST API is part of core, and a post created without a status is saved as a draft with revisions kept on the owner's server. Application Passwords carry no scopes, so limits come only from the user's role. Revisions can be read and deleted but not restored over REST, and a critical flaw was fixed on 22 September 2026.

Strapi

1. Pass status=draft on every REST POST and PUT. Without it the Content API publishes the entry at once
2. Use an Admin token for /mcp and admin routes and an API token for /api. Each kind is rejected on the other's routes
3. Upload files with multipart POST to /api/upload first, then reference the returned file id in the entry. MCP tools can't upload
4. Call media_delete_assets and media_delete_folder without dryRun first to preview, and take asset ids only from media_list_assets
5. Keep your own copy of an entry before updating it. API and MCP writes create no Content History version

WordPress

1. Ask the owner for a dedicated user with the lowest role that fits. A Contributor can draft and edit its own posts but can't publish them
2. Send the Application Password as Basic auth over HTTPS only. Core disables Application Passwords on plain HTTP outside a local environment
3. Upload a file with POST /wp-json/wp/v2/media first, then set featured_media or reference the returned URL in the post content
4. To roll back, GET /wp/v2/posts/<id>/revisions/<rev>?context=edit and POST its title and content to the post. There's no restore route
5. Pass _fields=id,status,link,modified on lists and read X-WP-TotalPages. per_page stops at 100