📊 Introduction

What if your AI assistant could securely tap into your company’s database, browse your SitecoreAI (FKA XM Cloud) content, query your CRM, or talk directly to your internal business systems - all without you lifting a finger?

That’s exactly what Model Context Protocol (MCP) makes possible. And if you’re a .NET developer, building custom MCP tools in C# is the most practical way to get there.

In my previous articles, I explained:

• How MCP works with Sitecore Marketer MCP
• Why MCP is needed compared to Copilot, GenAI, and Agentic AI

Now the next step is understanding how to create your own MCP tool in .NET C# using the official MCP SDK .

Out-of-the-box MCP servers are useful, but enterprise projects often require custom tools.

Examples:

• Internal APIs
• Sitecore CMS operation / automation
• DevOps utilities
• Data services
• Marketing workflows
• Reporting tools

Creating a custom MCP tool allows AI agents to interact with your system safely.

This becomes important when using:

• Copilot
• AI Agents
• Agentic AI
• Claude / ChatGPT with MCP
• VS Code MCP integration

Microsoft and Anthropic jointly maintain the official MCP C# SDK , making .NET a first‑class platform for MCP development.

With the C# SDK, you can:

• Build MCP servers as simple console apps or ASP.NET services
• Expose tools using familiar .NET patterns
• Integrate cleanly with dependency injection and hosting
• Run locally (stdio) or remotely (HTTP/SSE)

The ModelContextProtocol SDK provides:

• Core MCP protocol implementation (transport layer, message handling)
• Attribute-based tool registration ([McpServerTool], [McpServerToolType])
• Built-in dependency injection support
• Async/await patterns for I/O operations
• Type-safe parameter handling with validation

The best place to start is the official QuickstartWeatherServer sample from the MCP C# SDK repository - a minimal, well-structured example that shows exactly how to build your first MCP server in .NET.

This sample demonstrates:

• Creating a minimal MCP server
• Registering tools using attributes
• Exposing those tools to MCP clients
• Returning structured responses

Simple by design - but it demonstrates the exact pattern you'll repeat for every custom MCP tool you build.

Basic flow:

1. Create MCP server project
2. Define tools using SDK attributes
3. Register tools in server
4. Run MCP server
5. Connect from client (VS Code / Copilot / AI Agent)

Example concept:

Below is a high-level overview of how to build a custom MCP server in .NET. For the complete implementation, full source code, and a real-world SitecoreAI (FKA XM Cloud) example, check out the GitHub repository: MCP C# SDK Tutorial with SitecoreAI Example

1. Create a new .NET project Start with a minimal ASP.NET Core or console host:

Target .NET 8 or later, as most MCP examples assume current LTS or preview runtimes.

Add the following package references :

• Microsoft.Data.Sqlite
• Microsoft.Extensions.Hosting
• ModelContextProtocol

2. Register the MCP server and transport Using an approach similar to the examples, you configure MCP in Program.cs:

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using McpSitecoreAiExample;

var builder = Host.CreateApplicationBuilder(args);

builder.Services.AddSingleton<MonkeyService>();
builder.Services.AddSingleton<SellingService>();
builder.Services.AddSingleton<SitecoreAIService>();

builder.Logging.AddConsole(consoleLogOptions =>
{
    // Configure all logs to go to stderr
    consoleLogOptions.LogToStandardErrorThreshold = LogLevel.Trace;
});

builder.Services
    .AddMcpServer()
    .WithStdioServerTransport()
    .WithToolsFromAssembly();

await builder.Build().RunAsync();

📦 Service Registration

• MonkeyService, SellingService, SitecoreAIService registered as Singletons - one shared instance per app lifetime
• SitecoreAIService is the key bridge connecting your MCP server to SitecoreAI

📋 Logging Configuration

• All logs redirected to stderr from Trace level upward
• Critical for Stdio transport - keeps stdout clean exclusively for MCP protocol messages

⚙️ MCP Server Wiring

• AddMcpServer() - registers MCP into the .NET DI pipeline; server name & version auto-resolved via assembly reflection
• WithStdioServerTransport() - sets Stdio as the communication channel; swap with WithHttpTransport() for web-hosted scenarios
• WithToolsFromAssembly() - auto-discovers all MCP tools via reflection; no manual registration needed

🔐 Optional Authentication

• Plug in API-key authentication via standard ASP.NET Core middleware for production-grade security

🚀 Host Execution

• RunAsync() keeps the process alive, listening for MCP messages from AI hosts like Claude Desktop or GitHub Copilot

3. Create the tool class:

This is where your MCP server comes to life. In C#, MCP tools are simply well-designed methods that your AI model can discover and call - think of them as structured entry points into your business logic.

A typical MCP tool class in .NET looks like this:

[McpServerToolType]
public static class SitecoreAITool
{

    [McpServerTool, Description("Retrieves child item details from Sitecore by specifying an item path or ID and language.")]
    public static async Task<string> GetChildDetails(SitecoreAIService sitecoreAIService,
            [Description("The item path (e.g., /sitecore/content/site-name/home) or item GUID (e.g., '{110D559F-DEA5-42EA-9C1C-8A5DF7E70EF9}')")] string path,
            [Description("Language code for the item (e.g., 'en' for English, 'de' for German). Default is 'en'.")] string language = "en",
            CancellationToken cancellationToken = default)
    {
        var childDetails = await sitecoreAIService.GetChildDetails(path, language);
        return JsonSerializer.Serialize(childDetails);
    }
}

• A class decorated with [McpServerToolType] - this tells the SDK it’s a tool container
• Individual methods marked with [McpServerTool], each with a clear Description so the AI understands what the tool does and when to use it

A few design principles worth following:

• Be goal-oriented, not CRUD-driven - instead of exposing a raw GetSales() method, name and describe it as “Summarise daily sales by channel” so the model can use it intelligently
• Separate reads from writes - mark read-only tools clearly and keep write operations minimal and auditable
• Fail gracefully - validate inputs early and return descriptive error messages, this helps the AI model self-correct rather than stall

AmitKumar-AK/mcp-dotnet-tutorial

Complete tutorial and guide for building Model Context Protocol (MCP) tools using C# .NET SDK. Includes step-by-step instructions, code examples, and a practical SitecoreAI MCP tool implementation to integrate AI capabilities with Sitecore content management.

C#

0

0

4. Run and connect from an AI host:

Once the server is running locally or in a container:

• Configure an MCP‑aware host like Claude Desktop, Gemini CLI or VS Code Copilot to connect to your server via stdio or HTTP.
• Point it at your executable or remote endpoint and provide any required API keys or environment variables.
• Ask natural language queries like Use the .NET MCP server to list the latest orders and highlight any anomalies and watch the host call your tools.

// .vscode/mcp.json
{
    "servers": {
        "mcp-sitecoreai": {
			"type": "stdio",
            "command": "dotnet",
            "args": [
                "run",
                "--project",
				"McpSitecoreAiExample.csproj",
            ]
        }
    },
	"inputs": []
}

Every MCP tool in .NET consists of three essential parts:

1. Tool Class with [McpServerToolType] Attribute
   This decorator tells the MCP server that this class contains tool definitions.

[McpServerToolType] public class CustomerTools { 
// Tool methods go here 
}

2. Tool Methods with [McpServerTool] Attribute
   Each public method decorated with [McpServerTool] becomes an AI-accessible tool.

[McpServerTool]
[Description("Retrieves customer information by customer ID")]
public async Task<CustomerData> GetCustomerById(
    [Description("The unique customer identifier")] int customerId,
    CancellationToken cancellationToken = default)
{
    // Implementation here
}

3. Method Descriptions Using [Description] Attribute
   Descriptions are critical - they tell the AI when and how to use your tool. Write them as if you’re instructing a human colleague.

❌ Bad Description:

[Description("Gets customer")]

✅ Good Description:

[Description("Retrieves complete customer profile including contact info, purchase history, and support tickets by customer ID. Use this when the user asks about a specific customer or needs detailed customer information.")]

In earlier articles, we explored how Model Context Protocol (MCP) enables AI assistants to perform real, meaningful actions - not just generate text. The Sitecore Marketer MCP server puts that theory into practice with a working, real-world implementation.

