ChatCut

track_export

Read-onlyIdempotent

Inspect this project's browser exports and legacy cloud jobs. Relay returned status and original errorDetail, not guesses.

Recover a lost submit_export response with idempotencyKey plus the original full projectId and timelineId. This reads the accepted browser job without creating or retrying work. Do not combine idempotencyKey with renderIds, latest, or onlyActive. Missing keys fail explicitly; recovery never falls back to cloud or legacy browser handlers.

source="browser": app-owned status. Status remains readable after navigation or disconnection; interruption is reported honestly. When a media export completes, that browser starts downloading it to the user's device as expectedFilename; there is no cloud downloadUrl. Follow deliveryGuidance. An export submitted with delivery="host" is uploaded instead: its delivery object gives status and, when ready, downloadUrl; follow hostDeliveryGuidance. Relay warnings and their effects. source="cloud": a durable legacy render job. Never switch a browser export to cloud to obtain a URL. Deliver completed downloadUrl through the host's normal download flow.

action=status and action=wait each make one read. If nonterminal, wait at least 10 seconds before another call. Pass returned renderIds when available. Otherwise latest defaults to true; latest=false lists recent exports, and onlyActive=true filters active work.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "track_export"
  }
}

Input Schema

Name	Required	Description
`action`	Yes	status or wait
`latest`	No	When true, read the most recently started export of this project. Defaults to true when renderIds is omitted.
`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.
`renderIds`	No	Comma-separated render IDs or prefixes returned by submit_export.
`onlyActive`	No	Return only exports that are still rendering. Use false/omit to include recently completed or failed exports.
`timelineId`	No	Optional timeline ID or prefix to narrow latest lookup.
`idempotencyKey`	No	Original submit_export key to recover a lost response. Requires full projectId/timelineId; excludes renderIds/latest/onlyActive.

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.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds real substance: status survives navigation or disconnection, a browser export downloads directly to the user's device with no cloud downloadUrl, host delivery instead yields a delivery object with downloadUrl, and recovery never falls back to other handlers. What is missing is any sense of how long a wait call takes or what a wait returns versus status, given both "each make one read".

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, but the body is dense with jargon and contains incomplete fragments such as "Relay warnings and their effects." and "source=\"browser\": app-owned status." Several sentences (deliveryGuidance, hostDeliveryGuidance) reference undisclosed artifacts, which costs the reader parsing effort in an otherwise over-long description.

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?

With no output schema, the description does the work of explaining return surfaces (expectedFilename, delivery object, downloadUrl, errorDetail) and the two sources, which is substantial for a 7-parameter read tool. The gap is operational: the status-vs-wait distinction and polling cadence are stated, but what actually differs between the two actions remains ambiguous.

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, but the description contributes cross-parameter meaning: the idempotencyKey exclusivity set, the requirement for full projectId/timelineId during recovery, and the latest/onlyActive interaction. It stops short of clarifying the concrete difference between action=status and action=wait despite making that distinction central.

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 first sentence gives a specific verb ("Inspect") and resource ("this project's browser exports and legacy cloud jobs"), and the second sentence carves out the distinct idempotency-key recovery case. Together with the source= semantics, an agent can separate this from submit_export (which creates work) 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?

Explicit when-to-use and when-not-to: "Do not combine idempotencyKey with renderIds, latest, or onlyActive", "Never switch a browser export to cloud to obtain a URL", "If nonterminal, wait at least 10 seconds before another call". It also routes between renderIds and latest fallback and names the failure mode for missing keys.

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.