ChatCut

track_progress

Read-onlyIdempotent

Manage long-running work in the editor.

Use this when a step has already been started and you now need its current status, progress, completion, or submission params recorded with the job.
target=generation (default): track job-backed tasks such as image/video/music/TTS generation by job ID. Supports action=status, wait, params.
If generation succeeds at the provider but asset finalization fails, the terminal entry includes an expiring recoveryUrl. Download it immediately and import the local file instead of resubmitting and spending credits again.
target=transcription: track transcript readiness on an asset by asset ID. Supports action=status, wait.
target=upload: report cloud-copy readiness and, when an open web editor is available, its current upload pipeline state. This status check never starts uploads. Tools needing remote bytes start the upload themselves and fail with its expected time and the next step to take; follow that instead of polling here. A local-only asset has no active upload in the reporting editor; invoke the operation requiring remote bytes to start one. Relink only if its local source is missing. Do not wait preemptively for metadata-only edits or local browser inspection/export.
Use track_export for submitted video/audio/cloud render jobs and export history status.
Every call returns immediately after one status read. action=wait is a compatibility alias that also returns immediately and includes check-back guidance for non-terminal work.
Non-terminal results include checkBackAfterSeconds. When the current task depends on completion, use your environment's sleep command (for example, Bash sleep 30) for at least that interval, then call action=status once. Allow at most one sleep-and-recheck cycle per turn; if it is still non-terminal, tell the user and stop. Never busy-poll. If the current task is not blocked, tell the user it is still running and stop immediately.

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_progress"
  }
}

Input Schema

Name	Required	Description
`action`	Yes	status, wait, or params
`jobIds`	No	Job IDs or prefix IDs, comma-separated, for target=generation
`target`	No	Which async task kind to inspect: generation, transcription, upload
`assetIds`	No	Asset IDs or prefix IDs, comma-separated, for target=transcription or upload
`projectId`	No	Full project UUID. Required for external browser work; internal agents may omit. Execution/explicit-timeline calls never change later calls' target.
`timelineId`	No	Full timeline UUID, not a prefix. Required for browser work, even unplaced assets. Get it from read_project or manage_timelines action="list". Never switches visible timeline.
`idempotencyKey`	No	Stable key for this browser execution. Reuse only with identical scope and parameters after a lost acknowledgement; applies only to this call.
`browserProfileId`	No	Optional browser profile override. Omit to select automatically; do not ask the user to choose.

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

Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses that every call returns immediately, that action=wait is a compatibility alias that also returns immediately, and that non-terminal results carry checkBackAfterSeconds. It also surfaces a non-obvious failure mode: an expiring recoveryUrl after provider success but finalization failure, with instructions to download and import rather than resubmit (credit protection). This is exactly the context annotations cannot carry.

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-loaded with the core action and organized into scannable target-specific bullets, which is the right shape for nine behaviors. It is still long, and the target=upload bullet packs several distinct rules into one dense paragraph; the closing polling paragraph partially restates the earlier "returns immediately" point.

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?

Covers all three target modes, the parameter sets each expects, the polling policy, and the recovery path for failed finalization. With no output schema, the description correctly explains the return-relevant fields (checkBackAfterSeconds, recoveryUrl) itself. Nothing an agent needs to call this correctly appears to be 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 schema already explains most parameters and the baseline is 3. The description adds real value on top: target=generation is declared the default (not stated in the schema), which action values are valid per target (status/wait/params for generation, status/wait for transcription), and the fact that wait does not actually block. Slight overlap with schema descriptions keeps it from 5.

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?

The opening line ("Manage long-running work in the editor") is broad, but the bullets immediately pin it down: it reads status/progress/completion for job-backed generation, transcription and upload targets. It also explicitly routes render/export jobs to track_export, so an agent can separate it from the nearest sibling. Only the generic headline keeps it from 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 Guidelines5/5

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

States the triggering condition precisely ("when a step has already been started and you now need its current status"), names the alternative tool (track_export) for render/export jobs, and gives explicit exclusions: "Do not wait preemptively for metadata-only edits or local browser inspection/export" and "This status check never starts uploads." It even prescribes the polling etiquette (one sleep-and-recheck cycle per turn, never busy-poll).

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.