Skip to main content
Glama

Vixdeo — Tu Productor IA

by com.vixdeo
OverviewDiscussionsAdmin

Produce the video

produce
Destructive

Starts (or resumes) the production line of an EXISTING project: sets its drive to auto and dispatches the next station — the same sequence the human's «produce» button runs (enrich → studio build → final render). Publishing is not part of it. Applies to a project created without auto-production once edited, and to a line that stopped. The answer says whether the tick was really enqueued (dispatched, dispatch.reason) and what the line will do (line). On a piece whose final is already delivered the line does not render again by itself: the answer then carries finalRender — whether the studio changed after that final, and the quote of a NEW final render — and with confirm_spend=true the new render is launched, the same act as the human's «produce again» in the studio. Requires write. Spends budget under the org's quota and the daily free-action cap (each call counts as one action).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_idYes
confirm_spendNoOnly for a piece whose final is already delivered: true launches a new final render (a paid render, quoted in `finalRender.quote`). Default false: the answer quotes it and launches nothing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / confirm_spend
      Added value: +{
+  "description": "Only for a piece whose final is already delivered: true launches a new final render (a paid render, quoted in `finalRender.quote`). Default false: the answer quotes it and launches nothing.",
+  "type": "boolean"
+}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare destructive/non-idempotent/non-readOnly; the description goes well beyond them by disclosing the `write` permission requirement, budget/quota consumption and the daily free-action cap, and the exact response signals (`dispatched`, `dispatch.reason`, `line`, `finalRender`) including the no-op behavior when a final is already delivered. This is the kind of cost and side-effect context an agent needs before calling.

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-loads the core action and scope, then layers the edge cases; every sentence carries information (permissions, spend, response fields). It is dense and heavily parenthesized with backticks and guillemets, which costs some readability but not accuracy.

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?

With no output schema, the description still names the meaningful response fields and their conditional presence (finalRender only when a final exists, finalRender.quote, dispatch.reason), and covers auth, cost, and idempotency-adjacent behavior. Nothing an agent needs to call this 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 only 50% (project_id is undocumented), but the description compensates by fully explaining confirm_spend's semantics: default false quotes only, true launches a paid render equivalent to «produce again». project_id's meaning is left to inference, but it is self-evident from the purpose.

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?

States a specific verb and resource ('starts or resumes the production line of an EXISTING project') and pins down scope: the same sequence as the human «produce» button (enrich → studio build → final render), with publishing explicitly excluded. An agent can distinguish this from run_op/direct/stage_op by the described end-to-end pipeline and the existing-project constraint.

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 when-to-use conditions ('a project created without auto-production once edited' and 'a line that stopped') and a when-not ('Publishing is not part of it'), plus the special case for already-delivered finals. It stops short of naming an alternative sibling tool for the cases it does not cover, so it is clear context rather than full routing.

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

All Vixdeo — Tu Productor IA toolsInspect
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.

Resources