With custom MCP tools we can:

• Extend Sitecore automation
• Integrate internal services
• Build developer tools
• Enable AI-driven operations

This makes MCP a key part of modern architecture.

Enjoyed this guide? Give it a ⭐ and show your support!

Building custom MCP tools in .NET C# transforms AI assistants from generic chatbots into powerful, context-aware agents that understand your business. With the official C# SDK, dependency injection support, and .NET’s robust ecosystem, you can create production-ready MCP servers that securely bridge AI and enterprise systems.

Key Takeaways:

1. MCP tools are simple - Just C# classes with attributes
2. Descriptions matter - They guide AI decision-making
3. Follow .NET patterns - Async/await, DI, separation of concerns
4. Start small, iterate - Begin with 2-3 tools, expand based on usage
5. Security first - Never expose credentials, validate inputs, audit access

📘 MCP Server: Turning AI Thinking into Real Action

Modern enterprises no longer want AI that only writes or suggests - they want AI that can act.

The Model Context Protocol (MCP) Server is the missing infrastructure that makes this possible. It acts as a secure, standardized bridge that allows Copilot, Generative AI, and AI agents to interact with real enterprise systems, tools, and data - safely, audibly, and at scale.

By connecting AI models to real tools, MCP Servers enable Agentic AI and autonomous AI agents to perform real tasks such as creating content, validating changes, orchestrating workflows, and publishing results - all while enforcing permissions, audit trails, and enterprise governance.

This is why MCP Server is quickly becoming foundational infrastructure for modern AI architectures.

In this article, we'll clarify:

• What MCP Server actually does
• How it differs from related AI concepts
• Why it matters for enterprises
• How it works in practice using Sitecore Marketer MCP examples

Most AI systems - whether GenAI, Copilot, or even Agentic AI - can generate content or propose plans, but they cannot safely act on enterprise systems like Sitecore CMS, CRM, or business platforms on their own.

Without additional infrastructure, AI cannot:

• Create or update CMS content
• Trigger enterprise workflows
• Access live business data
• Execute multi‑step operations
• Work with enterprise permissions and security

This is where MCP Server (Model Context Protocol) fills the gap.

MCP Server allows AI systems to discover, understand, and invoke tools in a controlled way. It provides:

• Permission‑scoped execution
• Typed schemas for predictable behavior
• Tool discovery
• Full auditability

Generative AI models (such as GPT-4 or Claude) are the core intelligence layer / underlying engine. They excel at producing new content - text, code, summaries, and ideas - based on prompts.

Strengths

• Content creation
• Summaries and ideation

Limitations

• No execution capability
• No direct access to tools or systems
• No planning beyond a single response

Example

• Using ChatGPT to draft a blog post

Copilots embed GenAI directly into tools like VS Code, Microsoft 365, or Cursor. They observe user context and provide suggestions in real time.

Strengths

• In‑context recommendations
• Code completion and productivity boosts
• Excellent user experience

Limitations

• Not autonomous
• Limited to the host application
• Cannot orchestrate workflows across systems

Example

• GitHub Copilot recommending code snippets

AI Agents wrap GenAI with a specific goal and a set of tools. They can execute predefined tasks such as fetching data, find all broken links, filtering results, or performing simple operations.

Strengths

• Task execution
• API-based automation
• Goal‑oriented behavior

Limitations

• Dependent on available integrations
• Often rely on custom or fragile API wrappers
• Limited planning unless combined with Agentic AI

Example

• An agent retrieving flight data from an API

Agentic AI introduces autonomy, reasoning, and planning. Instead of following a script, it breaks goals into steps, selects tools, retries failures, and evaluates outcomes.

Strengths

• Multi-step planning
• Tool selection
• Self-evaluation and retries

Limitations

• Still needs secure access to systems
• Requires guardrails and validation
• Cannot safely discover tools without MCP

Example

• Planning a trip by checking weather, comparing flights, and booking within constraints

MCP Server is the execution and integration layer that allows AI systems to act safely.

What MCP Server Provides

• Standardized interface for AI-to-tool communication
• Tool discovery and invocation
• Secure, scoped permissions
• Typed schemas for predictable behavior
• Full audit logs and governance

It tells the AI:

• What actions are allowed
• Which tools can be used
• How to call them
• What inputs and outputs are expected

Without MCP Server, Agentic AI cannot reliably interact with enterprise systems.

Enterprise Execution Comparison: GenAI, Copilot, Agentic AI, and MCP Server

Capability Comparison Across AI Models and MCP Server

What it shows (at a glance):

Agentic AI and MCP Server play very different but complementary roles.

Agentic AI is responsible for thinking: understanding goals, reasoning, planning steps, choosing actions, and learning from outcomes. It behaves like a manager, deciding what should happen next.

MCP Server, on the other hand, is responsible for doing things safely. It acts as the execution and governance layer, exposing enterprise tools (CMS, CRM, APIs, databases) in a standardized, permission‑controlled way.

When Agentic AI decides to take action, it does not call enterprise systems directly. Instead, it invokes tools through the MCP Server, which:

• Validates permissions
• Enforces schemas
• Executes actions securely
• Records audit logs

This separation ensures that AI can act autonomously without bypassing enterprise security or governance.

MCP Server turns GenAI and Copilots into secure, action-capable digital teammates.

For Sitecore, the Marketer MCP enables AI to:

• Create and update pages
• Add or modify components
• Search and manage assets
• Update Fields

Using natural language commands from tools like VS Code Copilot, the MCP Server:

• Authenticates securely
• Maps intent to Sitecore Agent APIs
• Executes actions with governance
• Returns auditable results

This removes fragile custom integrations and standardizes AI-to-CMS communication across teams.

With Sitecore Marketer MCP:

• Agentic AI plans the steps
• MCP Server exposes the correct tools
• Sitecore Agent API executes securely

Developers can configure MCP in .vscode/mcp.json, turning the IDE into a Sitecore command center.

• Use GenAI for writing, summaries, ideation
• Use Copilot for productivity inside tools
• Use AI Agents for predefined automation
• Use Agentic AI for reasoning and orchestration
• Use MCP Server when AI must securely interact with real enterprise systems

Enjoyed this guide? Give it a ⭐ and show your support!

📊 Overview

Recently, I needed to work on a project and set up Sitecore 10.4.0 on a Windows 11 machine. The Sitecore 10.4.0 XM0 topology setup stopped working and started showing the error COPY failed: failed to create rwlayer: FSCTL_EXTEND_VOLUME. This error usually happens during image builds and highlights a conflict between Docker’s operations and the Windows file system’s space management.

This guide explains why the error happens, how to fix it quickly, and how to prevent it from happening again, even for large images and CI pipelines.

Error Message Variants

COPY failed: failed to create rwlayer: FSCTL_EXTEND_VOLUME \\?\Volume{GUID}
failed to create rwlayer: write \\?\Volume{GUID}: The volume for a file has been externally altered
ERROR: failed to solve: failed to create rwlayer

FSCTL_EXTEND_VOLUME \\?\Volume{GUID}: The media is write protected.

Error Screenshot

Impact

• Build Process: Interrupts Docker image builds during COPY operations
• Development Workflow: Blocks containerized application development
• CI/CD Pipelines: Causes automated deployment failures
• Time Loss: Can result in hours of debugging and lost productivity

What is FSCTL_EXTEND_VOLUME?

The FSCTL_EXTEND_VOLUME error in Docker on Windows occurs when Docker tries to expand storage for a container’s writable layer but fails due to filesystem limitations. This issue often stems from resource exhaustion or configuration limits, preventing Windows from extending the storage volume. As a result, Docker cannot create the necessary read-write layer, halting the build process. Understanding and addressing these underlying resource constraints can help resolve the error efficiently.

When You'll See It:

• When running a docker build command, especially at a COPY or ADD step.
• When pulling or building images with lots of files.
• The base image usually downloads without issues; the problem starts when Docker tries to add a writable layer for your changes.
• After system updates or changes to your disk setup.

Before applying fixes, understanding the likely culprit can save time. The main causes are:

• Low free disk space on the host machine

• Bloated WSL2 VHDX file after months of builds

