MCP: content_create/content_update ignores taxonomies field (categories/tags not assigned)

[Vallhalen]

Problem

content_create and content_update MCP tools accept a taxonomies field without error, but do not persist taxonomy assignments (categories, tags) to the content item. The field is silently ignored.

This is a follow-up to #621, which was closed after SEO and bylines support was added to content_update. The taxonomy part of that issue was not resolved.

Steps to reproduce

// Create a post with taxonomies
await call('content_create', {
  collection: 'posts',
  slug: 'my-post',
  data: { title: 'Test Post', content: [...] },
  taxonomies: {
    category: ['porady'],        // slug
    tag: ['ai', 'seo'],          // slugs
  },
  status: 'draft',
});
// Result: post created, but NO taxonomies assigned

// Update existing post with taxonomies
await call('content_update', {
  collection: 'posts',
  id: 'POST_ID',
  taxonomies: {
    category: ['TERM_ID'],       // by ID
    tag: ['TERM_ID_1', 'TERM_ID_2'],
  },
});
// Result: returns OK, but NO taxonomies persisted

Verified via content_get - the returned item has no taxonomies field at all.

Expected behavior

content_create and content_update should persist taxonomy assignments, either by term slug or term ID.

Workaround

The REST API endpoint works correctly:

POST /_emdash/api/content/posts/{postId}/terms/{taxonomyName}
Body: { "termIds": ["TERM_ID_1", "TERM_ID_2"] }

This is undocumented but functional. I used it to bulk-assign categories and tags to 15 posts.

Additionally, content_get does not return taxonomy assignments in its response - you need to use GET /_emdash/api/content/posts/{postId}/terms/{taxonomyName} to check.

Environment

• EmDash 0.9.x (latest as of 2026-05-08)
• Cloudflare Workers deployment
• MCP server with content_create, content_update, taxonomy_list_terms tools

[Vallhalen]

Still reproduces on 0.13.0. content_create accepts a taxonomies field without error but the assignment is silently dropped:

content_create({
  collection: 'posts', slug: 'zztest', status: 'draft',
  data: { title: 'Test', content: [] },
  taxonomies: { category: ['google-moja-firma'] }
})
// no error returned

content_get({ collection: 'posts', id }) // => entry terms: none ❌

Also note: content_update's MCP input schema in 0.13 is { collection, id, data, slug, status, seo, bylines, publishedAt, _rev } — there's still no taxonomies parameter at all, so even the intended top-level path isn't wired up. The taxonomy half of #621 remains unresolved. (taxonomy_create_term etc. manage terms fine — the gap is linking a term to a content entry.)

[Vallhalen]

Still reproduces on emdash@0.28.1 (verified against a live D1 site today). Two months and 15 minor releases later the taxonomies-in-content_create field is still silently dropped.

Fresh repro

const r = await call('content_create', {
  collection: 'posts',
  slug: 'zzz-test-tax-' + Date.now(),
  data: { title: 'REPRO test' },
  status: 'draft',
  locale: 'pl',
  taxonomies: {
    category: ['porady'],
    tag: ['ai', 'seo'],
  },
});

Response: 202 Accepted, entry created cleanly, but item.terms is undefined and GET /content/posts/{id}/terms/category returns {terms: []}. Same story for tag. No error, no warning, no partial success. The caller has no signal that the field went to /dev/null.

Concrete cost for MCP agent workflows

I hit this every time I automate blog publishing from Claude via the MCP server. To get a categorized, tagged post live I currently do:

1. content_create for the post itself (taxonomies field silently ignored)
2. Two follow-up taxonomy_list_terms calls to resolve slugs to IDs (or taxonomy_create_term if a tag doesn't exist yet, which is another round trip per new tag)
3. Two POST /content/{collection}/{id}/terms/{taxonomy} REST calls to actually attach them
4. Sometimes a fifth call to publish, since the extra term-attach requests bump updatedAt after the initial publish

Five to seven round trips for something the MCP tool already advertises in its input schema. On a Cloudflare D1 site each of those is ~40ms cross-region, so a categorized post that could be one call becomes ~250ms of avoidable latency plus a lot of orchestration complexity in every agent script that ships posts.

The parity gap is felt even more when agents fan out multiple posts in parallel: I now have to coordinate per-post follow-ups instead of trusting a single atomic write.

Suggested behavior (matches the field the MCP tool already exposes)

content_create and content_update should accept:

taxonomies?: {
  [taxonomyName: string]: string[]; // term slugs, resolved in the entry's locale
}

Unknown term slug: same failure mode as taxonomy_create_term when the taxonomy doesn't exist (clear error, whole request fails, no partial write). Known slug: attach via the same repository call the REST .../terms/{taxonomy} handler already uses.

Happy to PR this against handleContentCreate / handleContentUpdate in packages/core/src/api/handlers/content.ts if the shape and the atomic-vs-partial semantics get a sanity check from a maintainer first — I don't want to guess at whether unknown slugs should upsert or fail, and I want to make sure I hook into the same locale-resolution path the direct term-attach REST route uses so the two entry points can't drift.

The roadmap/1.0 + roadmap/api-mcp-agents labels are why I'm bumping this now: if the goal is MCP-first authoring in 1.0, this is one of the higher-leverage rough edges to sand off, because it directly shortens every automated publishing script from a five-step orchestration to a one-shot write.

[Vallhalen]

Opened #1874 with the fix.

TL;DR of the design (matches the earlier proposal above):

• taxonomies?: { [name: string]: string[] } on both content_create and content_update (plus the matching REST bodies).
• Slugs are resolved in the entry's locale via the same setTermsForEntry path the /terms/{taxonomy} REST route uses, and everything runs inside the content-write transaction so a bad slug rolls the whole write back.
• Update leaves untouched taxonomies alone; an empty array clears one taxonomy.
• Unknown slug or bad shape returns VALIDATION_ERROR so agents can self-correct without silent drops.

Test suite covers the atomic-rollback case, the empty-clear case, selective updates, and locale scoping on i18n sites (EN slug must fail on an FR entry). Changeset included.

Happy to iterate on the shape - the main open call was slugs vs IDs, and I landed on slugs for agent ergonomics but I'm open to also accepting { termIds: [...] } if you prefer strict parity with the REST route.