ChatCut

browse_assets

Read-onlyIdempotent

Browse current-project asset cards: identity, duration (ms), dimensions, folder, processing/source access, transcript/generation/audio facts and match snippets. mediaPoolVisibility="hidden" hides references from the user's library, not agent access by ID; do not assume user footage or place unless requested. Generating/failed jobs come first with jobId, status and progress; use track_progress. status=generating also shows jobs completed within 10 minutes as status=completed with assetId. Every query term must match a fact. Use nextOffset with the same query/filters; searchCoverage distinguishes no matches from unsearched transcripts. Pass transcriptRangesMs to inspect_asset; use inspect_asset for pixels. status is processing, not source access. transcript.readyForEditing=true enables transcript/Script/caption work despite processing/cloud-unavailable; pending upload is no reason to claim still transcribing, retry, remove or skip. sourceAccess.cloud concerns only operations needing cloud bytes; sourceAccess.desktopRegistered records an import, not current local availability. sourceAccess.originalUpload=deferred is intentionally skipped: do not poll. Metadata does not prove local bytes exist; a connected editor may inspect/export local sources without upload. If the user requests prior-work access/itemized costs before generation, report read-only known/unknown facts first: remembered style/reference identity does not prove media availability in this project. Never use paid generation as an access probe. For already-authorized cloud-only generation, pass asset IDs to the requested tool; supported tools request uploads on demand and give wait/retry instructions. Ask for Upload only if automatic upload is unavailable; relink only for missing sources.

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

Input Schema

Name	Required	Description
`type`	No
`limit`	No	Maximum cards returned (default 100, max 100).
`query`	No	Search text facts: asset id/name, folder, type/status, concise generation/property facts, or transcript text. This does not search pixels or visual actions.
`folder`	No	Exact media-pool folder path, case-insensitive, for example "Master/B-roll".
`offset`	No	Zero-based result offset (default 0). For continuation, pass nextOffset and keep the same query and filters.
`status`	No
`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

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.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent/non-destructive annotations: it explains result ordering (generating/failed first with jobId, status, progress), that status=generating surfaces recently completed jobs as completed with an assetId, the mediaPoolVisibility caveat, that every query term must match a fact, and what searchCoverage distinguishes. It also decodes sourceAccess.cloud/desktopRegistered/originalUpload=deferred semantics so the agent won't misread metadata as proof of local bytes.

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?

The purpose is front-loaded and the density of genuinely useful caveats is high, but it is delivered as one long semicolon-chained block with no structure. Several trailing sentences (paid generation as an access probe, when to Ask for Upload, relink for missing sources) are general workflow policy rather than browse-specific guidance and dilute the tool's actual contract.

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 describing what a card contains and how pagination and coverage signals behave, which is substantial for an 8-parameter browse tool. Some gaps remain around the unfiltered/type/folder combinations and projectId scoping, but an agent could call this correctly from the text provided.

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 coverage is 63%, and the description adds real meaning for status ('processing, not source access'), query ('every query term must match a fact'), and offset (use nextOffset with the same filters). However, type, folder, limit, projectId and timelineId receive no added explanation, leaving the coverage gap only partly compensated.

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?

Opens with a concrete verb+resource ('Browse current-project asset cards') and enumerates the card contents (identity, duration, dimensions, folder, processing/source access, transcript/generation/audio facts, match snippets). It explicitly carves out pixels to inspect_asset, which helps separate it from a key sibling, though it never mentions browse_library or inspect_item, so sibling differentiation is only partial.

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 concrete routing rules: use inspect_asset for pixels, pass transcriptRangesMs there, use track_progress for generating/failed jobs, and use nextOffset with the same query/filters to continue. It also warns not to assume user footage is present. It lacks a direct statement of when to prefer this over browse_library or inspect_item, so the alternative-set is incomplete.

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.