Skip to main content
Glama
Antonytm

mcp-sitecore-server

by Antonytm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

authoring-publish-item

Queues asynchronous publishing of Sitecore items by IDs or paths, returning an operationId to poll for live status.

Instructions

Queues a publish of one or more items over the Authoring and Management API and returns an operationId. Publishing is asynchronous — the call returns as soon as the job is queued, so poll authoring-publishing-status with the operationId before reporting that content is live. On SitecoreAI the target is 'experienceedge'; on XM/XP it is usually 'web'. Supply exactly one of rootItemIds or rootItemPaths.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
languagesYesThe languages to publish, e.g. ['en']. Required.
displayNameNoA label for this publish, shown in Sitecore's publishing UI and job list.
rootItemIdsNoGUIDs of the items to publish from. Supply this or rootItemPaths.
rootItemPathsNoPaths of the items to publish from, e.g. ['/sitecore/content/Home']. Supply this or rootItemIds.
sourceDatabaseNoThe database to publish from. Defaults to master.
publishItemModeNoSMART publishes only what changed; FULL republishes everything under the root regardless. SMART is the default and is what you normally want.SMART
publishSubItemsNoWhen true, publish the descendants of each root item too. Off by default, so a bare call publishes one item.
targetDatabasesYesThe publishing targets, e.g. ['experienceedge'] on SitecoreAI or ['web'] on XM/XP. Required. This is the target's *database* name, not the publishing target item's name: on SitecoreAI the item is 'Edge' but the database is 'experienceedge', and 'Edge' is rejected. Read the right values from the 'Target database' field of /sitecore/system/Publishing targets.
publishRelatedItemsNoWhen true, also publish items the content references, such as media and linked datasources. Off by default — a page can go live with unpublished images without this.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.5

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description goes much further by disclosing that the operation is asynchronous, returns as soon as the job is queued, and requires polling to know when content is actually live. That's exactly the behavioral context an agent needs and cannot get from structured fields.

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?

Three tight sentences, each earning its place: the action, the async caveat with the follow-up tool named, and the platform-specific target plus the one-of constraint. Front-loaded with the core behavior.

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 a 9-parameter mutation tool with no output schema, the description covers the gaps that matter: return value (operationId), async semantics, the follow-up call, platform-specific target values, and the root-item mutual exclusion. Nothing essential to correct invocation is missing.

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 baseline is 3, but the description adds non-obvious semantics: the mutual exclusion of rootItemIds vs rootItemPaths, and the trap that targetDatabases takes the database name ('experienceedge') not the publishing target item name ('Edge', which is rejected). Those details materially reduce invocation errors.

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 ('Queues a publish'), resource ('one or more items'), and channel ('Authoring and Management API'), plus the return value (operationId). This clearly separates it from siblings like common-publish-item or authoring-publishing-status.

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?

Gives explicit operational guidance: poll authoring-publishing-status with the operationId before reporting content is live, and supply exactly one of rootItemIds/rootItemPaths. It also names the correct target per platform. It does not, however, contrast itself against the sibling common-publish-item, so an agent still has to infer which publish tool to choose.

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