• Uncontrolled growth of Docker images and cache

• Large COPY commands in Dockerfiles

• Not enough memory allocated to WSL2

• Antivirus interference with Docker files, like BitLocker

• Corrupted Docker Desktop storage

Quick Diagnostic Commands:

# Check host disk space
Get-PSDrive C | Format-Table Name, @{n='Free(GB)';e={[math]::Round($_.Free/1GB,2)}}

# Check Docker disk usage
docker system df

Output:

Follow these solutions in order, starting with the simplest and most likely to succeed.

Solution 1: Free Up Disk Space (Quick Win)

Docker quietly accumulates:

• Old images
• Dangling layers
• Unused volumes
• Build cache

Script: Clean everything safely

Why it works: Directly addresses the most common cause: lack of free space. 👉 Aim for at least 20–30 GB free space on your system drive.

Solution 2: Reset Docker Desktop to Factory Settings or Clear Cache

⚠️ Warning: This removes all images, containers, and volumes.
Action: Use Docker Desktop’s UI: Troubleshoot > Reset to factory defaults or Clear / Purge data

Why it works: Eliminates corruption in Docker’s internal data structures, offering a clean slate.

Solution 3: Update BitLocker Drive Encryption

The value of FDVDenyWriteAccess is set to 1 at the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies\Microsoft\FVE registry key. This key manages BitLocker Drive Encryption (FVE = Full Volume Encryption) policies, which control security settings for removable drives and device encryption behavior. It is often used to block writing to non-encrypted USB drives or to turn off automatic device encryption.

Before Update

To fix the FSCTL\_EXTEND\_VOLUME write protection error, you need ADMIN access to change the value of FDVDenyWriteAccess to 0.

After Update

Solution 4: Install the Latest Version of Docker Desktop

Install the latest version of Docker Desktop and before that clear the content present at %ProgramData%\docker on Windows Server.

Solution 5: Configure Antivirus Exclusions

Action: Add Docker and WSL2 paths to your antivirus software’s exclusion list.

Key Paths to Exclude: C:\Program Files\Docker, %LOCALAPPDATA%\Docker, %LOCALAPPDATA%\Packages\*WSL*, \\wsl$.
Why it works: Prevents real-time scanning from interfering with Docker’s rapid file system operations.

Regular Maintenance Schedule

Create a maintenance calendar:

Monitoring Dashboards

Monitors Docker Desktop health metrics including disk space, WSL2 VHDX size, and Docker resource usage. Provides warnings when disk space falls below thresholds.

Script: Monitors Docker Desktop health

Output

Event Viewer Analysis

Retrieves and analyzes Windows Event Logs for errors and warnings related to Docker Desktop, Hyper-V, and WSL2 (Windows Subsystem for Linux).

Script: Retrieves and analyzes Windows Event

Output

Performance Monitoring

Real-time Docker Performance Monitor

Script: Docker Performance Monitor

Output

Enjoyed this guide? Give it a ⭐ and show your support!

To effectively tackle the Docker FSCTL_EXTEND_VOLUME error on Windows, focus on freeing disk space, compacting the WSL2 VHDX file, and optimizing resource limits. Regular maintenance and cleanup will prevent build failures, ensuring smooth and reliable Docker Desktop performance.

AmitKumar-AK/Sitecore-XM0-Topology

This repo will provide Sitecore Container images for XP0, XP1, XM0 and XM1 topologies. With Sitecore XM0 Topology Container Images, you can encapsulate the entire Sitecore XM environment, including its dependencies, configurations, and code, into a lightweight, isolated container.

TypeScript

0

0

Being part of this community is very rewarding. The MVP program recognizes people who do more than just their daily work - by giving practical advice, sharing solutions, supporting others, and helping to speed up the use of new Sitecore features.

The Sitecore MVP award honors professionals who:

• Demonstrate deep, hands‑on expertise with Sitecore products

• Contribute consistently across blogs, videos, webinars, open‑source work, community forums, and events

• Share learning from real implementations to support developers, marketers, and strategists

• Provide valuable product feedback and participate in beta programs

• Engage actively in local and global communities to uplift others

  Sitecore MVP Award

  It’s more than a technical milestone - it’s about giving back, creating impact, and helping the community grow.

🙏 A Heartfelt Thank You

This achievement wouldn’t be possible without the trust, support, and encouragement from my teams, colleagues, leadership, and the wider Sitecore community. Every discussion, collaboration, and opportunity has contributed to this journey.

I look forward to continuing to learn, share, and support others as we move into an exciting future shaped by Sitecore and AI‑driven digital experiences.

Thank you all once again for your support!

Credly Badge

Issued by Sitecore

A Sitecore MVP is an individual with expertise in Sitecore products who actively participates in online and offline communities to share their knowledge and expertise with other Sitecore partners and customers. These individuals have made significant contributions that drive forward the success of other members of the community.

Sitecore Technology MVP 2026

The Model Context Protocol (MCP) is an open standard that changes how AI tools work by linking AI apps to outside systems like data sources, tools, and workflows. Instead of using fragile, custom connections, it offers a unified, neutral way for any AI that supports MCP to easily connect with MCP servers. With more than 17,000 servers, MCP works with many applications, from web browsing to managing enterprise content.

In enterprise projects like Sitecore implementations , it’s important to use curated, secure, and well-managed MCP servers. Created by Anthropic , MCP sets a standard for how AI models connect to outside systems, ensuring they work well with AI clients like Claude , ChatGPT , and VS Code Copilot . This protocol allows AI models to safely access data, tools, and business workflows, improving flexibility and integration.

What it shows (at a glance):

• An AI app (host) uses an MCP client to connect to an MCP server.
• Messages use JSON‑RPC over stdio (local) or Streamable HTTP (remote).
• The server exposes three core capabilities: Tools, Resources, and Prompts.
• Basic flow: discover → invoke tool → return results/context

📹 Learn More About MCP

Sitecore Marketer MCP is a powerful tool that changes content management by adding advanced AI features to the SitecoreAI platform. This server uses the SitecoreAI Agent API to allow smooth interactions between AI assistants and Sitecore's marketing tools . It lets users manage content, assets, and data with natural language commands , making workflows easier and boosting productivity. Unlike traditional APIs, it is user-friendly for both developers and marketers, providing a more flexible and secure content management experience.

Built on the open-standard Model Context Protocol (MCP) , Sitecore Marketer MCP lets AI agents safely work with Sitecore’s marketing tools. This integration allows AI to not only offer suggestions but also perform actions like creating or editing content and optimizing campaigns, without needing manual UI navigation or complex API calls. The protocol includes safeguards like scoped permissions and audit trails to ensure secure and efficient operations. By allowing faster experimentation with less risk, Sitecore Marketer MCP helps marketers innovate and adapt quickly, making it a key feature in Sitecore’s latest updates and discussions.

Why these components?:

• Marketer MCP exposes "tools" that directly map to business‑level actions (e.g., create page, add component, upload asset). Those tools proxy to Agent API endpoints, so AI assistants can perform actions from natural‑language prompts - no manual UI or raw API calls.
• Security & governance: operations run under your existing Sitecore roles with auditability and human‑in‑the‑loop approval rules where configured.
• Transport & protocol: Requests flow via MCP (JSON‑RPC) over Streamable HTTP (remote) or stdio (local), following the standard MCP architecture.

List of available tools from Sitecore Marketer MCP

By default, all the Marketer MCP tools are enabled. To fully use the Marketer MCP, it’s recommended to enable each tool. Each tool matches an endpoint of the Agent API used by the MCP to perform actions in Sitecore.

🗂️ Site Management

📄 Page Management

📃 Content Management

🛠️ Component Tools

🖼️ Asset Management

👤 Personalization

Integrating the Marketer MCP server with Visual Studio Code and GitHub Copilot:

• Transforms your development environment into a powerful Sitecore content assistant.

• This integration enhances the developer experience by turning VS Code into a comprehensive content-orchestration hub, allowing seamless interaction with Sitecore’s AI-driven features.

• With native support for MCP servers through GitHub Copilot and related extensions, users can query Sitecore content, generate code snippets aligned with Sitecore schemas, and automate marketing tasks using natural language prompts.

  What is SitecoreAI (FKA XM Cloud)?

  To learn more about SitecoreAI (FKA XM Cloud), watch the video below for detailed information.

  
  

