Skip to main content
Glama
Antonytm

mcp-sitecore-server

by Antonytm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

authoring-introspect-schema

Read-only

Explore the Sitecore Authoring and Management GraphQL schema to find operations, types, arguments, and SDL for writing queries and mutations. Search by keyword or inspect one type.

Instructions

Explores the Sitecore Authoring and Management GraphQL schema (items, templates, media, sites, search, publishing, jobs, indexing, workflow, security, identity). With no arguments it returns the operation index: 127 queries and mutations, one line each. Use type: "" for one operation or type in full — for an operation the input types its arguments need are included, so one call is enough to write the document — search: "" to find an operation by what it does, and full: true for the entire SDL (117,188 characters on a live CM). Most of this schema has no typed authoring-* tool, so this is how you find the rest: createUser, createSite, executeWorkflowCommand, addLanguage, archiveItem, cancelPublishing and around a hundred more. Not the Edge schema — that is introspection-graphql-*.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fullNoWhen true, return the entire schema SDL. Very large — see the tool description for the measured size — so prefer 'type' or 'search'. Combine with includeDescriptions:false to cut it substantially.
typeNoReturn the full definition of one named type, or of one root operation (e.g. 'ArticlePage', 'createUser'). For an operation, the input and enum types its arguments reference are included too, so the result is enough to write the document. This is the argument to reach for once the index has told you the name.
searchNoFind types and operations whose name or description matches this keyword (e.g. 'media', 'workflow', 'publish'). Returns names and one-line summaries, not full definitions.
includeDescriptionsNoWhen false, strip all docstrings from the output. Defaults to true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.5

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true; the description goes well beyond that, disclosing the return shape (127 queries/mutations, one line each), a measured size for full: true (117,188 characters on a live CM), that type expands to include referenced input/enum types so one call suffices, and that search returns names/summaries rather than definitions. This is exactly the extra operational context annotations cannot carry.

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

Conciseness4/5

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

Front-loaded with the tool's scope and mode-selection guidance, and every sentence carries usable information (sizes, examples, sibling disambiguation). It is dense and long, with example operation names clustered in one sentence, but nothing is wasted.

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

Completeness5/5

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

For an introspection tool with no output schema, the description fully characterizes return values (index lines, search summaries, full SDL with measured size) and the expansion behavior of type. An agent has everything needed to choose a mode and interpret results.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real operational meaning: it explains the interaction between full and includeDescriptions ('combine with includeDescriptions:false to cut it substantially'), what type actually returns for an operation, and why search results are lightweight. It reinforces rather than merely repeats the schema.

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?

States a specific verb (explores) and resource (the Sitecore Authoring and Management GraphQL schema), enumerates the domains it covers (items, templates, media, sites, search, publishing, jobs, indexing, workflow, security, identity), and explicitly rules out the Edge schema by naming the introspection-graphql-* sibling. An agent can distinguish this from all other introspection/query tools without opening a schema.

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

Usage Guidelines5/5

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

Gives concrete when-to-use guidance per mode: no arguments for the operation index, type for one operation, search for keyword lookup, full for the whole SDL. It also states the broader purpose ('Most of this schema has no typed authoring-* tool, so this is how you find the rest') and names the alternative to avoid ('Not the Edge schema — that is introspection-graphql-*').

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

Deploy Server

Other Tools