Skip to main content
Glama
Antonytm

mcp-sitecore-server

by Antonytm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

authoring-search

Read-only

Search the Sitecore authoring index by criteria (MUST/SHOULD/NOT) to return matching items by field, template, or path; read entire subtrees in one query.

Instructions

Searches a Sitecore index over the Authoring and Management API and returns matching items. Criteria combine on the operator you give each one: MUST is AND, SHOULD is OR, NOT excludes. Useful system fields: '_name', '_fullpath' (the item path), '_path' (matches items under an ancestor, given that ancestor's ID with no braces or dashes), '_template' and '_templatename'. IDs in index values are lowercase and unpunctuated, e.g. '110d559fdea542ea9c1c8a5df7e70ef9'. Returns 10 results unless pageSize says otherwise. A '_path' criterion is the cheap way to read a whole subtree at any depth — one query where item-service-get-item-descendants makes one request per node — at the cost of returning identity fields rather than field values, from the index rather than the database.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
indexNoThe index to search. Defaults to sitecore_master_index (the authoring content).sitecore_master_index
criteriaYesThe criteria to match. At least one.
languageNoRestrict results to this language, e.g. 'en'.
pageSizeNoResults per page. The endpoint's own default is 10.
pageIndexNoZero-based page to return. Use with pageSize to walk a large result set.
sortFieldNoField to sort by, e.g. '__smallcreateddate'. Omit for relevance order.
sortDirectionNoSort direction. Only meaningful with sortField.
latestVersionOnlyNoWhen true, return only the latest version of each item instead of every indexed version.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.5

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, so the description carries the rest and does so well: default index, default 10-result page size, pagination via pageSize/pageIndex, relevance vs sortField ordering, and the important caveat that index values are lowercase unpunctuated IDs and that _path results return identity fields rather than field values. This is real behavioral context beyond the safety hint.

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?

Purpose is front-loaded in the first clause, and each subsequent sentence adds distinct operational value (operator semantics, useful fields, ID format, page size, subtree tradeoff). Dense but no filler or restatement of the 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?

With no output schema, the description must carry return-value context; it does so at a high level (matching items, 10 results by default, identity fields vs field values) but never describes the result shape or total-count/paging metadata. For a search tool with eight parameters this is close to complete, with a minor remaining gap.

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 meaning the schema lacks: the usable system fields ('_name', '_fullpath', '_path', '_template', '_templatename'), the brace/dash-free ancestor-ID syntax for '_path', and the exact ID format example. It does not explain criteriaType behavior or boost in prose, leaving some schema-documented semantics untouched.

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 and resource ('Searches a Sitecore index over the Authoring and Management API and returns matching items') and immediately distinguishes itself from nearby tools by describing criteria semantics and index-backed behavior. An agent can tell it apart from item-service-search-items and item-service-get-item-descendants without opening any schema.

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

Usage Guidelines4/5

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

Explicitly routes one case: use a '_path' criterion to read a whole subtree in one query, versus item-service-get-item-descendants which makes one request per node, and it names the tradeoff (identity fields, index not database). It does not cover when to prefer the other search siblings (item-service-search-items, indexing-find-item) or any when-not conditions, so it falls short of full routing guidance.

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