DatoCMS vs Strapi

DatoCMS

The Content Management API publishes a JSON Hyper-Schema for 202 operations, 100 documented error codes and rate-limit headers, and the hosted MCP server adds OAuth with three access levels. There are no idempotency keys, the only official client library is JavaScript, audit logs are Enterprise only, and prices are in euros with no machine payment route.

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.

DatoCMS

1. Send X-Api-Version: 3 and Accept: application/json on every request, with Content-Type: application/vnd.api+json on writes
2. Records are items, models are item_types and assets are uploads in every path and payload
3. Save a record, then call the publish endpoint as a separate PUT. Send meta.current_version on updates and re-fetch on STALE_ITEM_VERSION
4. Stay under 60 requests every 3 seconds. On 429 wait the seconds in x-ratelimit-reset, and retry any error whose body has transient set to true
5. Fork a sandbox environment for schema changes and promote it when checked. Use POST /items/validate to test a payload without saving it

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