Premiere Pro MCP Server

Get Metadata

get_metadata

Read-onlyIdempotent

Retrieve metadata for any project item, returning identity, path, XMP, and project metadata. Disable XML payloads when only bounded identity/path data is needed.

Instructions

Get metadata for a project item. Disable either XML payload when a bounded identity/path response is sufficient.

Input Schema

TableJSON Schema

Name	Required	Description
`item_id`	Yes	Node ID or name of the project item
`include_xmp_metadata`	No	Include the potentially large XMP XML payload (default: true). Set false for a bounded identity/path response.
`include_project_metadata`	No	Include the potentially large Project Metadata XML payload (default: true). Set false for a bounded identity/path response.

Output Schema

TableJSON Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

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

A3.5/5.0

Behavior3/5

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

Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior, so the description carries a lighter burden. It adds useful context about potentially large XML payloads and the availability of a bounded identity/path response, but it does not disclose other behavioral details such as response size limits or error conditions.

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?

Two concise sentences with no filler. The primary purpose is front-loaded, and the second sentence provides a practical, actionable qualifier about payload control.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only metadata getter with a rich output schema and strong annotations, the description is mostly sufficient. The main gap is the lack of differentiation from overlapping sibling tools with similar metadata-focused names, which leaves some ambiguity about when exactly this tool should be selected.

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 parameter meanings and defaults are already fully documented. The description reinforces the relationship between the two boolean flags and the bounded response, but it does not add significant semantic value beyond the schema.

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?

The description clearly states the operation ('Get metadata') and resource ('a project item'), so an agent can understand the basic purpose. However, the generic 'metadata' scope overlaps with sibling tools like get_item_info, get_project_item_info, and get_xmp_metadata, and no distinctions are drawn.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers actionable guidance on when to disable the XML payloads ('when a bounded identity/path response is sufficient'), which is useful for efficient invocation. However, it does not explain when to choose this tool over nearby sibling metadata tools, so the tool-selection context is only implied.

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

Deploy Server