Repository navigation
Content type CRUD MCP output diverges from csdx cm:stacks:export, breaking repo-managed JSON workflows #384
Description
When a content type is fetched (or written and re-fetched) through @contentstack/mcp's CMA tools, the JSON shape and key ordering differ from what csdx cm:stacks:export produces. Teams who store exported content type JSON in a repo (so importer scripts and code generation can run from a known canonical source) end up with two incompatible shapes for the same content type. This makes MCP unusable as a drop-in replacement for csdx in such workflows.
Environment
- Package: @contentstack/mcp@0.6.0
- Tools used: get_a_single_content_type, update_content_type
- Auth: OAuth (set up via npx @contentstack/mcp --auth)
- Comparison tool: @contentstack/cli (csdx cm:stacks:export)
- Region: [NA / EU / AZURE-NA — fill in]
- Stack API key: [redacted]
- Branch: dev
Steps to reproduce
- Export a content type with the official CLI:
csdx cm:stacks:export --content-types <uid> --branch dev --alias <management-alias>
Save the resulting<uid>.json. - Read the same content type via MCP:
mcp_contentstack_get_a_single_content_type({ branch: "dev", content_type_uid: "<uid>" }) - Compare the two payloads.
Observed differences
Concretely, on a content type abc(real example from our repo):
The schema reordering is the most damaging side effect: a single MCP write to a previously csdx-managed content type permanently changes how Contentstack returns the schema, so subsequent csdx exports also diff against the prior repo state.
Expected behavior
Either:
-
MCP output matches csdx export. @contentstack/mcp post-processes content type responses to the same shape csdx cm:stacks:export produces. Ideal for repo-managed workflows.
-
Opt-in csdx-compatible mode. A flag (--export-shape=csdx or format parameter on the CMA tools) emits the csdx shape so consumers can choose.
-
At minimum, consistent ordering. Even if shape can't change, schema key order should be stable on read (either the user's submitted order or a documented canonical order that csdx also follows), so MCP writes don't introduce one-time reorder diffs against csdx-exported repo files.
Actual behavior
- MCP returns the raw CMA payload, including server-side fields and the unfiltered DEFAULT_ACL / SYS_ACL shapes.
- After any MCP write, Contentstack stores the content type in a canonical order that differs from what csdx had previously emitted, and all subsequent reads (csdx or MCP) reflect this new order.
Activity
shafeeqd959 commentedon Jun 10, 2026
Investigation Findings
Thank you for the detailed report and for your patience while we looked into this.
After investigating, we can confirm the root cause: this is not a key-ordering issue. Both the MCP and the CLI use the same underlying CMA API, so the key order in API responses is consistent between them. The actual difference is that
csdx cm:stacks:exportapplies filtering and normalization on top of the raw API response before writing to disk, whereas@contentstack/mcpsurfaces the raw API response directly.The specific fields that appear in the MCP output but are absent from CLI exports include
DEFAULT_ACL,SYS_ACL, and a number of other internal/system-level attributes thatcsdxintentionally strips during its export process.Recommended Workaround
While a native fix is in discussion, the immediate path forward is to use a custom normalization script that post-processes the MCP response to match the CLI export shape — stripping the additional system fields and applying the same field ordering that
csdxproduces.This keeps your repo JSON stable and your git diffs clean without requiring any changes to the MCP server or the CLI.
Longer-Term Fix
Internally, we have started discussing the addition of a formatting/normalization flag to the MCP server that would allow it to emit CLI-compatible output directly, removing the need for the custom script. An ETA has not been finalized yet, but we will update this issue once it enters the roadmap.
We appreciate you raising this — the use case of keeping repo-committed content type JSON as a stable source of truth for downstream tooling is an important one, and we want MCP to be a first-class option in those workflows. Happy to answer any follow-up questions in the meantime.