Sitecore Community MCP

authoring-update-item-template

Update a Sitecore data template via the Authoring API: modify existing sections and fields by ID, add new ones, or delete omitted ones when deleteMissingFields is true.

Instructions

Updates a Sitecore data template over the Authoring and Management API. Sections and fields carrying an ID are updated; those without one are created. Matching is by ID only, never by name: to add a field to a section that already exists you must pass that section's templateSectionId (read it as itemTemplateSectionId from authoring-get-item-template), otherwise the call is rejected for creating a second section of the same name. Nothing is removed unless deleteMissingFields is true — and when it is, every section and field absent from this call is deleted, along with the content stored in them, so read the template first.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "templateId": "<templateId>"
    },
    "name": "authoring-update-item-template"
  }
}

Input Schema

Name	Required	Description
`icon`	No	A new icon for the template.
`name`	No	A new name for the template. Omit to leave it unchanged.
`database`	No	The database holding the template. Defaults to master.
`language`	No	The language to write template text in.
`sections`	No	Sections to update or add. Include templateSectionId / templateFieldId to update rather than create.
`templateId`	Yes	The GUID of the template to update.
`baseTemplates`	No	GUIDs of templates to inherit from. This replaces the current list rather than adding to it.
`deleteMissingFields`	No	When true, delete every section and field not named in this call, discarding their content. Off by default.
`createStandardValuesItem`	No	When true, create the __Standard Values item if the template does not have one.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.3Oct 18, 2026

TDQS

A4.8/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 well beyond them by disclosing that deleteMissingFields deletes every absent section and field plus their stored content, and that the default is off. It also explains the ID-only matching rule and the rejection behavior, which the annotations cannot convey.

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 sentences, front-loaded with the create-vs-update rule, then the ID-matching constraint, then the destructive-flag warning. Every sentence carries operational information; nothing is padding or restatement of the 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?

For a 9-parameter mutation tool with no output schema and only two thin annotations, the description covers the highest-risk behaviors (deletion, ID matching, rejection). It stops short of noting permission requirements or the effect of baseTemplates replacement, but those are minor relative to what it does cover.

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 meaning on top: it explains that templateSectionId/templateFieldId are the only match keys and are mandatory when targeting an existing section, and it warns what deleteMissingFields=true actually does. Minor gaps remain (database, language, baseTemplates) that only the schema covers.

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 ('Updates a Sitecore data template over the Authoring and Management API') and immediately distinguishes itself from siblings like authoring-create-item-template and authoring-get-item-template by explaining create-vs-update semantics. An agent can identify the tool's role without opening the 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 explicit routing instructions: read the template first via authoring-get-item-template, pass templateSectionId to add a field to an existing section, and pass templateFieldId to update rather than create. It also names the failure mode (rejection for creating a duplicate section name), which is precisely the when-not guidance an agent needs.

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

Deploy Server