optimizely-test-data-mcp
An MCP server that turns a content plan into an importable Optimizely CMS 12
.episerverdata package.
The generator never touches a CMS. It reads a content-type export and writes a file; a human exports the schema and a human imports the result under Admin → Import Data.
Use it
{
"mcpServers": {
"optimizely-test-data": {
"command": "bunx",
"args": ["optimizely-test-data-mcp@0.1.1"]
}
}
}
Pin the version. An unpinned spec is re-resolved on every session start instead of being served from cache — on Windows that measured ~11s per start versus ~0.7s pinned.
npx works the same way if you would rather not use Bun.
Tools
| Tool | Purpose |
|---|---|
load_schema |
Load the site's content types from an Admin → Export Data export (content types only). Every other tool fails until this succeeds. |
list_content_types |
Find the types the site actually has, filtered by kind or name. |
describe_content_type |
One type's properties, which are required, and a ready-to-edit plan skeleton. |
validate_plan |
Check a plan without writing anything. Errors name the shape they expected. |
build_package |
Write the .episerverdata file. |
inspect_package |
Summarise the content tree inside an existing package. |
Limits
Media, inline block properties, unpublished content, more than one language,
Category and untyped Json are not generated. Any property type with no proven
serialisation is left empty with a warning rather than guessed — a wrong guess
produces content that looks right and is subtly incorrect.
Working: pages, blocks, nested page trees, text, HTML, ContentArea, content
references, and {{date:±Nd}} / {{date:±Nh}} / {{date:±Nm}} tokens.
Releasing
Bump
versioninpackage.json.Commit, then tag and push:
git tag v0.2.0 git push origin v0.2.0
The workflow checks the tag against package.json, runs the tests, builds dist/,
and publishes through OIDC trusted publishing — no token to store.
Releasing is CI's job. There is no prepublishOnly hook, so npm publish on
its own does not build: dist/ is git-ignored, and publishing without it ships a
package whose files: ["dist"] matches nothing. npm accepts that and exits 0, so
nothing reports the failure — the broken version simply reaches consumers. If you
ever do need to publish by hand, run bun run build first.
That hand-publish is required exactly once: npm can only trust a package it already
knows about. Publish 0.1.1 manually (bun run build, then npm publish after
npm login), then add the trusted publisher under the package's Settings →
Trusted Publisher on npmjs.com, pointing at this repository and publish.yml.
Every release after that comes from a tag.
Consumers pin the version they use — see the config above. Bumping here does not move them until they update that pin.