Benchmark Hyperframes render speed and output file size across configurable runs to compare performance and storage tradeoffs in kinocut projects.
Benchmark Hyperframes render speed and file size.
| Name | Required | Description | Default |
|---|---|---|---|
| runs | No | ||
| overwrite | No | Explicitly allow replacing existing media. Existing non-media files are protected. | |
| json_output | No | ||
| output_path | No | ||
| project_path | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.16.4Input schema / properties / overwriteAdded value: +{
+ "default": false,
+ "description": "Explicitly allow replacing existing media. Existing non-media files are protected.",
+ "title": "Overwrite",
+ "type": "boolean"
+}v1.16.0Input schema / additionalPropertiesAdded value: +falsev1.5.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does not meet it: it doesn't say whether benchmarking performs real renders (costly/slow), whether it writes media to disk, or that output_path/overwrite govern file creation. Only the schema hints at file output via the overwrite parameter.
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?
A single front-loaded sentence with no filler. It is efficient, though its brevity is partly the cause of the missing guidance noted elsewhere.
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?
For a 5-parameter tool with no annotations and thin schema coverage, the description omits what a benchmark run entails, what the runs default means, and how output is produced. The output schema covers return values, but the invocation-side context remains thin.
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 only 20% (just overwrite), and the description adds no meaning for runs, output_path, json_output, or project_path. With four of five parameters undocumented, the description fails to compensate for the coverage gap.
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?
States a specific verb (benchmark) and resource (Hyperframes render) plus the measured dimensions (speed and file size), so the purpose is unmistakable. It does not, however, distinguish itself from close siblings like hyperframes_render or video_benchmark_run.
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?
There is no guidance on when to run a benchmark versus a normal render, what prerequisites exist (e.g., a valid project or built composition), or how it relates to hyperframes_render / video_benchmark_run. The agent must infer usage entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.