输入口播文案与素材，自动生成安全排版出片计划并云端渲染成片。前 3 条免费。
Scored across 3 tools
Each tool maps to a distinct stage of the pipeline: planning (explicitly non-rendering), submitting a render, and polling status. The descriptions actively disambiguate the plan-vs-render distinction, so an agent cannot easily confuse them.
All three follow a predictable verb_recut_noun pattern (generate/get/render). Verbs are distinct and the shared 'recut' infix reinforces the domain.
Three tools is at the low end but genuinely matches the narrow plan→render→poll workflow with no filler. It could use one or two more operational tools, but nothing here feels redundant.
The core lifecycle of producing a recut video is fully covered: plan, render, and retrieve the result. Minor gaps exist around job management (cancel, list, or retry a render) that an agent would have to work around.
根据口播视频元信息与文案，生成出片计划（人脸禁区安全布局 / MG 卡片反选 / BGM 情绪匹配），不渲染。
| Name | Required | Description | Default |
|---|---|---|---|
| copy | Yes | 口播文案（纯文本或结构化章节） | |
| slug | No | ||
| theme | No | apple-keynote | |
| video | Yes | 视频元信息 | |
| zones | No | 可选，客户端人脸禁区探测结果 {available_bands:[{id,x,y,w,h}]} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose the key behavioral trait that no rendering occurs, which tells the agent this is a planning-only call. However, it says nothing about whether a plan/job artifact is persisted, whether a job id must later be polled via get_recut_job, or any cost/latency/permission expectations.
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: the purpose, the three plan components, and the non-render constraint each add distinct information. Nothing is repeated from the title or schema.
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?
There is no output schema, yet the description does not say what the returned plan looks like or how the caller consumes it (inline JSON vs. persisted job consumed by get_recut_job). Given a nested 'video' object and optional 'zones' among 5 parameters, the description leaves an important gap for correct downstream use.
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 60%, so baseline is 3. The description only restates the two documented inputs (文案, 视频元信息) and adds no meaning for the undocumented 'slug' or the 'theme' default value, nor does it explain how 'zones' influences the face-exclusion layout.
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 (生成) and resource (出片计划) and enumerates what the plan contains (人脸禁区安全布局 / MG 卡片反选 / BGM 情绪匹配). The closing '不渲染' explicitly separates it from the render_recut_video sibling, so an agent can distinguish it without opening a schema.
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?
'不渲染' implies this is a planning step preceding rendering, but the description never names render_recut_video or get_recut_job as the follow-up, and gives no preconditions (e.g. whether zones must be supplied by the client for face-safe layout). Usage is implied rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询渲染任务状态与成片 URL。
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must provide the full behavioral picture. '查询' implies a read-only operation, but nothing is said about error behavior for an unknown or expired job_id, whether the URL is absent until rendering completes, or whether results expire. That is a meaningful gap for a job-status tool that agents will typically poll.
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?
The description is a single efficient sentence that front-loads the resource and the two things returned (status and finished URL). Nothing is wasted, though the sentence is sparse to the point of underspecification.
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 simple single-parameter lookup with no output schema, the description does state the return contents (status plus finished video URL), which is helpful. However, it omits polling and error semantics and leaves job_id provenance unexplained, so it is only minimally adequate.
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 0%, so the schema provides no documentation for job_id, and the description does not compensate at all. It does not say where job_id comes from (presumably 'render_recut_video') or what format it takes.
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?
The description states a specific verb and resource combination ('查询渲染任务状态与成片 URL'), which makes clear that this is a status and result lookup rather than an action like planning or rendering. It is reasonably distinguishable from the sibling tools 'generate_recut_plan' and 'render_recut_video', though it never explicitly names them.
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?
The description gives no guidance about when to call this tool: it does not say whether this is meant for polling after 'render_recut_video', whether retry or polling intervals matter, or what to do if the job is still running. No alternatives or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
提交渲染任务，返回 job_id；用 get_recut_job 轮询成片。
| Name | Required | Description | Default |
|---|---|---|---|
| copy | No | ||
| plan | No | 可直接传 generate_recut_plan 的结果，跳过重新生成 | |
| slug | No | ||
| video | No | ||
| media_url | Yes | 口播视频素材的公开可下载地址 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description usefully discloses that this is an asynchronous render submission that returns a job_id and requires polling via get_recut_job. It does not cover permissions, side effects, failure behavior, resource cost, or input requirements beyond the schema.
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?
The description is two compact clauses with zero wasted text. The core action and the required follow-up polling step are front-loaded.
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 tool with no annotations, no output schema, five parameters including nested objects, and low schema description coverage, the description is too sparse. It covers the async job pattern but leaves optional inputs, prerequisites, and error behavior unexplained.
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 40%, and the description adds no parameter-level meaning for copy, slug, video, or the overall plan workflow. It explains the return value and polling pattern, but does not compensate for the undocumented optional parameters.
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?
The description states a specific action and resource: submit a render task and return a job_id. It also distinguishes the follow-up polling tool get_recut_job, though it does not mention generate_recut_plan.
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?
It clearly says to use get_recut_job to poll the finished video, giving the next-step workflow. However, it does not explicitly say when to call this versus generate_recut_plan, nor does it state prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
generate_recut_planget_recut_jobrender_recut_videoClip long videos, render branded short-form video, schedule to TikTok, Reels, Shorts and X.
Script in, finished 1080p narrated video out. Pay per call in USDC via x402.
Render an MP4 from your own images, clips, voice-over and timed captions. JSON to video.
Talking-actor and faceless short videos from your AI agent, with a free quote before each render
Add one secure layer between your agents and this server.
