Premiere Pro MCP Server

Get Metadata

get_metadata

Read-onlyIdempotent

Retrieve project or clip metadata as raw XML or parsed named fields to inspect asset details in Premiere Pro.

Instructions

Get metadata for a project item. Use parse_fields to return named XMP/project fields instead of raw XML. Project metadata XML and file/clip XMP are separate packets; disable either when identity/path is enough. Prefer inspect_project_panel_metadata_uxp item_columns or manage_metadata_uxp inspect_fields for visible columns. This is not the premiere://project/metadata resource. GPS and serials are omitted from parse_fields unless include_sensitive is true.

Input Schema

TableJSON Schema

Name	Required	Description
`item_id`	Yes	Node ID or name of the project item
`parse_fields`	No	Parse project metadata and XMP into named fields (default false). When true, raw XML is omitted unless include_project_metadata or include_xmp_metadata is explicitly true.
`include_sensitive`	No	When parse_fields is true, include GPS, serials, and similar EXIF. Default false.
`include_xmp_metadata`	No	Include the potentially large XMP XML payload (default: true unless parse_fields is true).
`include_project_metadata`	No	Include the potentially large Project Metadata XML payload (default: true unless parse_fields is true).

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."

Changed4 schema fields changedv1.16.3Sep 19, 2026

changedInput schema / properties / include_project_metadata / description

Previous value: -"Include the potentially large Project Metadata XML payload (default: true). Set false for a bounded identity/path response."New value: +"Include the potentially large Project Metadata XML payload (default: true unless parse_fields is true)."

addedInput schema / properties / include_sensitive

Added value: +{
+  "description": "When parse_fields is true, include GPS, serials, and similar EXIF. Default false.",
+  "type": "boolean"
+}

changedInput schema / properties / include_xmp_metadata / description

Previous value: -"Include the potentially large XMP XML payload (default: true). Set false for a bounded identity/path response."New value: +"Include the potentially large XMP XML payload (default: true unless parse_fields is true)."

addedInput schema / properties / parse_fields

Added value: +{
+  "description": "Parse project metadata and XMP into named fields (default false). When true, raw XML is omitted unless include_project_metadata or include_xmp_metadata is explicitly true.",
+  "type": "boolean"
+}

Changed4 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"

addedInput schema / properties / include_project_metadata

Added value: +{
+  "description": "Include the potentially large Project Metadata XML payload (default: true). Set false for a bounded identity/path response.",
+  "type": "boolean"
+}

addedInput schema / properties / include_xmp_metadata

Added value: +{
+  "description": "Include the potentially large XMP XML payload (default: true). Set false for a bounded identity/path response.",
+  "type": "boolean"
+}

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.6/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the safety profile is covered. The description adds meaningful behavioral context: parse_fields returns named fields instead of raw XML, XML packets can be disabled when identity/path is sufficient, GPS and serials are omitted by default unless include_sensitive is true, and this is not the premiere://project/metadata resource.

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?

The description is front-loaded, dense, and uses no filler sentences. It packs purpose, usage guidance, alternatives, and sensitive-field caveats efficiently, though the number of clauses in one paragraph requires careful reading.

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?

Given the tool's moderate complexity, rich annotations, complete schema coverage, and existing output schema, the description supplies everything an agent needs beyond structured fields: when to use it, which alternatives to prefer for related tasks, how metadata packets behave, and sensitive-data defaults.

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 five parameters, including defaults and inter-parameter behavior. The description reinforces some of that, but does not add substantial syntax or format details 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 gives a specific verb and resource: 'Get metadata for a project item.' It also distinguishes the operation from related tools and resources by noting 'This is not the premiere://project/metadata resource' and by explaining that project metadata XML and file/clip XMP are separate packets.

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?

The description explicitly states when to use parse_fields, when to disable either metadata packet, and which sibling tools to prefer for visible columns ('inspect_project_panel_metadata_uxp item_columns or manage_metadata_uxp inspect_fields'). It also clarifies the sensitive-data default behavior, leaving little inference for an agent.

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

Deploy Server