Step-by-Step: VS Code Configuration

1. Prerequisites:

• Visual Studio Code with the GitHub Copilot extension enabled.

• Access to the Sitecore Marketer MCP server (typically provided via a specific URL https://edge-platform.sitecorecloud.io/mcp/marketer-mcp-prod from your Sitecore setup).

• Ensure your organization’s Copilot administrator has enabled the necessary permissions.

  Important

  A common hurdle: If the START MCP SERVER option doesn’t appear later, your admin may need to re-enable MCP access in the Copilot admin UI, as noted in related VS Code issues here

2. Configuration in VS Code:

Create or edit a file at .vscode/mcp.json in your project root (or workspace) or a user-level mcp.json (C:\Users\[UserName]\AppData\Roaming\Code\User). Add your MCP server entry. Example for a hosted/remote server (adapt URL to your Sitecore Marketer MCP endpoint):

// Sitecore Marketer MCP Server configuration for AI-driven content management in Visual Studio Code.
// Enables integration with SitecoreAI, and Copilot for advanced marketing automation, 
// content orchestration, and secure API access.
// For more details, visit: https://doc.sitecore.com/sai/en/users/sitecoreai/marketer-mcp.html

  {
    "servers": {
          "sitecore-marketer-mcp": {
        "url": "https://edge-platform.sitecorecloud.io/mcp/marketer-mcp-prod",
        "auth": {
          "type": "external"
        },
        "type": "http"
      }
      }
  }

3. Restart and Use:

i) Save the mcp.json file.

ii) Fully restart VS Code and ensure you are signed into Copilot.

iii) Once configured correctly, VS Code should detect it. Look for options like START MCP server or MCP-related commands in the Command Palette (Ctrl+Shift+P) or Copilot Chat.

iv) Visual Studio Code will expose the START MCP server option, allowing Copilot and other AI extensions to interact with the MCP server.

Getting Started with the Sitecore Marketer MCP Demo:

v) The AI in your editor (e.g., Copilot Chat) will now have access to the tools provided by the Sitecore Marketer MCP server.

4. Troubleshooting:

If the START MCP server option does not appear:

• Verify that GitHub Copilot is enabled for your account

• Ensure your organization has not disabled MCP access

• Contact your organization admin to re-enable MCP in the Copilot Admin UI

• For official Marketer MCP, confirm your Sitecore account has required permissions and the endpoint is correctly provisioned.

5. Utilization: Once connected:

• In GitHub Copilot Chat , use natural language prompts tied to Sitecore, e.g., Create a Sitecore content item for a new blog post or Generate JSS component code for a personalized banner from Sitecore data.

• Combine with VS Code’s AI features for code generation.

• Safely experiment with AI-driven Sitecore content changes and marketing tasks

• Extend to web chatbots or other tools by referencing the same MCP server.

• When you use a prompt like Create item with name [Item Name] based on template [template name], followed by Update field on Content Item, the update_fields_on_content_item tool is triggered. It will automatically use the newly created Item ID to update the content item with your specified values. The required JSON payload will look like this:

// Example: Update Sitecore content item fields using Marketer MCP tool in VS Code.
// Automate headless CMS workflows, AI-powered content updates, and marketing operations with SitecoreAI, 
// Copilot, and Experience Edge.
// Ideal for scalable, secure, and efficient Sitecore content management.
// More info: https://doc.sitecore.com/sai/en/users/sitecoreai/marketer-mcp.html

    {
      "fields": {
        "image": "<image mediaid=\"\" alt=\"Contoso Logo\" width=\"904\" height=\"460\" />",
        "paragraph1": "Lorem ipsum dolor sit amet, consectetur adipiscing elit",
        "title": "Lorem ipsum dolor"
      },
      "itemId": "dd8c3d91-b57b-4f0b-a574-e4c02b683b48"
    }

• When you use a prompt such as Add Component [Component Name] inside placeholder [Placeholder Name] on Page [Page Name], the add_component_on_page tool is triggered. It will generate a JSON payload similar to the following:

// Example: Add a component to a Sitecore page using the add_component_on_page tool.
// Streamline headless CMS personalization, automate component placement, and enhance marketing workflows with 
// SitecoreAI and Copilot.
// Supports scalable, AI-driven content management in Experience Edge and JSS environments.

   {
      "componentItemName": "Hero Banner",
      "componentRenderingId": "ccd1c539-a271-4fc0-ae04-0e78fa722b9b",
      "fields": {},
      "language": "en",
      "pageId": "82932c57-15b6-4720-9603-a2c1a397ba5b",
      "placeholderPath": "headless-main"
    }

Enjoyed this guide? Give it a ⭐ and show your support!

The Sitecore Marketer MCP revolutionizes content management by integrating AI capabilities through the open Model Context Protocol (MCP) and the safety-focused Agent API. This integration with Visual Studio Code enhances flexibility, safety, and scalability, empowering organizations to innovate rapidly while maintaining control over their Sitecore ecosystem. By adopting Sitecore Marketer MCP early, businesses position themselves at the forefront of AI-driven digital experiences, streamlining content management and bridging code with marketing tasks. For the latest setup, refer to Sitecore’s documentation on Marketer MCP .

AmitKumar-AK/sitecore-marketer-mcp-prompts

This repository provides ready-to-use mcp.json configuration and a collection of practical prompts for integrating Sitecore Marketer MCP with Visual Studio Code and GitHub Copilot. Use these resources to automate content management, marketing workflows, and personalization in Sitecore Headless, SitecoreAI and Experience Edge environments.

null

0

0

🏁 Introduction

When you migrate from a traditional Sitecore CMS to Sitecore Headless and Sitecore’s Composable DXP, and there may be business logic in Sitecore MVC which might be accessing the system fields (__Created, __Updated) and you also need these system fields in GraphQL queries for rendering in JSS components or Next.js applications. This article explains how to configure your setup to make these Sitecore standard fields (Created Date, Updated Date) available and how to query them correctly.

The official Sitecore documentation Making fields from the standard template publishable suggests adding a patch configuration to include system fields in GraphQL queries. However, this approach is designed for SitecoreAI (formerly XM Cloud) and does not work for Sitecore XP/XM Headless Services.

Here’s the patch configuration that fails in Sitecore XP or Sitecore XM Headless setups:

<!-- Sitecore GraphQL/Experience Edge: This patch makes standard template fields (such as __Created, __Updated, __Owner) available for querying and publishing via the Experience Edge API. Enables access to system fields in headless and composable SitecoreAI solutions for enhanced content auditing, metadata, and integration scenarios. See Sitecore docs: Making fields from the standard template publishable. https://doc.sitecore.com/sai/en/developers/sitecoreai/making-fields-from-the-standard-template-publishable.html -->

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <api>
      <GraphQL>
        <defaults>
          <standardFieldsResolver>
            <supportedStandardFields>
              <field name="__Owner" />
              <field name="__Updated" />
              <field name="__Created" />
            </supportedStandardFields>
          </standardFieldsResolver>
        </defaults>
      </GraphQL>
    </api>
  </sitecore>
</configuration>

Sitecore system fields, such as Created and Updated date, are typically excluded from GraphQL schemas in Sitecore Headless setups to reduce data exposure. While SitecoreAI (formerly XM Cloud) offers patches for Experience Edge, these do not work for Sitecore XP or Sitecore XM 10.4 due to differences in GraphQL runtime configurations. Attempts to modify the schema using patches like <supportedStandardFields> are ineffective for Sitecore XP or Sitcore XM setups. As a result, queries for these system fields don't work because they aren't part of the default Edge provider schema.

Output:

To make Sitecore system fields available in the Edge schema (Edge GraphQL endpoint) for Sitecore XP or Sitecore XM implementation, you need to remove the default exclusion rule that filters out fields starting with __. This adjustment ensures system fields like Created and Updated dates are included when generating the Edge schema for templates.

