Recently, I had the opportunity to put the Sitecore Marketer MCP to the test for some large migration efforts. I used it on a large utility-program site moving onto SitecoreAI, bringing hundreds of legacy pages, three languages, and a lot of media assets with it.

The Marketer MCP is Sitecore’s Model Context Protocol server. It exposes content and page-building operations as tools an AI assistant can call. For example, it can read items, list pages’ components, create datasources, update fields, add a components to placeholders. Paired with an assistant, it lets a developer describe a change in plain terms and have it carried out against the authoring environment, item by item.

In this post, I’ll cover what I used it for, the workflow that kept it safe, the gotchas that cost time, and where I used Sitecore PowerShell instead.

Where the MCP fit

The MCP earned its place on work that needs judgment per item but is too repetitive to do by hand. I used it for page-by-page migration of news, landing pages, events, etc. guided by a written playbook, and for the long tail of fixes around the bulk imports.

Task	What the MCP did	Scale
Event venue cleanup	Read every event, proposed a split of free-text venues into venue, street, city, state and ZIP, then applied the approved rows	233 events read, 37 events updated across 103 language versions
Redirect maps	Compared the redirect spec against the maps in Sitecore, added missing entries, corrected targets that pointed at old URLs	24 entries added, 83 targets corrected
Seasonal data	Built a new set of income-limit items from two spreadsheets	21 items, 678 ZIP codes
Component rebuilds	Turned document links buried in body copy into tile-grid components	7 grids, 64 tiles on 4 pages
Field cleanup	Cleared a deprecated field and stripped inline alignment styles	100 language versions

Each change needed the assistant to read the current content first, decide what to do with it, and write back something specific. That read-decide-write loop is what the MCP makes cheap.

A repeatable workflow

Every change followed the same five steps:

1. Inventory. Read the current state before proposing anything. For the events cleanup that meant pulling the venue fields from all 233 event pages, in every language that had a version.
2. Propose. Turn the reads into a reviewable artifact, usually a spreadsheet with the current value, the proposed value and a note on anything inferred. Rows that needed a guess (a missing ZIP, a rewritten venue name) were highlighted.
3. Review. A person approves the plan, not the assistant. On the venue work, the reviewer approved the clean rows first and the inferred ones in a second pass.
4. Apply with a guard. Before each write, re-read the item and confirm it still matches the value captured in step 1. If an editor changed it in the meantime, skip it and report it.
5. Verify. Read every written item back and compare it with what was intended. Keep the before values so any change can be reversed.

I wrote these rules down as a playbook the assistant loads at the start of each session: field mappings, component patterns, naming conventions and the “never” list (never publish, never delete, never create a language version that doesn’t exist). The playbook went through several versions as I learned more about what could go wrong and what worked well.

A couple gotchas…

The MCP has its limitations, and learning/understanding those helped me to create a better workflow for subsequent migrations:

Gotcha	What happened	What I changed
Final vs shared layout	The add-component tool writes to the page’s Final layout. The requirement was the Shared layout, so the MCP couldn’t place the components where they belonged.	Check the page’s layout editing kind first. Create datasources with the MCP and place renderings with a script when Shared is required.
Language versions	Writing to a language that has no version creates one. Read-backs of versioned fields can also differ by language.	Read each language first and never write to one that reports version 0.
Language fallback on Edge	With item fallback enabled, publishing creates fallback copies in every language. Anything that lists “available languages” from Edge then sees all of them.	Test language-aware components against the live Edge endpoint, not only preview.
Capped and oversized responses	Child listings stop at 50 items. A site-wide page list returned over 100 KB.	Walk large folders item by item. Save big responses to disk and process them with a script instead of reading them in context.
Truncated item names	Long news item names were cut short, so their URLs were shorter than the legacy slugs. Redirects built from the slugs would have 404’d.	Build redirect targets from the real page URLs in the site’s page list.
Read-after-write lag	A re-read right after an update sometimes returned the old value.	Re-read once more after a short wait before calling a write failed.
Workflow states	Updating an item in a final workflow state creates a new version instead of editing in place.	Check the version number in every update response.
Session drops	The connector disconnected or needed re-authorizing several times a week.	Make every step resumable: plans and logs live in files, not in the conversation.

When to switch to Sitecore PowerShell

I used Sitecore PowerShell Extensions (SPE) when the job was large, structural, or outside what the MCP exposes. The assistant still did the hard part: it wrote the script from what it had learned through the MCP, and I just ran it in the ISE.

Three cases pushed us there:

• Layout XML. The pages’ __Renderings field holds a delta against the template’s standard values (p:p="1" with p:after rules), not a full layout. Parsing it directly found none of the components. The fix was to merge with LayoutField.GetFieldValue, insert the rendering, and save with LayoutField.SetFieldValue, which writes the delta back.
• Volume. A scan of every text field under the site’s Home folder for lists missing an Oxford comma had to read thousands of items. That is script territory, and even the script needed a per-template field cache and progress logging before it finished reliably.
• Fields the MCP doesn’t show. System fields like __Sortorder and __Final Renderings weren’t returned by the item tools for content items, so anything that depends on them goes to SPE.

The split that worked: use the MCP to explore, decide and create content; use SPE for bulk changes and anything touching layout or system fields. Every script started in report-only mode ($whatIf = $true) and wrote a JSON backup when it ran for real.

Guardrails that kept content safe

An assistant with write access to the authoring environment is only as safe as the rules around it. Mine were simple, and they held across every task above.

• Nothing gets published. Every change landed in the authoring database. Content editors reviewed in Page Builder and published on their own schedule.
• Nothing gets deleted. Items replaced by a merge were renamed and kept, not removed. Deletes stayed a human action.
• No silent overwrites. A write only went ahead if the field still held the value read during the inventory. For example, that check caught a Portuguese venue name that differed from the English one by a single translated word.
• Judgment calls go to a person. When a spreadsheet row was marked for change but the edit would have been wrong, the assistant held it back and said why instead of applying it. One example was a comma that would have split “heating and cooling equipment” in two.
• Large reads go to helpers. Reading 233 events or 43 headline items across three languages ran in parallel sub-agents that wrote results to files. The main session stayed focused, and every number in the summary came from those files, not from memory.
• Every write is logged. Each run produced a log of item, language, result and version, plus the before values.

Takeaways

The Marketer MCP is a strong fit for content work that needs a decision per item, and a weak fit for bulk or structural changes.

• Read before you write, and write only when the item still matches what you read.
• Put a reviewable artifact between the plan and the change. A spreadsheet with a Change column works great.
• Know which layout the tools edit. If your team works in the Shared layout, plan on scripts for placement.
• Treat language versions as separate items, and test anything language-aware against the live Edge endpoint.
• Keep plans, logs and backups in files, so a dropped connection costs minutes, not the afternoon.
• Write the rules down. A playbook the assistant loads every session is what made the hundredth change as careful as the first.

Documentation for the Sitecore Marketer MCP can be found here:

https://doc.sitecore.com/sai/en/users/sitecoreai/sitecore-marketer-mcp-server.html