Hide Wildcard URLs in sitemap.xml with the Sitecore MCP Server
A while ago I wrote a blog about hiding wildcard URLs in the sitemap.xml. For that solution I used a PowerShell script, because it was easy to automate and worked well when you have many wildcard items. In this new blog I want to see if we can do the same using the Sitecore MCP server. The MCP server uses modern Agent API calls, and is part of Sitecore’s AI tooling. It feels like a perfect place to automate tasks that we normally solve with PowerShell or custom code. Below is the video where I show the full process:
And yes it works great, but it helps when you need to know what you are doing. Here are my findings, details, and a few tips:
What I tried to solve In my Skatepark demo website I created several wildcard pages. A wildcard page is a page with the name *, or a page where the URL contains /*/. This pages are not giving a correct in the default sitemap.xml from JSS and the Content SDK. Wildcards should not show in the sitemap, so I want to set the NavigationFilter field with the correct GUID: {A0E7FF57-6994-4B09-AA21-104239628D5A} Normally I would add the GUID only if it doesn’t exist (PowerShell version), but for this test with MCP I simply overwrite it, including possible other filters because retrieving the existing field value needs a workaround.
My Findings and Tips
1) MCP Server uses the Agent API (version 1.0) The MCP server is basically a thin layer on top of the Agent API. Because the API is public, human-readable, and REST-based, you can easily explore what each endpoint does. This makes experimenting with the MCP server much easier. You can also call this API directly from your own code. In my project Sitecore Commander, I use the API for automation examples.
2) Retrieving items gives only a small set of fields (for now) When you call “Retrieve a content item by ID” or similar endpoints, you currently get only a very small number of fields back, the Content section fields.
That means fields like:
SEO metadata
SXA Tags
Navigation Filter
Other custom sections
are not returned yet. This makes it harder to check or combine the existing field values. The Agent API only returns the fields defined in the item's current template, and will not return any fields that are inherited from its base template. it is a Bug reference number AI-6372
Workaround Use Retrieve Page HTML via the get_page_html method. This includes:
the rendered content
metadata
field labels
and yes, also the Navigation Filter GUID
It’s not perfect, but it gives you access to more information than the basic item retrieval.
3) MCP Server is not aware of Sitecore-specific field types This is a very important one.
The API treats fields simply as strings. It does not know:
this is a GUID
this is a list of GUIDs separated by |
this is a Sitecore link field containing XML
this is a Rich Text field that should contain HTML
this is a Droplink / Multilist
etc.
So the MCP server will happily accept anything you send.
Examples that went wrong
I added a text component and the LLM decided to place JSON inside a Rich Text field (instead of HTML).
When generating a translation, the LLM tried to “translate” a Sitecore link field (XML), which broke the image because it changed the XML structure.
For NavigationFilter, the LLM does not know the value should be a GUID list, unless you tell it.
This means your LLM (or your own automation) should have basic Sitecore field knowledge, or you can easily break things.
4) Interpretation: The LLM understood wildcard URLs better than expected In the video I asked the MCP server (through the LLM) to “give me all items with the name *”. Instead of returning only items literally named *, the LLM also returned items that have a wildcard in the URL, which it recognized because the path contains ,-w-,.
This surprised me in a good way, because that is actually exactly what I needed.
My original PowerShell script does the same: the goal is not only to hide the wildcard item itself, but all URLs under that wildcard path. So the LLM interpretation matched the real use case, even though I was not fully aware of it at that moment.
5) Other ways (and why I avoided them) Before recording the video I noticed the NavigationFilter field is hard to read through the current API. Because of that, the LLM tried to help by searching the filesystem for .yml serialization files to find the field value.
Technically that approach can work, it only works when the test site is serialized to disk. My Skatepark site is not serialized, so searching the filesystem would not return the correct data. That’s why in the video I explicitly asked to use the MCP server only.
In the video everything went smoothly, even with some typos I made. For example, I typed "skateboard site" instead of "Skatepark site", but the LLM corrected it automatically. This shows MCP + LLM can handle small mistakes and still complete the task correctly.
Conclusion The MCP server is powerful and can absolutely replace many scripting tasks, including hiding wildcard pages in the sitemap.
But:
You need to understand what the API gives you (and what it does not).
You need to handle Sitecore field types manually.
You may need workarounds like the rendered HTML method.
The MCP server is not only for automation, I use it in development as well. The Visual Studio Code integration is great for quickly checking or retrieving items instead of clicking through the Content Editor.
Still, I am impressed with how well the Sitecore MCP server works, and I expect more fields and more methodes will be added soon.
PowerShell vs MCP Server (Conclusion)
PowerShell is very predictable. When you run a script, you always get the same result, and it is easy to repeat, test, and verify. This makes PowerShell a safe choice when you need to update many items in Sitecore.
Using the MCP server together with an LLM is much more flexible, but also more risky. The LLM can misunderstand a field, make a wrong interpretation, or change more than you expect. On a production environment this can be dangerous, especially when you want to modify many items at once.
Even with an LLM helping you, writing a good PowerShell script can take more time than you expect. The MCP server is fast, but not always the right tool for very complex tasks.
At the moment it still takes a lot of effort to backup and restore content, and there is no simple way to preview or review all changes before applying them. Until we have better tooling for this, we need to be careful when using MCP + LLM for bulk updates.
