Skip to main content
Glama
leancoderkavy

Premiere Pro MCP Server

by leancoderkavy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Set Metadata

set_metadata

Replace a Premiere Pro project item's metadata by submitting a complete metadata XML and verifying the exact readback. Partial field updates are rejected, so provide the full XML with modified fields.

Instructions

Replace project metadata XML on a project item and verify the exact readback. Partial field/value writes are intentionally rejected because Premiere requires a complete Project Metadata XML payload.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueNoLegacy partial-write argument. It is no longer executed; read projectMetadata first, update the complete XML, then supply metadata_xml and updated_fields.
item_idYesNode ID or name of the project item
field_nameNoLegacy 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.
metadata_xmlNoComplete Project Metadata XML previously read from get_metadata, with the intended field values applied.
updated_fieldsNoExact Project Metadata field paths changed in metadata_xml (for example, Column.Intrinsic.Description).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYesWhether the tool completed successfully.
dataNoTool-specific result data when ok is true.
toolYesThe registered MCP tool name.
errorNoFailure detail when ok is false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.14.9
    • addedInput schema / properties / updated_fields / minItems
      Added value: +1
  2. Changed7 schema fields changedv1.14.4
    • 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"
+}
  3. Changed1 schema field changedv1.4.0
    • removedInput schema / additionalProperties
      Removed value: -false
  4. First observedv1.1.1

TDQS

A4.3/5.0
Behavior4/5

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

Annotations only indicate that the tool is not read-only, not idempotent, and not destructive-flagged; the description adds that partial writes are intentionally rejected, that a complete payload is mandatory, and that readback is verified. This is useful behavioral context beyond the annotations, though it doesn't cover failure handling.

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?

The description is a single, front-loaded sentence with no filler. The essential operation and the key constraint (complete XML payload, no partial writes) are stated immediately and efficiently.

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?

Between the description and the fully described input schema, the agent has the operation, the required workflow shape, the legacy arguments to avoid, and the updated_fields semantics. An output schema is present, so return-value details are not the description's burden.

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 percent, so the schema already documents every parameter, including the legacy no-execute behavior of value and field_name. The main description reinforces the complete-XML requirement but adds little parameter meaning beyond what the schema provides.

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?

The description opens with a specific verb and resource: replace project metadata XML on a project item. It also states the verification behavior and explicitly rejects partial writes, which differentiates it from read tools like get_metadata and other metadata setters like set_xmp_metadata.

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?

The description gives clear context that complete XML payloads are required and partial field/value writes are rejected. It stops short of naming sibling alternatives or an explicit read-modify-write workflow, though the schema fills in the read-projectMetadata-first step.

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