Content type CRUD MCP output diverges from csdx cm:stacks:export, breaking repo-managed JSON workflows

[tufailmirr]

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

1. 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.
2. Read the same content type via MCP:
   mcp_contentstack_get_a_single_content_type({ branch: "dev", content_type_uid: "<uid>" })
3. 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:

1. 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.

2. 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.

3. 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

1. MCP returns the raw CMA payload, including server-side fields and the unfiltered DEFAULT_ACL / SYS_ACL shapes.
2. 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.