Skip to main content
Glama
Antonytm

mcp-sitecore-server

by Antonytm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

authoring-upload-media

Destructive

Uploads a file to the Sitecore media library via the Authoring and Management API, fetches a pre-signed URL, posts the bytes, and returns the created media item.

Instructions

Uploads a file into the Sitecore media library over the Authoring and Management API and returns the created media item. Does both halves of the documented flow: asks uploadMedia for a pre-signed URL, then POSTs the bytes to it. Source is exactly one of sourceUrl (fetched by this server — use this to import from a live site), filePath (local to the machine running this MCP server), or content (base64). Needs no SPE Remoting, unlike media-upload.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
altNoAlt text for the media item.
contentNoThe file bytes as base64. Small files only — prefer sourceUrl or filePath for anything sizable. Supply this, sourceUrl or filePath.
databaseNoThe database holding the media library. Defaults to master.
fileNameNoThe file name to upload as, including its extension. Defaults to the name from filePath or sourceUrl. Sitecore reads the extension to decide the media type, so set this when the source has none.
filePathNoPath to a file on the machine running this MCP server. Refused over the HTTP transport unless MEDIA_LOCAL_FILE_ROOT names a directory to confine it to. Supply this, sourceUrl or content.
itemPathYesWhere the item goes, relative to the media library and WITHOUT the '/sitecore/media library/' prefix — e.g. 'Project/MySite/hero'. The last segment is the item's name and must NOT carry a file extension: 'hero', not 'hero.png'. The extension comes from fileName (or the source), and Sitecore reads it to pick the media type — so a '.png' source becomes an Image item with an Alt field, while a '.txt' one becomes a File item that has no Alt.
languageNoThe language of the media item.
sourceUrlNohttp(s) URL to fetch the bytes from. Supply this, filePath or content.
versionedNoWhen true, create the media item as versioned rather than shared.
overwriteExistingNoWhen true, replace the file on an existing item at itemPath instead of failing.
includeExtensionInItemNameNoWhen true, keep the file extension in the item's name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.5

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true/openWorldHint=true, so the description earns credit by adding non-obvious mechanics: the two-step pre-signed-URL-then-POST flow, the HTTP-transport refusal of filePath unless MEDIA_LOCAL_FILE_ROOT confines it, and the returned media item. It stops short of describing overwrite failure/rollback semantics, which matter for a destructive tool.

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 core action and flow, then alternatives and the sibling distinction. Four sentences are dense but each carries information; no filler.

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 an 11-parameter destructive mutation with no output schema, the description covers the mechanism, the source-selection decision, the return value, and the sibling alternative. The main gap is auth/permission prerequisites and what happens on partial failure, but overall it is complete enough to invoke 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 schema already documents all 11 parameters thoroughly, including the itemPath extension rule and the source/exclusivity constraint. The description's 'exactly one of sourceUrl, filePath, or content' mirrors what the schema already says, adding reinforcement rather than new meaning — baseline 3 is appropriate.

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 ('Uploads a file into the Sitecore media library over the Authoring and Management API') and names the sibling it differs from ('Needs no SPE Remoting, unlike media-upload'). An agent can distinguish it from media-upload and authoring-create-item without opening either 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?

Gives explicit selection guidance for the three source modes ('use this to import from a live site' for sourceUrl; filePath is local to the MCP server machine; content is base64 for small files) and routes away from media-upload. It does not explicitly state when not to use the tool, so it falls short of a full 5.

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