<!-- To include access Sitecore system fields (in Sitecore Layout Service or Sitecore Headless Services) like Created and Updated dates in the Edge GraphQL schema for Sitecore XP or Sitecore XM, remove the default exclusion rule for fields starting with “__”. This adjustment allows these fields to be part of the Edge schema, enhancing data accessibility for templates. Sitecore get system fields in Sitecore headless -->
<configuration>
  <sitecore xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:role="http://www.sitecore.net/xmlconfig/role/">
    <api>
      <GraphQL>
        <defaults>
          <content>
            <schemaProviders>
              <edgeContent>
                <templates>
                  <fieldFilter>
                    <exclusions hint="raw:AddFilter">
                      <exclude name="__*">
                        <patch:delete/>
                      </exclude>
                    </exclusions>
                  </fieldFilter>
                </templates>
              </edgeContent>
            </schemaProviders>
          </content>
        </defaults>
      </GraphQL>
    </api>
  </sitecore>
</configuration>

Initially, your query looked like this:

    query GetItemSystemFields( $contextItem: String!) {
      #---- Retrieve Sitecore system fields by using field(name:"__Created") directly on the Sitecore item.
          layout(site: "Services",routePath: $contextItem, language:"en"){
               item
                  {
                    created: field(name:"__Created") {
                      value
                      jsonValue
                    }
                    updated: field(name:"__Updated") {
                      value
                      jsonValue
                    }
					rendered
                  }
              }
            }
            
# Query Variables:
# {"contextItem" :"/insights/achieving-work-life-balance"}

When querying these fields in GraphQL, you need a different approach. Instead of using field(name:"__Created"), query them directly at the template level.

On Sitecore 10.4 XP or Sitecore 10.4 XM Edge GraphQL, the usual pattern fails because standard fields aren’t exposed through the generic field() selector, even after you remove the field filter. Instead, these fields become strongly typed properties on the template. To access them, cast the item to its template and read the fields directly.

A working pattern is:

        query GetItemSystemFields( $contextItem: String!) {
      #---- Access Sitecore system fields by using field(name:"__Created") directly at the template level referenced by the Sitecore item.
          layout(site: "Services",routePath: $contextItem, language:"en"){
               item
                  {
                    ... on BlogPost
                    {
                     blog_created: field(name:"__Created") {
                        jsonValue
                      }
                      blog_updated: field(name:"__Updated") {
                        jsonValue
                      }                      
                    }                    
					rendered
                  }
              }
            }
            
# Query Variables:
# {"contextItem" :"/insights/achieving-work-life-balance"}

The jsonValue returns the field in a format that works with JSS field helpers, including DateField rendering in Next.js apps. This method aligns with all Sitecore JSS types and how to use them, offering typed access similar to custom fields.

Output:

This approach solves common questions like:

• How to get the Sitecore field updated date instead of item updated date?
• How to get the modified date and created date of a Sitecore item?
• How can we get Sitecore field type with GraphQL query?

Enjoyed this guide? Give it a ⭐ and show your support!

Accessing system fields in Sitecore 10.4 Headless SXA with Edge GraphQL involves knowing the schema limits. Using the Sitecore Patch Config for Edge GraphQL schema mentioned above, you can access created or modified dates system fields.

This approach keeps your headless project efficient while working within platform constraints. If you are migrating to SitecoreAI (formerly XM Cloud), review the SitecoreAI-specific configurations for better support.

AmitKumar-AK/Sitecore-XM0-Topology

This repo will provide Sitecore Container images for XP0, XP1, XM0 and XM1 topologies. With Sitecore XM0 Topology Container Images, you can encapsulate the entire Sitecore XM environment, including its dependencies, configurations, and code, into a lightweight, isolated container.

TypeScript

0

0

⚔️ Use case Background

While working on a SitecoreAI Content SDK project with Next.js, I received a requirement that We needed to display thousands of records - specifically blog posts and product details (dynamic wildcard pages) - stored in an external system (a Headless Commerce engine and a PIM). The goal was to support dynamic wildcard pages that behave like nested blog slugs while still resolving each request to a real item in the Sitecore content tree.

The business wanted:

• Dynamic pages generated from an external API.
• Nested URLs similar to a blog slug structure.
• No manual creation of Sitecore items for every page.
• Dynamic breadcrumbs and page titles.
• A scalable solution for future integrations like PIM or Headless Commerce.

Before starting the implementation, I reviewed Sitecore’s documentation on wildcard pages .

For example:

• To manage URLs like /blogs/my-first-post or /blogs/category/subcategory/article-slug, create a wildcard item under /blogs.
• The wildcard item uses a shared layout and components, but the actual content is determined dynamically at runtime based on the URL slug.

Benefits include:

• Less clutter in the content tree - no need to manually create pages for each external record.
• Easy integration with external APIs for real-time or cached data.
• Support for nested routes, like multi-level slugs such as blog categories.
• Dynamic updates to metadata, like page titles and breadcrumbs, for better SEO.

This is particularly useful for pulling data from external sources such as PIM systems, e-commerce catalogs, or custom APIs, enabling truly headless experiences.

1. Dynamic Wildcard Routing

File: src/app/[site]/[locale]/[[...path]]/page.tsx

Details: This project uses Next.js App Router using Content SDK which handles all routes with the help of src/app/[site]/[locale]/[[...path]]/page.tsx and it acts a catch‑all App Router entry.

This single dynamic route powers all wildcard and nested blog‑style URLs without duplicating static page files. At the same time, it keeps the routing logic consistent so that visual editing, server‑side rendering, and analytics all see the same canonical path. This forms the foundation for a flexible, wildcard‑aware routing model in the App Router.​

This approach ensures:

• No hardcoded routes
• Unlimited nesting
• Clean SEO-friendly URLs

2. Dynamic Context Provider

File: src/contexts/DynamicParamsContext.tsx, src/contexts/ProvidersWithParams.tsx

Details: Passes route params, slugs, and path info to all components via React context. This makes dynamic data (like blog slugs or path arrays) available throughout the app for rendering breadcrumbs, page titles, and more.

I introduced a context provider that:

• Extracts route parameters at runtime
• Makes the full slug available across components
• Keeps page components clean and reusable

This context becomes the single source of truth for:

• API queries
• Breadcrumb construction
• Page title resolution

🔗 DynamicParamsContext.tsx

// This context provides dynamic route parameters (id, slug, path, etc.)
// to all components in the Next.js App Router using Sitecore Content SDK.
// It enables features like dynamic breadcrumbs, page titles, and external API queries
// for deeply nested and wildcard routes, without needing multiple static files.
// Used in conjunction with ProvidersWithParams to inject route data from [[...path]] catch-all routes.

'use client';
import { createContext, useContext } from 'react';

// Type for dynamic route parameters extracted from Next.js App Router
export interface DynamicParams {
  id?: string;        // e.g. /blog/123 → id = '123'
  someslug?: string;  // e.g. /blog/123/slug → someslug = 'slug'
  path?: string[];    // Full path segments from [[...path]]
  blogSlug?: string;  // e.g. /blogs/[slug] → blogSlug = slug
}

// Context for sharing dynamic params across the app
export const DynamicParamsContext = createContext<DynamicParams>({});
// Hook for consuming dynamic params in any component
export const useDynamicParams = () => useContext(DynamicParamsContext);

🔗 ProvidersWithParams.tsx

// This client component wraps the app in DynamicParamsContext,
// providing dynamic route parameters to all child components.
// Used in Next.js App Router with Sitecore Content SDK to enable
// dynamic breadcrumbs, page titles, and API queries for wildcard/nested routes.
// Receives route params from [[...path]] and passes them via context.

'use client';
import { DynamicParamsContext } from 'src/contexts/DynamicParamsContext';
import Providers from 'src/Providers';
import Layout from 'src/Layout';

export default function ProvidersWithParams({ id, someslug, path, blogSlug, page, componentProps }) {
  return (
    <DynamicParamsContext.Provider value={{ id, someslug, path, blogSlug }}>
      <Providers page={page} componentProps={componentProps}>
        <Layout page={page} />
      </Providers>
    </DynamicParamsContext.Provider>
  );
}

File: src/components/breadcrumbs/Breadcrumb.tsx

Details: Breadcrumbs are generated based on the current route and content. Breadcrumbs are rendered for all nested routes using the path array from context.

