Which integrations are available for this server?

Provides tools for retrieving item details and listing children of items from a Sitecore XM Cloud Content Management GraphQL API.

How do I use Sitecore AI MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Sitecore AI MCP Server List the children of /sitecore/content/home" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Sitecore AI MCP Server

by KoushikMukherjeeDA

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Sitecore AI MCP Server

A Model Context Protocol (MCP) server that exposes two read tools over the SitecoreAI / XM Cloud Content Management GraphQL API:

Tool	What it does
`get_item_detail`	Fetch one item's full detail: id, name, path, template name, display name, all fields, children count
`list_items`	List an item's immediate children, optionally filtered by template

It runs over stdio, so any MCP client (Claude Desktop, Claude Code, etc.) can launch it as a local subprocess. Authentication uses the OAuth 2.0 client-credentials grant, with an in-memory token manager that caches and proactively refreshes the access token before it expires.

1. Prerequisites

Node.js 18+ (uses the built-in global fetch).
A Sitecore XM Cloud environment (or a self-hosted CM instance) whose Content Management GraphQL API is enabled.
An OAuth client (client id + secret) that is authorised to call that API.

Related MCP server: SitecoreMCP

2. Install & build

npm install
npm run build

This compiles src/** to dist/**. The executable entrypoint is dist/index.js.

3. Configure environment variables

Copy the example file and fill in the values:

cp .env.example .env

Variable	Required	Description
`SITECORE_API_URL`	✅	Content Management GraphQL endpoint, e.g. `https://<cm-host>/sitecore/api/authoring/graphql/v1`
`SITECORE_TOKEN_URL`	✅	OAuth token endpoint (identity server), e.g. `https://auth.sitecorecloud.io/oauth/token`
`SITECORE_CLIENT_ID`	✅	OAuth client id
`SITECORE_CLIENT_SECRET`	✅	OAuth client secret
`SITECORE_SCOPE`	⬜	OAuth scope, if your identity server requires one
`SITECORE_AUDIENCE`	⬜	OAuth audience, if your identity server requires one

The server never logs the client secret or the access token. Errors are surfaced with a category (auth, forbidden, not_found, invalid_template, graphql, network, config) and a short, secret-free detail string.

Access policy (deny-by-default)

Every tool call passes through a path-based policy before any field values or children are read:

Zero-network deny — the well-known Sitecore protected roots (/sitecore/system, /sitecore/templates, /sitecore/layout) have fixed, public GUIDs, so a request for one is refused with no network call at all.
Path gate — for every other id, a minimal path-only lookup runs first, the policy decides, and only then is the item's content fetched. Anything outside the allow-list is denied by default; a denial surfaces as a [forbidden] tool error.

Variable	Default	Purpose
`SITECORE_ALLOW_PATHS`	`/sitecore/content,/sitecore/media library`	Readable path prefixes. Anything not matched is denied.
`SITECORE_PROTECTED_PATHS`	`/sitecore/system,/sitecore/templates,/sitecore/layout`	Blocked outright unless developer mode is on.
`SITECORE_DEVELOPER_MODE`	`false`	When `true`/`1`/`yes`/`on`, lifts the block on the protected areas.

Why block templates/system/layout by default: an agent that can read — and especially, once write tools exist, edit — a template can take down every page built on it with one plausible-looking change. Keep SITECORE_DEVELOPER_MODE off in any environment an agent reaches unsupervised, and turn it on only for a deliberate developer session.
Because the tools are keyed by item id (an opaque GUID), the id → path mapping for non-root items requires exactly one lightweight metadata lookup; the gate then runs before any content, field values, or (future) mutation is touched.

Where to generate the OAuth client id / secret

XM Cloud (Sitecore Cloud):

Sign in to the XM Cloud Deploy / Cloud Portal.
Open Credentials (Organization settings → Automation client credentials, or the environment's Developer settings).
Create a new client with the scope/role needed to read content via the Authoring/Content GraphQL API.
Copy the generated Client ID and Client Secret into .env.
The token endpoint for Sitecore Cloud is typically https://auth.sitecorecloud.io/oauth/token — set that as SITECORE_TOKEN_URL.

Self-hosted XM / CM instance:

Register an OAuth client in your Sitecore Identity Server configuration (a ClientCredentials grant client) with a client id and secret.
Grant it the API resource/scope for the GraphQL endpoint.
Use your identity server's token endpoint (e.g. https://<cm-host>/sitecore/api/identity/token or the IdentityServer /connect/token) as SITECORE_TOKEN_URL.

The exact GraphQL schema differs slightly between endpoints. This server targets the XM Cloud Authoring & Management GraphQL API shape (item(where: { itemId, language, version }), fields { nodes { name value } }, children { nodes / totalCount }). If your endpoint uses a different schema, adjust the queries in src/tools/getItemDetail.ts and src/tools/listItems.ts.

4. Register the server in an MCP client

Claude Desktop (`claude_desktop_config.json`)

Location:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "sitecore-ai": {
      "command": "node",
      "args": ["C:\\path\\to\\SItecoreAISimpleMCP\\dist\\index.js"],
      "env": {
        "SITECORE_API_URL": "https://<cm-host>/sitecore/api/authoring/graphql/v1",
        "SITECORE_TOKEN_URL": "https://auth.sitecorecloud.io/oauth/token",
        "SITECORE_CLIENT_ID": "your-client-id",
        "SITECORE_CLIENT_SECRET": "your-client-secret"
      }
    }
  }
}

Restart Claude Desktop; the two tools appear under the 🔌 tools menu.

Claude Code

claude mcp add sitecore-ai \
  --env SITECORE_API_URL=https://<cm-host>/sitecore/api/authoring/graphql/v1 \
  --env SITECORE_TOKEN_URL=https://auth.sitecorecloud.io/oauth/token \
  --env SITECORE_CLIENT_ID=your-client-id \
  --env SITECORE_CLIENT_SECRET=your-client-secret \
  -- node C:\\path\\to\\SItecoreAISimpleMCP\\dist\\index.js

5. Usage examples

get_item_detail:

{ "itemId": "110D559F-DEA5-42EA-9C1C-8A5DF7E70EF9", "language": "en" }

list_items (optionally filtered by template):

{
  "parentId": "0DE95AE4-41AB-4D01-9EB0-67441B7C2450",
  "language": "en",
  "templateId": "76036F5E-CBCE-46D1-AF0A-4143F9B557AA"
}

GUIDs may be dashed, braced ({...}), or raw 32-hex — all forms are accepted.

6. Tests

npm test

Unit tests cover:

Token manager — grant request shape, caching, proactive refresh before expiry, concurrent-refresh coalescing, invalidate(), and 401/network/config error handling (plus a check that the secret never leaks into errors).
get_item_detail — field mapping, defaults, version passthrough, not-found handling, and input validation.
list_items — child mapping, template filtering (GUID-form-insensitive), invalid-template detection, empty children, not-found, input validation, and policy enforcement (protected parent by id/path, per-child filtering).
Access policy — allow-list matching, protected-area blocking, deny by default, sibling-prefix safety, developer-mode lifting the block, and fromEnv parsing.

Both tool suites mock the GraphQL client; the token-manager suite mocks fetch.

7. Project structure

src/
  index.ts                 # server entrypoint, registers tools over stdio
  sitecoreClient.ts        # GraphQL client wrapper (adds bearer token, 401 retry)
  itemPath.ts              # minimal id -> path lookup used by the policy gate
  policy.ts                # PathPolicy: deny-by-default allow-list + protected roots
  context.ts               # ToolContext = { client, policy }
  schemas.ts               # zod input schemas
  errors.ts                # SitecoreError + error categories
  auth/
    tokenManager.ts        # OAuth client-credentials fetch/cache/refresh
  tools/
    getItemDetail.ts       # get_item_detail implementation
    listItems.ts           # list_items implementation
tests/
  tokenManager.test.ts
  policy.test.ts
  getItemDetail.test.ts
  listItems.test.ts

License

MIT

Available Tools

2 tools

get_item_detailGet Sitecore item detailA

Fetch a single Sitecore / XM Cloud item's full details: id, name, path, template name, display name, all field names/values, and children count.

ParametersJSON Schema

Name	Required	Description	Default
`itemId`	Yes	The GUID of the Sitecore item to fetch.
`version`	No	Specific item version. Omit for the latest version.
`language`	No	Language/locale code, e.g. 'en' or 'en-US'. Defaults to 'en'.	en

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavior. It lists the return fields (id, name, path, template name, display name, field names/values, children count), giving a clear expectation of what the tool returns. It does not mention error behavior or permissions, but for a fetch operation this is likely sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the action and resource, followed by a colon and list of returned details. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple: one required parameter (itemId), with optional version and language documented in the schema. The description explains the return values thoroughly, and the sibling tool list_items covers the list scenario. The absence of an output schema is compensated by the detailed field list. Complete enough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters have descriptions in the schema (100% coverage), so baseline is 3. The description does not add additional parameter semantics beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Fetch' and clearly identifies the resource as a single Sitecore item, listing the fields returned. This distinguishes it from the sibling tool list_items, which likely retrieves multiple items.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool over list_items. However, the phrase 'single item' implies this is for fetching one item's details, while list_items presumably retrieves multiple. No exclusion or alternative is mentioned, so guidance is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_itemsList Sitecore child itemsA

List the immediate children of a Sitecore / XM Cloud item. Optionally filter by template id. Returns id, name, path, template name and display name.

ParametersJSON Schema

Name	Required	Description	Default
`language`	No	Language/locale code, e.g. 'en' or 'en-US'. Defaults to 'en'.	en
`parentId`	Yes	The GUID of the parent item whose immediate children should be listed.
`templateId`	No	Optional template GUID. When provided, only children of this template are returned.

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral disclosure. It does add useful details: lists only immediate children, supports an optional template filter, and specifies the returned fields (id, name, path, template name, display name). However, it omits other behavioral aspects such as sorting, pagination, error behavior when parentId is invalid, or language handling. It provides some transparency but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with the core purpose ('List the immediate children'). Every clause adds value: the scope ('immediate'), the optional filter, and the return fields. No fluff or redundant repetition of the title or tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the moderate complexity, full schema coverage, and absence of an output schema, the description is mostly complete. It explains the purpose, the key behavior (immediate children, optional filter), and the return fields. However, it does not mention the language parameter's role or any edge cases, and the sibling tool relationship is not addressed. Still, it provides a solid understanding for an agent to select and use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it mentions 'immediate children' and optional template filter, both of which are already captured in the parameter descriptions. It does not add new meaning about the language parameter or parameter relationships. The schema fully documents the parameters, so the description does not need to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'immediate children of a Sitecore / XM Cloud item', which is specific and distinguishes it from the sibling tool get_item_detail that retrieves a single item. It also mentions optional filtering by template ID and the returned fields, making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing immediate children, but does not explicitly state when to use this tool versus the sibling get_item_detail, nor does it give guidance on when not to use it. The optional template filter is mentioned, but no contextual triggers or exclusions are provided. The usage is clear by implication but not explicitly framed against alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesv1.0.0Jul 31, 2026
- First observedget_item_detail
- First observedlist_items

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Scored 2026-07-31 17:15 across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one fetches detailed information about a single item, while the other lists children of an item. There is no overlap or ambiguity.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern: 'get_item_detail' and 'list_items'. The naming is predictable and conventional.

Tool Count3/5

With only 2 tools, the server feels minimal but not unreasonable for a focused read-only item browsing scenario. The count is borderline per the calibration.

Completeness2/5

The tools only support reading item details and listing children. Missing write operations (create, update, delete), search, or other content management features leave significant gaps for a Sitecore server.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-serverOAuth
com.agilitycms
An MCP server that provides access to Agility CMS. See https://mcp.agilitycms.com for more details.
Content Management Systems Developer Tools
2
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
Grafbase
com.grafbase.api
The Grafbase MCP server sits in front of a GraphQL API and exposes an MCP protocol-compliant interface that allows AI agents and LLMs to explore and query GraphQL APIs using natural language. It provides tools to search schemas, introspect types and fields, and execute GraphQL queries while minimizing context bloat by returning only relevant schema subsets, with built-in support for authentication, authorization, and configurable access control.
API Testing Search Developer Tools
2
StytchOAuth
dev.stytch.mcp
The Stytch MCP server is a reference implementation that demonstrates remote MCP server authentication and authorization using Stytch Connected Apps. It provides OAuth 2.1-compliant authorization (including PKCE), Dynamic Client Registration, and validates Stytch-issued access tokens to enable AI agents to securely interact with external services through permissioned access, supporting scopes like openid, email, profile, and manage:project_data.
Security Autonomous Agents App Automation
2

Related MCP Servers

GitHub GraphQL API MCP
Search Developer Tools Version Control
wanzunz
F
license
B
quality
D
maintenance
A server that allows you to explore the GitHub GraphQL schema and execute GraphQL queries through MCP client tools, enabling efficient data retrieval from GitHub with reduced token consumption.
Updated 9 months ago (2025-12-12 10:24 UTC)
4
4
-
SitecoreMCP
App Automation Content Management Systems Developer Tools
ramseur
A
license
C
quality
D
maintenance
A SitecoreMCP version that can be used in enterprises
Updated 4 months ago (2026-05-19 14:06 UTC)
100
127
Apache 2.0
mcp-sitecore-server
Content Management Systems Security
Antonytm
A
license
Not graded
quality
A
maintenance
MCP server for Sitecore that provides tools to interact with Sitecore via GraphQL, Item Service API, and Sitecore PowerShell Extensions, enabling content and security management.
Updated 10 days ago (2026-09-01 20:01 UTC)
127
52
Apache 2.0
Sitecore XM Cloud MCP Server
Content Management Systems Cloud Platforms Developer Tools
JagadeeshMaroju
F
license
Not graded
quality
D
maintenance
AI-driven MCP server for Sitecore XM Cloud authoring, enabling template creation via GraphQL API with OAuth support for Sitecore Agentic Studio.
Updated 3 months ago (2026-06-12 02:58 UTC)
1
-

Sitecore AI MCP Server

1. Prerequisites

2. Install & build

3. Configure environment variables

Access policy (deny-by-default)

Where to generate the OAuth client id / secret

4. Register the server in an MCP client

Claude Desktop (claude_desktop_config.json)

Claude Code

5. Usage examples

6. Tests

7. Project structure

License

Available Tools

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

GitHub GraphQL API MCP

SitecoreMCP

mcp-sitecore-server

Sitecore XM Cloud MCP Server

Claude Desktop (`claude_desktop_config.json`)