Skip to main content
Glama
KyaniteLabs

kinocut

by KyaniteLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

video_workflow_inspect

Inspect workflow receipts and dry-run plans to report status, failures, hash integrity, outputs, warnings, and optional diffs in a read-only check.

Instructions

Summarize any receipt this project emits, with a read-only integrity check.

Reads a workflow render receipt, a dry-run workflow_plan artifact, or a layer_plan receipt (v1 legacy with NO receipt_kind field, or v2) at receipt_path and returns a NORMALIZED inspection: the kind (inferred from the tool field when receipt_kind is absent, per legacy tolerance), schema_version, tool, versions, a status summary (per-step statuses, failed step + error if any), a hash presence/integrity report (which recorded source/output hashes still match the bytes on disk NOW — a read-only re-check), outputs, warnings, cleanup state, plus human-review pointers and known limitations.

Nothing is rendered or modified. A malformed/unreadable receipt fails closed with invalid_workflow_receipt.

Args: receipt_path: Absolute path to the receipt JSON file to inspect. compare_path: Optional second receipt; when set, also return a diff (N3).

Input Schema

NameRequiredDescriptionDefault
overwriteNoExplicitly allow replacing existing media. Existing non-media files are protected.
compare_pathNo
receipt_pathYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.16.4
    • addedInput schema / properties / overwrite
      Added value: +{
+  "default": false,
+  "description": "Explicitly allow replacing existing media. Existing non-media files are protected.",
+  "title": "Overwrite",
+  "type": "boolean"
+}
  2. Changed2 schema fields changedv1.16.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / compare_path
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Compare Path"
+}
  3. Addedv1.6.0

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it declares the operation strictly read-only ('Nothing is rendered or modified'), specifies the fail-closed error surface (invalid_workflow_receipt on malformed/unreadable input), and explains that hash verification is a live re-check of recorded hashes against bytes currently on disk. It also discloses the legacy kind-inference behavior and the shape of the returned normalized report.

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?

Front-loads a one-line summary, then a detail paragraph, then an Args block — a sensible order. It is verbose in places (reST backticks, the unexplained '(N3)' tag) but nearly every clause conveys a real behavioral fact.

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

Completeness4/5

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

An output schema exists, so return-value explanation is optional, yet the description valuably previews the normalized report fields (kind, schema_version, per-step statuses, hash integrity, warnings, cleanup state). What's missing is any statement about the orphaned overwrite parameter and any routing to the alternative validate/rescue-inspect tools.

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 33%; receipt_path and compare_path have no schema descriptions, and the description compensates well for those two (absolute path to the receipt JSON; optional second receipt producing a diff). However, the third parameter, overwrite, is never mentioned in the description, and its 'allow replacing existing media' semantics sit oddly on a tool declared read-only, leaving an unresolved ambiguity.

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?

States a specific verb and resource — read and summarize a workflow render receipt / dry-run workflow_plan artifact / layer_plan receipt — and enumerates the accepted receipt variants (v1 legacy lacking receipt_kind, v2). It also states what it does not do ('Nothing is rendered or modified'), implicitly separating it from the render/plan siblings. It never names a specific sibling (e.g. video_workflow_validate or video_rescue_inspect) to disambiguate, so it stops short of a 5.

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

Usage Guidelines4/5

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

Gives clear context for use: point it at a receipt_path to get a normalized inspection, optionally with compare_path for a diff (N3). It explains the legacy tolerance (kind inferred from the tool field when receipt_kind is absent), which tells the agent this is safe on older artifacts. It does not say when to prefer video_workflow_validate, hyperframes_inspect, or video_rescue_inspect instead.

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