Skip to main content
Glama

Get Project Panel Metadata

get_project_panel_metadata
Read-onlyIdempotent

Retrieve the current Project-panel column layout as XML to review schema configuration before setting panel metadata; verify truncation before reuse.

Instructions

Get the current Project-panel column layout as XML. This is schema/layout configuration, not per-item Scene/Shot/Take values; use inspect_project_panel_metadata_uxp item_columns or get_metadata for those. Output is capped by max_chars (default 20000); when truncated is true the XML is incomplete and must not be passed to set_project_panel_metadata.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_project_panel_metadata"
  }
}

Input Schema

NameRequiredDescriptionDefault
max_charsNoMaximum characters of metadata XML to return (256-200000, default 20000). Longer XML is cut at this length and reported with truncated: true and totalChars.
expected_cep_targetNoOptional reviewed CEP sequence/clip identity and exact tick ranges. Checked before every generated command; UXP refuses this CEP-only guard.
expected_project_pathNoOptional absolute saved-project path. Every generated CEP command refuses before its body when the active project differs or is unsaved. UXP commands refuse this CEP-only guard; local-only tools do not inspect Premiere. Omit to keep existing behavior.

Output Schema

NameRequiredDescriptionDefault
okYesWhether the tool completed successfully.
dataNoTool-specific result data when ok is true; on failure, diagnostic detail when the tool provides it.
toolYesThe registered MCP tool name.
errorNoFailure detail when ok is false.
receiptNoVersioned common mutation receipt; success never implies rendered verification.
idempotencyNoPresent when idempotency_key deduplicated this call: replayed is true when the original outcome was returned instead of running again.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.30.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare a safe read, so the description's real contribution is the output-capping behavior and the truncated-flag hazard, which are genuinely new. It does not mention the CEP-vs-UXP guard behavior of expected_cep_target in prose, but the schema carries that fully, so the gap is minor.

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?

Three sentences, front-loaded with the scope statement, then the disambiguation, then the truncation caveat. No filler and no repetition of the deeply documented expected_cep_target/expected_project_path parameters.

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?

With an output schema present, return values needn't be explained; what remains — what this returns, what it isn't, what truncation means, and where truncated XML must not go — is all covered for a read-only getter with three optional params.

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 baseline is 3; the description adds meaning by tying max_chars to a truncated:true state and to a forbidden downstream use, which the schema alone doesn't express. The default value itself is a restatement of the schema.

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: returning the Project-panel column layout as XML. It immediately disambiguates from the nearest confusion (per-item Scene/Shot/Take metadata) and names the siblings that serve that other need.

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?

Explicitly says when NOT to use this tool ('not per-item Scene/Shot/Take values') and redirects to inspect_project_panel_metadata_uxp item_columns or get_metadata. It also gives a hard downstream rule: truncated output must not be passed to set_project_panel_metadata.

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