aicut

Analyse a video

analyze_video

Starts an AI analysis of an existing video and returns the new analysis's id immediately (it does NOT wait). It reads the video and describes it in detail (what happens, who is in it, the on-screen text, the pacing and cuts) as free-form text, plus the platform's own metadata (title, author, view count) when it has any. It generates nothing: use generate_video for that. WHEN: the user wants to understand, break down, transcribe or copy the structure of a video they link to or uploaded to aicut. WHICH VIDEOS: a public YouTube, TikTok or Instagram video url, or a video this account uploaded to aicut. Any other url, including another account's upload, is rejected: do not retry it in a different form. AFTER: poll get_analysis with the returned id every 5-10 seconds (never faster) until status is succeeded or failed. TIMING: an analysis usually finishes in under a minute and can take a few minutes for a long window or a slow platform. No timers or background shells. COST: this spends NO tokens, so there is nothing to confirm about cost and no reason to check the balance. It counts against a per-account daily analysis allowance: on daily_limit_exceeded wait rather than top up, and do not run analyses in a loop to explore. IDEMPOTENCY: a reused idempotency_key REPLAYS the first job whatever the settings: never reuse one for a new generation (this server's instructions).

Input Schema

Name	Required	Description
`url`	Yes	The video to analyse: a public YouTube, TikTok or Instagram video url, or the url of a video this account uploaded to aicut. Pass the url the user gave you, unchanged: do not rewrite it, strip it to an id or substitute another.
`end_seconds`	No	Where to stop, in seconds: at most 128 seconds after `start_seconds`, which is also the default, so a longer video is analysed in a window and a wider span is rejected rather than trimmed. Cover a long video with successive windows.
`start_seconds`	No	Where to start analysing, in seconds (default: the beginning). Use it when the user pointed at a moment.
`idempotency_key`	No	Retry-safety key (IDEMPOTENCY).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: async/no-wait behavior, typical and worst-case latency, zero token cost versus a daily per-account allowance with `daily_limit_exceeded` handling, no-loop guidance, and idempotency-key replay semantics. The 'generates nothing' statement is consistent with readOnlyHint=false (it still creates an analysis job) and idempotentHint=false (new jobs on repeat calls).

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 contract and organized into labeled sections (WHEN, WHICH VIDEOS, AFTER, TIMING, COST, IDEMPOTENCY), which is easy to scan. It is dense and somewhat repetitive in the COST sentence ('nothing to confirm about cost and no reason to check the balance'), which could be tightened.

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?

For an async job-creating tool with no output schema, the description supplies the return value (analysis id), the follow-up polling tool and interval, terminal statuses, latency expectations, and failure semantics. Nothing an agent needs to call it correctly is 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 baseline would be 3, but the description adds real meaning: the 128-second window cap and 'cover a long video with successive windows' for the start/end pair, and 'never reuse one for a new generation' for the idempotency key. It stops short of restating per-parameter syntax, which the schema already handles.

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 opening sentence states a specific verb and resource ('starts an AI analysis of an existing video') plus the async contract ('returns the new analysis's id immediately, does NOT wait'). It further specifies the output content (description text, on-screen text, pacing, platform metadata) and explicitly separates itself from `generate_video`.

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 clause, explicit WHICH VIDEOS acceptance/rejection rules with 'do not retry it in a different form', an AFTER section routing to `get_analysis` with a polling interval, and a WHEN-NOT for generation via `generate_video`. The agent has everything needed to choose this tool and to sequence follow-up calls.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All aicut tools Inspect

Try in Browser