Retrieves detailed metadata for a clip by path, name, or GUID in a Hiero/Nuke Studio project, including media path, resolution, timecode, versions, tags, and media metadata.
Clip details: media path, resolution, timecode, versions, tags and media metadata.
`clip` is a bin path ("Footage/A001"), a clip name or a GUID.
| Name | Required | Description | Default |
|---|---|---|---|
| clip | Yes | ||
| project | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, closed-world operation, so the safety profile is covered. The description adds that it returns media metadata and related clip details, but it does not disclose lookup failure behavior, project scoping, or other operational context beyond what annotations and the output schema already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the returned clip details, then adds the key identifier forms for `clip`. It is efficient, though the parameter note is slightly disconnected and the `project` parameter is omitted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema plus read-only annotations, so much of the burden is handled structurally. However, the description leaves the optional `project` parameter unexplained and gives no usage routing against siblings, leaving a meaningful gap for an agent choosing and calling the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It usefully defines `clip` as a bin path, clip name, or GUID, but the optional `project` parameter is completely undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource and the specific details retrieved (media path, resolution, timecode, versions, tags, media metadata), so an agent can tell this is a clip-inspection tool. It does not explicitly distinguish it from related sibling tools such as get_track_item or get_selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no when-to-use guidance or alternatives. It explains what forms the `clip` argument may take, but not when an agent should call get_clip versus inspecting a selection, track item, or sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.