Using the slug array:

• Each segment is converted into a breadcrumb node
• Labels are resolved dynamically (API response or formatted slug)
• Links are generated progressively based on hierarchy

This ensures breadcrumbs remain:

• SEO-friendly
• Accurate
• Fully dynamic

🔗 Breadcrumb.tsx

// Breadcrumb component for Next.js App Router using Sitecore Content SDK.
// Dynamically renders breadcrumbs for any nested/wildcard route using the path array from context.
// Enables SEO-friendly navigation and reflects the current content hierarchy without static routes.
// Consumes dynamic params from DynamicParamsContext, which is populated by ProvidersWithParams.

import React from 'react';
import { useDynamicParams } from 'src/contexts/DynamicParamsContext';

const Breadcrumb = () => {
  const { path } = useDynamicParams();
  return (
    <nav id="breadcrumb" className="breadcrumb">
      <a href="/">Home</a>
      {Array.isArray(path) && path.map((segment, idx) => (
        <span key={idx}>
          {' / '}
          <a href={`/${path.slice(0, idx + 1).join('/')}`}>{segment}</a>
        </span>
      ))}
    </nav>
  );
};

export default Breadcrumb;

File: src/app/[site]/[locale]/[[...path]]/page.tsx

Details: Page titles are generated based on the current route and content. Wildcard pages use the last path segment for the title if Sitecore returns a generic value (e.g., *).

This ensures:

• Unique titles per URL
• Better SEO indexing
• Improved click-through rates

Example conceptually:

• /blog/sitecore/wildcard-pages
• Title: Wildcard–Page

🔗 page.tsx

import { isDesignLibraryPreviewData } from "@sitecore-content-sdk/nextjs/editing";
import { notFound } from "next/navigation";
import { draftMode } from "next/headers";
import { SiteInfo } from "@sitecore-content-sdk/nextjs";
import sites from ".sitecore/sites.json";
import { routing } from "src/i18n/routing";
import scConfig from "sitecore.config";
import client from "src/lib/sitecore-client";
import Layout, { RouteFields } from "src/Layout";
import components from ".sitecore/component-map";
import Providers from "src/Providers";
import { NextIntlClientProvider } from "next-intl";
import { setRequestLocale } from "next-intl/server";
import ProvidersWithParams from 'src/contexts/ProvidersWithParams';

type PageProps = {
  params: Promise<{
    site: string;
    locale: string;
    path?: string[];
    [key: string]: string | string[] | undefined;
  }>;
  searchParams: Promise<{ [key: string]: string | string[] | undefined }>;
};


export default async function Page({ params, searchParams }: PageProps) {
  const { site, locale, path } = await params;

  let id, someslug, blogSlug;
  let isBlogDetail = false;
  if (Array.isArray(path)) {
    // blogs/[slug] → path = ['blogs', 'some-blog-slug']
    if (path[0] === 'blogs' && path.length === 2) {
      isBlogDetail = true;
      blogSlug = path[1];
    } else if (path.length === 1) {
      // Single-segment page, e.g., /About
      // You can use path[0] as the page name/slug
    } else if (path.length >= 3) {
      // Multi-segment, e.g., /mypath/123/slug
      id = path[path.length - 2];
      someslug = path[path.length - 1];
    }
  }

  const draft = await draftMode();

  // Set site and locale to be available in src/i18n/request.ts for fetching the dictionary
  setRequestLocale(`${site}_${locale}`);

  // Fetch the page data from Sitecore
  let page;
  if (draft.isEnabled) {
    const editingParams = await searchParams;
    if (isDesignLibraryPreviewData(editingParams)) {
      page = await client.getDesignLibraryData(editingParams);
    } else {
      page = await client.getPreview(editingParams);
    }
  } else {
    if (isBlogDetail && blogSlug) {
      // Fetch blog detail page by slug, e.g., from Sitecore or your API
      // Example: page = await client.getBlogDetail(blogSlug, { site, locale });
      page = await client.getPage(['blogs', blogSlug], { site, locale });
    } else {
      page = await client.getPage(path ?? [], { site, locale });
    }
  }

  // If the page is not found, return a 404
  if (!page) {
    notFound();
  }

  // Fetch the component data from Sitecore (Likely will be deprecated)
  const componentProps = await client.getComponentData(
    page.layout,
    {},
    components
  );

  // ProvidersWithParams wraps the app in a dynamic context provider, making route params
  // (id, slug, path, blogSlug) available to all components. This enables dynamic breadcrumbs,
  // page titles, and API queries for deeply nested/wildcard routes in the Next.js App Router
  // using Sitecore Content SDK. It receives route params from the catch-all [[...path]] route.
  return (
    <NextIntlClientProvider>
      <ProvidersWithParams id={id} someslug={someslug} path={path} page={page} componentProps={componentProps} blogSlug={blogSlug} />
    </NextIntlClientProvider>
  );
}

// This function gets called at build and export time to determine
// pages for SSG ("paths", as tokenized array).
export const generateStaticParams = async () => {
  if (process.env.NODE_ENV !== "development" && scConfig.generateStaticPaths) {
    // Filter sites to only include the sites this starter is designed to serve.
    // This prevents cross-site build errors when multiple starters share the same XM Cloud instance.
    const defaultSite = scConfig.defaultSite;
    const allowedSites = defaultSite
      ? sites
          .filter((site: SiteInfo) => site.name === defaultSite)
          .map((site: SiteInfo) => site.name)
      : sites.map((site: SiteInfo) => site.name);
    return await client.getAppRouterStaticParams(
      allowedSites,
      routing.locales.slice()
    );
  }
  return [];
};

// Metadata fields for the page.
export const generateMetadata = async ({ params }: PageProps) => {
  const { path, site, locale } = await params;

  // The same call as for rendering the page. Should be cached by default react behavior
  const page = await client.getPage(path ?? [], { site, locale });
  let title = (page?.layout.sitecore.route?.fields as RouteFields)?.Title?.value?.toString();
  // If title is '*' (wildcard), use the last path segment or fallback
  if (title === '*' && Array.isArray(path) && path.length > 0) {
    title = path[path.length - 1];
  }
  return {
    title: title || "Page",
  };
};

All without creating a new Sitecore item.

File: src/components/dynamic-data/DynamicData.tsx

Details: On each dynamic page, queries an external API (e.g., public dummy API) to fetch related records. Displays API data contextually based on the current route, demonstrating how external systems can be integrated with SitecoreAI content.

🔗 DynamicData.tsx

"use client";
// DynamicData component for Next.js App Router using Sitecore Content SDK.
// Consumes dynamic params from context and fetches external API data based on the current route.
// Demonstrates how to integrate external systems (e.g., PIM, Commerce) with Sitecore-driven pages.
// Useful for showing contextual data (e.g., blog slug, wildcard path) and API results on dynamic/wildcard pages.

import React, { useEffect, useState } from 'react';
import { useDynamicParams } from 'src/contexts/DynamicParamsContext';

const DUMMY_API_URL = 'https://jsonplaceholder.typicode.com/posts?_limit=3';

const DynamicData: React.FC = () => {
  const { blogSlug, path } = useDynamicParams();
  const [dummyData, setDummyData] = useState<any[]>([]);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    setLoading(true);
    fetch(DUMMY_API_URL)
      .then((res) => res.json())
      .then((data) => {
        setDummyData(data);
        setLoading(false);
      })
      .catch((err) => {
        setError('Failed to fetch dummy data');
        setLoading(false);
      });
  }, []);

  return (
    <div style={{ padding: '1rem', border: '1px solid #ccc', margin: '1rem 0' }}>
      <h2>Dynamic Data Component</h2>
      {blogSlug && (
        <div>
          <strong>Blog Slug:</strong> {blogSlug}
        </div>
      )}
      {path && path.length > 0 && (
        <div>
          <strong>Wildcard Path:</strong> {path.join(' / ')}
        </div>
      )}
      <div style={{ marginTop: '1rem' }}>
        <strong>Dummy API Data:</strong>
        {loading && <div>Loading...</div>}
        {error && <div style={{ color: 'red' }}>{error}</div>}
        {!loading && !error && (
          <ul>
            {dummyData.map((item) => (
              <li key={item.id}>
                <strong>{item.title}</strong>
                <div>{item.body}</div>
              </li>
            ))}
          </ul>
        )}
      </div>
    </div>
  );
};

