Premiere Pro MCP Server

Set Metadata

set_metadata

Update a project item's metadata by writing complete XMP XML or a single named field value, with optional compare-and-set checks, to keep Premiere Pro properties accurate.

Instructions

Update project metadata on a project item. Supply complete metadata_xml plus updated_fields, or field_name and value to read-modify-write one XMP/project property through AdobeXMPScript with field readback. The project packet (default) stays in the project; packet 'xmp' is written by Premiere into the source media file on disk and requires the filesystem capability.

Input Schema

TableJSON Schema

Name	Required	Description
`value`	No	Replacement value for field_name. Maximum 4096 characters.
`packet`	No	Packet for field_name writes. Default project (Premiere-private metadata).
`item_id`	Yes	Node ID or name of the project item
`field_name`	No	Named field to update (for example Column.Intrinsic.LogNote). Used with value; cannot be combined with metadata_xml.
`metadata_xml`	No	Complete Project Metadata XML previously read from get_metadata, with the intended field values applied.
`expected_value`	No	Optional compare-and-set guard for field_name writes.
`updated_fields`	No	Exact Project Metadata field paths changed in metadata_xml (for example, Column.Intrinsic.Description).
`field_namespace`	No	XMP namespace URI or alias (premiere, dc, xmp, exif). Default premiere for project packet; required for xmp.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	Whether the tool completed successfully.
`data`	No	Tool-specific result data when ok is true; on failure, diagnostic detail when the tool provides it.
`tool`	Yes	The registered MCP tool name.
`error`	No	Failure detail when ok is false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.18.6Sep 30, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

changedOutput schema / properties / data / description

Previous value: -"Tool-specific result data when ok is true."New value: +"Tool-specific result data when ok is true; on failure, diagnostic detail when the tool provides it."

Changed5 schema fields changedv1.16.3Sep 19, 2026

addedInput schema / properties / expected_value

Added value: +{
+  "description": "Optional compare-and-set guard for field_name writes.",
+  "type": "string"
+}

changedInput schema / properties / field_name / description

Previous value: -"Legacy partial-write argument. It is no longer executed because it cannot form a valid Project Metadata XML payload; use metadata_xml and updated_fields instead."New value: +"Named field to update (for example Column.Intrinsic.LogNote). Used with value; cannot be combined with metadata_xml."

addedInput schema / properties / field_namespace

Added value: +{
+  "description": "XMP namespace URI or alias (premiere, dc, xmp, exif). Default premiere for project packet; required for xmp.",
+  "type": "string"
+}

addedInput schema / properties / packet

Added value: +{
+  "description": "Packet for field_name writes. Default project (Premiere-private metadata).",
+  "enum": [
+    "project",
+    "xmp"
+  ],
+  "type": "string"
+}

changedInput schema / properties / value / description

Previous value: -"Legacy partial-write argument. It is no longer executed; read projectMetadata first, update the complete XML, then supply metadata_xml and updated_fields."New value: +"Replacement value for field_name. Maximum 4096 characters."

Changed1 schema field changedv1.14.9Sep 8, 2026
- addedInput schema / properties / updated_fields / minItems
```
Added value: +1
```

Changed7 schema fields changedv1.14.4Aug 29, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedInput schema / properties / field_name / description

Previous value: -"Metadata field name (e.g., 'Column.Intrinsic.Description')"New value: +"Legacy partial-write argument. It is no longer executed because it cannot form a valid Project Metadata XML payload; use metadata_xml and updated_fields instead."

addedInput schema / properties / metadata_xml

Added value: +{
+  "description": "Complete Project Metadata XML previously read from get_metadata, with the intended field values applied.",
+  "type": "string"
+}

addedInput schema / properties / updated_fields

Added value: +{
+  "description": "Exact Project Metadata field paths changed in metadata_xml (for example, Column.Intrinsic.Description).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedInput schema / properties / value / description

Previous value: -"Value to set"New value: +"Legacy partial-write argument. It is no longer executed; read projectMetadata first, update the complete XML, then supply metadata_xml and updated_fields."

changedInput schema / required

Previous value: -[
-  "item_id",
-  "field_name",
-  "value"
-]New value: +[
+  "item_id"
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "data": {
+      "description": "Tool-specific result data when ok is true."
+    },
+    "error": {
+      "description": "Failure detail when ok is false.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "Whether the tool completed successfully.",
+      "type": "boolean"
+    },
+    "tool": {
+      "description": "The registered MCP tool name.",
+      "minLength": 1,
+      "type": "string"
+    }
+  },
+  "required": [
+    "ok",
+    "tool"
+  ],
+  "type": "object"
+}

Changed1 schema field changedv1.4.0Jul 27, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
First observedv1.1.1May 28, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false. The description adds real context beyond that: the xmp packet persists to the source media file on disk, requires the filesystem capability, and writes go through AdobeXMPScript with field readback. It does not explain the non-idempotent behavior, which is a minor gap.

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?

Three compact sentences, front-loaded with the primary effect before the modality and packet details. Dense but every clause 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?

An output schema exists so return values need no explanation, and annotations cover the safety profile. The description supplies the write mode, persistence target, and capability requirement, leaving only sibling disambiguation unaddressed.

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 per-parameter docs already carry the load. The description still adds relationship semantics the schema does not: which parameter groups combine (metadata_xml with updated_fields; field_name with value) and the packet-dependent default for field_namespace.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Update project metadata on a project item') and covers both project and xmp packet targets. However, it never names its near-identical siblings (set_xmp_metadata, set_project_panel_metadata, get_metadata), so an agent must infer which metadata writer to use.

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?

Explains the two mutually exclusive write modes (metadata_xml + updated_fields vs field_name + value) and gives the condition selecting packet 'xmp' (writes into source media, requires filesystem capability). It stops short of any when-not-to-use or alternative-tool guidance.

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

Deploy Server