Hello Sitecorian Community! 👋
This is the blog I have been building toward across the whole series. Blogs 1–3 covered the foundations — understanding MCP, building a minimal .NET server, and setting up Anton Tishchenko’s community server against a live XP instance. All of that was preparation for this: building something genuinely mine, shaped around the actual work I do every day on a Sitecore project.
The Problem I Wanted to Solve
When I started thinking about what to build, the answer came quickly — because the pain was already obvious.
On every Sitecore project I have worked on, there is a category of work that is critical but relentlessly repetitive: managing Content Security Domain (CSD) role access. CSD is Sitecore’s standard security model for controlling which roles can read, write, rename, create, delete, or administer content nodes in the content tree.
On the surface it sounds simple — give a role access to a path. In practice, on an active project with multiple content authors, developers, and client stakeholders all requesting access at different points, it turns into a constant stream of small but time-consuming tasks.
The Before: A Manual, Repetitive Grind
Here is what the daily reality looked like before this server existed.
Every request followed the same path through the Sitecore Security Editor:
- Open the Security Editor in the Sitecore Content Editor
- Search for the role by name — sounds trivial, but role names across multiple domains (
sitecore\,cog\, client-specific) are easy to get wrong, especially for roles you don't work with daily - Navigate to each content node — sometimes a single path, often multiple paths (content root + media library root for the same site)
- Tick the correct permission type — CSD access (Read + Write) or CSD Admin (6 rights), with inheritance enabled so child items pick it up
- Repeat for every path in the request — a single request often covers 2–4 paths
- Repeat the whole thing for every role — some requests cover multiple roles at once
- Verify the rules were applied correctly and propagated as expected
The hidden cost: this work required a developer. It was not something a BA or project manager could safely do through the Sitecore UI. Every request became a ticket, a context switch, an interruption to actual development work — adding zero feature value, carrying real risk of human error.
The After: Natural Language + MCP
With the Sitecore MCP Server connected to VSCode, the same work now looks like this:
I need to set up CSD access for the "cgdev" team on the DemoSite.
1. Search for Sitecore roles matching "cgdev" to find the exact role names.
2. Grant CSD access (Read and Write) for the found roles on:
- /sitecore/content/DemoSite
- /sitecore/media library/DemoSite
3. Also grant CSD Admin access to any role matching "cgadmin" on the same paths.GitHub Copilot in agent mode chains the tool calls in sequence — search, then grant, then confirm — and summarises the result. The whole thing takes under a minute. No Security Editor. No navigation. No repeated clicking across paths and roles.
The CSD Tools — Five Tools That Changed My Daily Workflow
The server exposes five tools specifically for CSD role access management. Here is each one in detail.
SearchCsdRole — Find the exact role identity first
Before granting or revoking access, you need the exact role identity string — including the domain prefix. On a real project with multiple domains (sitecore\, cog\, client-specific), guessing is error-prone.
This tool searches across all Sitecore domains by partial name match and returns the exact identities.
Search for Sitecore roles matching the name "cgdev".Returns results like sitecore\cgdev, cog\cgdeveloper — whichever match. You pass those exact strings to the grant or revoke tools. This one step alone eliminates a common class of access mistakes.
GrantCsdAccess — Read + Write with inheritance
Grants CSD access (Read and Write) to one or more roles across one or more content paths. All rules apply with PropagationType Any, meaning they inherit to all child items automatically.
Grant CSD access for the role "sitecore\cgdev" on the following paths:
- /sitecore/content/DemoSite
- /sitecore/media library/DemoSiteYou can also pass multiple roles at once. What used to be 4 separate Security Editor operations — 2 roles × 2 paths — is now one prompt.
Safety behaviour: paths that do not exist in Sitecore are reported as PathNotFound and skipped. The tool never silently fails and never applies partial access without telling you.
GrantCsdAdminAccess — Full admin rights with inheritance
Grants full CSD Admin access — Read, Write, Rename, Create, Delete, and Administer — with inheritance. Used for roles that need full editorial control over a site section, not just content authoring. Previously this required manually ticking six checkboxes per role per path in the Security Editor — easy to miss one under time pressure.
Grant CSD Admin access to the role "sitecore\cgadmin" on /sitecore/content/DemoSite
and /sitecore/media library/DemoSite.RevokeCsdAccess — Remove Read + Write safely
Removes CSD Read and Write Allow rules from roles on specified content paths. Designed for offboarding team members or restructuring access when a content section is reorganised.
Revoke CSD access for "sitecore\cgdev" on /sitecore/content/DemoSite
and /sitecore/media library/DemoSite.The most important design decision in this tool: it reads the item’s explicit ACL, filters out only the target Allow entries for the specified role, and resets the ACL with those entries removed. No Deny rules are ever written. A mistake during a revoke operation should never lock someone out of Sitecore content unexpectedly. This constraint is enforced in code — it cannot be overridden by a prompt.
If a role had no rules on an item, the tool reports RulesRevoked: 0 for that path and continues. It never fails silently.
RevokeCsdAdminAccess — Remove all 6 admin rights safely
Same safe revoke behaviour, but targets all six CSD Admin rights. Used when a role is being downgraded from admin to standard CSD access, or fully removed from a section.
Revoke all CSD Admin permissions for "sitecore\cgadmin" on /sitecore/content/DemoSite.CSD Access Rights Reference
How the CSD Tools Work Under the Hood
The CSD tools build inline SPE (Sitecore PowerShell Extensions) scripts at call time and execute them through the same PowerShell remoting client used by the RunSitecorePowerShellScript tool.
- Role searches use
Get-Role -Filterwith the partial name you provide - Access grants use
New-ItemAclandAdd-ItemAclwithPropagationType Any - Access revokes read the item’s full explicit ACL, filter out the target
Allowentries for the specified role, and apply the cleaned ACL back withSet-ItemAcl— noDenyrules are ever constructed or written
The Time Saving — In Real Numbers
Across a normal working week, that is roughly 8–10 hours of developer time moving from access management back to actual development work.
The Other Tools in the Server
QuerySitecoreGraphQl
Run any GraphQL query against a Sitecore schema (edge, master, core). Handles the HTTP POST with the sc_apikey header. Supports variables and schema introspection.
Query the Sitecore Home item via GraphQL using the path /sitecore/content/Home in English.
Run a Sitecore GraphQL introspection query to list all available types on the edge schema.GetSitecoreItemByPath
Retrieve a Sitecore item and all its fields by content tree path using the Item Service API (SSC). Supports any database and language.
Get the Sitecore item /sitecore/content/Home from the web database and tell me
if it has been published — check the __Updated field.RunSitecorePowerShellScript
Execute any script via SPE remoting — the most open-ended tool in the set. Copilot constructs the script from your intent, or you write it yourself.
Run a Sitecore PowerShell script to get all direct children of /sitecore/content/Home
and return their Name, ID, and TemplateName as JSON.
Run a Sitecore PowerShell script to clear all Sitecore caches on the CM server.Program.cs — How It All Wires Up
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
var builder = Host.CreateApplicationBuilder(args);
// All logs to stderr - stdout is reserved for MCP protocol messages
builder.Logging.AddConsole(o => o.LogToStandardErrorThreshold = LogLevel.Trace);
builder.Services
.AddMcpServer()
.WithStdioServerTransport()
.WithTools<GraphQlTools>()
.WithTools<ItemServiceTools>()
.WithTools<PowerShellTools>()
.WithTools<CsdAccessTools>();
await builder.Build().RunAsync();Each tool class registered independently with .WithTools<T>(). Adding a new tool category is one line.
Prerequisites
- .NET 8 SDK
- Sitecore XP or XM CM instance with GraphQL endpoint enabled, Item Service (SSC) enabled, and SPE installed with remoting enabled
Getting Started
git clone https://github.com/gaurarun777/sitecore-mcp.git
cd sitecore-mcpOpen in VSCode — the .vscode/mcp.json prompts for all credentials interactively when the server starts. Nothing sensitive is hardcoded.
⭐ github.com/gaurarun777/sitecore-mcp
Key Lessons from Building This
Design safety into the tool, not into the prompt
The no-Deny-rules constraint in the CSD revoke tools is enforced in code. It cannot be overridden by any prompt. On tools that touch access control, safety behaviour belongs in the implementation — not in hoping the caller remembers the right instruction.
Search before act
The SearchCsdRole tool exists for a reason. Role names across multiple Sitecore domains are easy to misremember. Searching first and confirming the exact identity before granting or revoking is the difference between a clean operation and an access mistake that takes time to diagnose and fix.
Repetitive work is the right first target
The CSD tools did not replace complex, high-judgment Sitecore development work. They replaced work that was clearly repetitive, time-consuming, and low-judgment — the kind where the value is accuracy and speed, not deep thinking. That is always the right first target for any automation.
One prompt can chain multiple tool calls
Copilot in agent mode chains tool calls automatically. You do not need to build orchestration into the server. Design tools to be focused and single-purpose — let the AI chain them together in response to a compound prompt.
The Full Journey
When I sat in that SUGCON India 2026 session, I wasn’t thinking about access management scripts. But when I looked at where developer time was actually going on the project, the answer was obvious. The MCP server did not solve an interesting engineering problem — it solved a real, daily, expensive one.
That is probably the most useful thing you can build.
Till then, Happy Sitecoring! 😊
References:
github.com/gaurarun777/sitecore-mcp
Microsoft Learn — Build MCP Server with C#
Flux Digital — Sitecore MCP Server with XP + VSCode & CoPilot
Anton Tishchenko — mcp-sitecore-server (GitHub)
SUGCON India 2026 — sitecoreknowledgeshare.blogspot.com