ChatCut

inspect_item

Read-onlyIdempotent

Return complete readable detail for one to ten objects placed on a timeline: clips and other items, effects, and transitions. To inspect several, pass them together in itemIds in one call instead of calling inspect_item once per item.

Use ids or prefixes from preview_timeline, from edit_item results, or from an item's Attached section; an "effect-track:" tag on an effect id is accepted. Each id gets its own block, separated by ---, headed by its timeline and "Item: ". An item block includes identity, timeline and track, timeline/source ranges, asset reference, playback state, geometry, crop/fit/position/scale/rotation/opacity, fades and audio state, item-type-specific properties, Motion Graphic defaults/overrides, and attached effects/transitions when present. An effect or transition block includes its track, its timeline frame range, the clip(s) it attaches to, its asset, its editable properties with current values, and the edit_item call that changes or removes it. Ids that are not found or ambiguous do not fail the call: the others are returned and a final "Not inspected" section lists each failed id with its reason. The call fails only when no requested id can be inspected.

This reads placed instances. Use inspect_asset for the source asset and preview_timeline for surrounding timeline structure or composed pixels.

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": "inspect_item"
  }
}

Input Schema

Name	Required	Description
`id`	No	Alias for itemId; accepts the same placed object ids or prefixes.
`itemId`	No	One placed item, effect, or transition id, or an unambiguous id prefix. A comma-separated list is read as itemIds.
`itemIds`	No	Placed item, effect, or transition ids/prefixes (up to 10) to inspect in one call; they may be mixed. Combined with itemId when both are given; duplicates are ignored, and the limit counts distinct ids.
`projectId`	No	Project for this call (full ID or unambiguous prefix). Explicit-timeline calls never change the target of later calls; legacy project selection applies otherwise.
`timelineId`	No	Optional timeline id/prefix that narrows item, effect, and transition lookup without switching the active timeline.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

First observedNov 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description still adds substantial behavior: per-id output blocks separated by '---' with 'Item: <id>' headers, the exact field groups returned, the accepted 'effect-track:' id tag, and the crucial partial-failure contract that unknown or ambiguous ids go into a 'Not inspected' section rather than failing the call. That failure semantics is exactly the kind of context annotations cannot convey.

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?

Structure is strong: purpose and batching first, id sourcing second, output format third, failure behavior fourth, sibling routing last. It is on the long side — the enumerated block contents (geometry, crop/fit/position/scale/rotation/opacity, fades, Motion Graphic defaults) read as a list dump — but each element does inform what the agent will receive, so the length is mostly earned.

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?

There is no output schema, so the description must carry the return contract itself, and it does: block delimiters, header format, field groups for item blocks versus effect/transition blocks, and the partial-failure 'Not inspected' section. For a 5-parameter read tool with no output schema, nothing an agent needs in order to call it and interpret the result is missing.

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 real meaning beyond it by naming id sources (preview_timeline, edit_item, Attached section), confirming prefix matching and the 'effect-track:' tag, and reiterating the ten-id cap. It does not add much on projectId/timelineId beyond what the schema text already says, so it falls short of a 5.

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 opening sentence names a specific verb and resource — 'Return complete readable detail for one to ten objects placed on a timeline: clips and other items, effects, and transitions' — and explicitly bounds the scope to placed instances rather than source assets. The closing line distinguishes it from inspect_asset and preview_timeline, so an agent can route correctly without opening the schema.

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 states when to use it, how to batch ('pass them together in itemIds in one call instead of calling inspect_item once per item'), where valid ids come from (preview_timeline, edit_item results, an item's Attached section), and which alternatives to use for adjacent needs ('Use inspect_asset for the source asset and preview_timeline for surrounding timeline structure or composed pixels'). Exclusions and alternatives are both explicit.

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

All ChatCut tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.