export default DynamicData;

• Create Wildcard Items: In the Sitecore content tree, create items with names like * to act as wildcard placeholders
• Template Configuration: Ensure wildcard items use templates.
• Presentation Details: Assign layout and renderings that can handle dynamic content

SitecoreAI Content Tree:

• Blogs: /blogs/tech/ai/12345 resolves to a specific blog post, fetching details from Sitecore and/or an external API
• Articles: /articles/marketing/2024/5678 dynamically loads the article content and metadata
• Commerce: /products/category/shoes/sku123 pulls product data from a headless commerce API
• Nested Content: /about/team/leadership displays nested team info from Sitecore
• External Systems: /pim/items/sku999 fetches product info from a PIM system

• Use Wildcards for Scale: If your content lives in an external API, don’t sync it to Sitecore items. Use the * item.
• Context is King: Implement a DynamicParamsContext (as seen in the xmcloud-starter-js > DynamicParamsContext.tsx ) to manage route-specific data.
• SEO Matters: Always make sure your dynamic data is included in your SEO components, like Meta tags, OpenGraph, and Breadcrumbs.
• Performance: Use Next.js Incremental Static Regeneration (ISR) or strong caching for your external API calls to keep the dynamic pages very fast .

Dynamic Wildcard Routing and External API Integration Demo:

Dynamic wildcard routing in SitecoreAI (Sitecore XM Cloud) with Next.js App Router enables seamless integration of external content systems, such as PIM and headless commerce, using clean, SEO-friendly URLs. This approach allows editors to manage layouts and navigation efficiently, while developers maintain streamlined routing logic. By leveraging Sitecore’s wildcard functionality and Next.js dynamic routing , the solution supports scalable content orchestration, bridging static and dynamic data sources. Sitecore’s composable architecture further enhances flexibility by integrating modular components tailored to specific needs, allowing businesses to scale efficiently and maintain a cohesive digital experience. This modularity ensures agility and future-proofing in the digital ecosystem.

Enjoyed this guide? Give it a ⭐ and show your support!

AmitKumar-AK/xmcloud-starter-js

PowerShell

0

0

⚠️ Understanding the SitecoreAI Development Error

This security fatal: detected dubious ownership in repository error is particularly common in development environments where developers work with multiple code repositories with multiple id’s simultaneously and Git detects mismatched ownership.

fatal: detected dubious ownership in repository at 'C:/xmcloud-starter-js'
'C:/xmcloud-starter-js/.git' is owned by: 'x-x-x-xx-xxx'
but the current user is: 'x-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx'

Git’s dubious ownership warning is a critical security feature that ensures directory ownership is verified to prevent unauthorized access. This issue occurs when the current user differs from the directory owner, which is essential in environments where you are working with different Git Repositories of SitecoreAI and other Sitecore application repositories. Common scenarios include:

• Switching between repositories.
• Working on multiple microservices or headless repositories (e.g., SitecoreAI, specialized AI service repos).
• Working with your personal repositories alongside enterprise repositories.
• You use different credentials or user contexts to clone and work with repositories from various platforms (GitHub, Azure DevOps, GitLab).
• The local directory ownership (e.g., your Windows user SID) differs from the user who originally cloned the repository (e.g., running commands as an Administrator).

🛡 Step 1: Mark Your SitecoreAI Application Directory as Safe

To allow Git operations for your SitecoreAI repo (for example, C:/xmcloud-starter-js), run the following command in Command Prompt, PowerShell, or Git Bash:

  git config --global --add safe.directory C:/xmcloud-starter-js

👤 Step 2: Set Correct Git User for Your SitecoreAI Commits

After marking the directory as safe, configure Git so that your commits in SitecoreAI and Sitecore implementation repositories use the correct developer identity. Run:

  git config user.name "AmitKumar-AK"
  git config user.email "dev@contoso.com"

Next, update the remote URL to point to the correct GitHub repository and user:

🔗 Update Remote Repository URL

  git remote set-url origin https://AmitKumar-AK@github.com/AmitKumar-AK/xmcloud-starter-js.git

Before continuing development or committing Sitecore templates, renderings, or SitecoreAI-related code, verify the configuration:

    git config --get user.name
    git config --get user.email
    git remote -v

Check that:

• user.name is your intended Sitecore developer identity, which you configured in Step 2 .
• user.email is your intended Sitecore developer email address, which you configured in Step 2 .
• The remote URL points to the correct SitecoreAI repository, which you configured in Step 2 .

• Use one Git identity per organization
• Verify git config --list before committing any changes
• Avoid running Git commands as admin unless required
• Separate personal and enterprise repos

The Git detected dubious ownership error is a security feature, not a blocker.

For SitecoreAI development teams, the fix is simple:

1. Mark the repository as safe
2. Configure the correct Git user and remote URL

This ensures secure, traceable, and compliant development across SitecoreAI, and multi-repository environments.

🏁 Introduction

Unit testing plays a critical role in ensuring code quality, stability, and maintainability for modern headless CMS solutions. When working with SitecoreAI Content SDK Next.js applications, implementing a robust testing strategy is essential. This guide provides a comprehensive walkthrough for setting up unit testing in a SitecoreAI-powered Next.js project using Jest and React Testing Library. You’ll learn how to install the required dependencies, configure Jest for Next.js , and structure effective test cases for SitecoreAI components to achieve reliable and scalable applications. SitecoreAI

Before you begin setting up unit testing for SitecoreAI Content SDK Next.js applications, ensure your development environment is properly configured. Meeting these prerequisites will help you integrate Jest and React Testing Library seamlessly and avoid common setup issues.

You’ll need:

• Node.js (v14 or higher) for running Next.js and testing tools
• npm or Yarn as your package manager
• An existing SitecoreAI Content SDK Next.js project ready for testing
• Basic knowledge of React and TypeScript for writing and maintaining test cases

This setup leverages industry-standard tools for a robust testing stack:

• Jest: JavaScript testing framework
• React Testing Library: For React component testing
• TypeScript: For type-safe tests
• Jest DOM: Enhances DOM assertions for Sitecore component testing.

Step 1: Install Core Testing Dependencies

Navigate to your Sitecore Content SDK Next.js project directory and install the required packages:

cd xmcloud-starter-js/examples/kit-nextjs-article-starter
npm install --silent
npm ci --silent
npm install --save-dev jest @testing-library/react @testing-library/jest-dom @types/jest jest-environment-jsdom

Output of the Command:

Step 2: Add TypeScript Support

For TypeScript-enabled Sitecore projects:

npm install --save-dev ts-jest

Output of the Command:

Confirm all core packages are installed correctly:

npm list --depth=0 | Select-String "jest|testing"

Output of the Command:

Step 4: Create Jest Configuration

Create a jest.config.js file in your project root to handle Next.js integration and module mapping. This file loads your Next app, configures setupFilesAfterEnv, maps module aliases, and sets jest-environment-jsdom as the test environment.

Update jest.config.js to align with path aliases defined in tsconfig.json.

// jest.config.js file
const nextJest = require('next/jest');

const createJestConfig = nextJest({
  dir: './',
});

const customJestConfig = {
  setupFilesAfterEnv: ['<rootDir>/jest.setup.js'],
  moduleNameMapper: {
    '^@/(.*)$': '<rootDir>/src/$1',
    '^components/(.*)$': '<rootDir>/src/components/$1',
    '^shadcd/(.*)$': '<rootDir>/shadcn/$1',
    '^lib/(.*)$': '<rootDir>/src/lib/$1',
    '^temp/(.*)$': '<rootDir>/src/temp/$1',
    '^assets/(.*)$': '<rootDir>/src/assets/$1',
    '^enumerations/(.*)$': '<rootDir>/src/enumerations/$1',
    '^types/(.*)$': '<rootDir>/src/types/$1',
    '^graphql-types$': '<rootDir>/node_modules/@types/graphql-let/__generated__/__types__',
    '^react$': '<rootDir>/node_modules/react',
    '^@/tw/(.*)$': '<rootDir>/tailwind-config/$1',
  },
  testEnvironment: 'jest-environment-jsdom',
  testMatch: [
    '**/tests/**/*.(test|spec).(ts|tsx|js)',
    '**/__tests__/**/*.(test|spec).(ts|tsx|js)',
    '**/*.(test|spec).(ts|tsx|js)'
  ],
  testPathIgnorePatterns: ['<rootDir>/.next/', '<rootDir>/node_modules/'],
  collectCoverageFrom: ['src/**/*.{ts,tsx}', '!src/**/*.d.ts', '!src/**/*.stories.{ts,tsx}'],
};

module.exports = createJestConfig(customJestConfig);

Create jest.setup.js in your project root to import Jest DOM matchers:

// jest.setup.js file

import '@testing-library/jest-dom';

Step 6: Update TypeScript Configuration

Add Jest types to your tsconfig.json:

// tsconfig.json file

{
  "compilerOptions": {
    // ... other options
    "types": ["node", "jest"]
  }
}

Step 7: Add Test Scripts to package.json

Update your package.json:

// package.json file

{
  "scripts": {
    "test": "jest",
    "test:watch": "jest --watch",
    "test:coverage": "jest --coverage",
    "test:ci": "jest --ci --coverage --watchAll=false"
  }
}

if below entry present then update with "test": "jest":

// package.json file

{
  "scripts": {
    "test": "echo 'No tests implemented yet' && exit 0",
  }
}

Creating effective unit tests for SitecoreAI Content SDK Next.js components is key to ensuring your application performs reliably across different scenarios. Prioritize testing Sitecore-specific elements such as component fields and rendering variants.

Step 1: Create tests folder

Create a tests folder in your project root to store the unit test files.

Step 2: Create Test File for a SitecoreAI Next.js Component

Create a test file inside a tests/ folder, for example, examples\kit-nextjs-article-starter\tests\rich-text-block\RichTextBlock.test.tsx

Step 3: Key Testing Patterns

Mocking SitecoreAI Next.js Components

Since Sitecore Content SDK components like Link and NextImage are wrappers around native tags, they must be mocked to run outside a Sitecore/Next.js environment.

// Mock Sitecore Content SDK
jest.mock('@sitecore-content-sdk/nextjs', () => ({
  RichText: ({ field }: any) => (
    <div role="region" className="prose custom-style" data-component-name="rich-text-block" id="test-id">
      <div data-testid="rich-text">{field}</div>
    </div>
  ),
}));

// Mock NoDataFallback component
jest.mock('@/utils/NoDataFallback', () => ({
  NoDataFallback: () => <div data-testid="no-data">Rich text</div>,
}));

// Mock Sitecore SDK components
jest.mock('@sitecore-content-sdk/nextjs', () => ({
  Text: (props: any) => <span data-testid="text" {...props}>{props.field?.value}</span>,
  useSitecore: () => ({ page: { mode: { isEditing: false } } }),
}));

// Mock TextBanner variants (named export Default for each)
jest.mock('@/components/text-banner/TextBannerDefault.dev', () => ({
  Default: (props: any) => <div data-testid="text-banner-default">Default {props.isPageEditing ? 'editing' : 'view'}</div>,
}));

Creating Test Data Factories

Use functions to generate consistent mock data, making tests clean and easy to maintain.

// Helper to create mock props
const createMockProps = (overrides: any = {}) => ({
  params: {
    RenderingIdentifier: 'test-id',
    styles: 'custom-style',
    ...overrides.params,
  },
  fields: {
    Content: { value: '<p>Test Content</p>' },
    ...overrides.fields,
  },
});

// Usage
const props = createMockProps();
const props = createMockProps({
      fields: {
        Content: undefined, // Explicitly remove Content to trigger fallback
      },
    });
const props = createMockProps({
      params: { styles: 'mystyle', RenderingIdentifier: undefined },
    });

Step 1: Validate Setup and Configuration

Validate your Jest setup with npx jest --version and npx jest --showConfig before running individual or directory‑wide tests.

# Verify Jest installation and version
npx jest --version

# Run Jest configuration check
npx jest --showConfig

Run specific tests for faster debugging:

# Run tests for the Hero component
npm test tests\components\hero\Hero.test.tsx

Step 3: Run Tests by Name Pattern

# Run tests by name pattern
npx jest --testNamePattern="Hero"

Step 4: Run a Specific Test File with Coverage and Verbose Output

npx jest tests\components\hero\Hero.test.tsx --coverage --verbose

npm run test:coverage -- --testPathPattern=Hero --verbose

Step 6: Run All Tests Once

npm test

Step 7: Run Tests in Watch Mode

npm run test:watch

npm run test:ci

These commands help streamline your testing workflow, whether you’re developing locally, debugging a specific component, or running tests in a CI/CD pipeline. They also ensure you can easily view and improve your code coverage.

Step 1: Generate Coverage Reports

Generate detailed analysis of lines, functions, and branches:

npm run test:coverage

It will generate the report at \kit-nextjs-article-starter\coverage\lcov-report\index.html location:

✔ Testing Strategy

• Test behavior, not implementation
• Clear test names
• Use Arrange / Act / Assert
• Mock external APIs & Sitecore fields

✔ Component Testing Guidelines

• Test all component variants
• Cover empty or missing data cases
• Validate accessibility
• Confirm field mapping

✔ Organization

• Keep tests in a separate /tests folder
• Use factories for consistency
• Group related cases with describe()

Recommended File Structure

kit-nextjs-article-starter/
├── src/
│   └── components/   // Component source files
└── tests/
    └── components/   // ✅ All test files go here (Isolated from build)

You now have a fully configured, production-ready unit testing environment for SitecoreAI Content SDK Next.js applications. This setup delivers a solid foundation for comprehensive testing, enabling faster development cycles, improved code stability, seamless CI/CD integration, and enhanced developer experience - ensuring high-quality, scalable Sitecore implementations.

Enjoyed this guide? Give it a ⭐ and show your support!

This guide describes a hybrid caching plan for Sitecore XM Cloud apps on Vercel, using various caching layers to enhance performance in different environments. In this article, I will explain the caching details using sample components that call external APIs to fetch necessary information and use Vercel’s edge network for quick content delivery. Advanced caching methods, such as response headers, ETag checks, and Vercel edge functions, are crucial for speed, scalability, and smooth content delivery in a Next.js or headless Sitecore setup. Effective caching reduces API calls to XM Cloud’s GraphQL endpoint, decreases server load, and improves Core Web Vitals, which boosts SEO rankings.

Key Features:

• Multi-Layer Caching: Edge, HTTP, and In-Memory strategies
• Environment-Aware: Different behaviors for development vs production
• Performance Monitoring: Different behaviors for development vs production
• Error Handling: Graceful fallbacks and resilience
• SEO Optimization: Proper cache headers for search engines

📢 Read the full SitecoreAI Performance guide here

The Sitecore Content SDK for XM Cloud is a transformative tool for front-end development. This modern SDK simplifies the complexities of the JSS Next.js SDK, enhancing performance and developer efficiency. It offers seamless integration with XM Cloud’s headless architecture, featuring built-in GraphQL utilities, real-time visual editing, and support for multi-site, personalization, and analytics. Learn how to migrate your existing JSS app to the Content SDK and connect it to a local XM Cloud setup using Docker, optimizing your development process with a streamlined Next.js template.

In this guide, we’ll explore:

• What the Content SDK is
• Key benefits over JSS
• How to migrate from JSS
• Connecting to a local XM Cloud Docker setup

📢 Checkout essential checklist for migrating Sitecore JSS projects to the Content SDK here

Deploying ASP.NET MVC applications, especially Sitecore-based projects, can be tricky due to dependency conflicts, unwanted assemblies, and missing updates. Traditional deployment methods often lead to bloated packages, version conflicts, and manual steps that slow down delivery.

The .wpp.targets file is a powerful MSBuild tool that can turn the Web Publishing Pipeline (WPP) into a precise deployment tool. This guide shows how development teams use .wpp.targets files to make deployments smooth and efficient.

📢 For a deep dive into deployment optimization with .wpp.targets check out our full tutorial here