Vixdeo — Tu Productor IA

Get project status

get_project_status

Read-onlyIdempotent

Where a project stands: lifecycle status, production drive (auto | manual | none), whether the line is waiting on funds, the cut (headVersionId, latestVersion), the runs (script, build, final render, publication) with status and cost, publication (whether the piece is published to the channel and whether the cut changed since; publication.gallery is its published gallery work, whether it exhibits the latest delivered final, whether the showcase lists it, with the reason when it does not, and its provenance), and — when delivered — finalVideoUrl with finalVideoDurationSec, the measured length of the delivered file. latestRunByKind is a compact index by run kind; the full objects live in runs. With run_id — the id of a job that an asynchronous authoring, rewrite or publication call returned — job reports that job: its status and, once completed, its result (a Director turn's reply and staged ops; a rewrite's new version; a publication's URL), or the reason it failed. fidelityReport is derived without a model from what the pipeline already wrote on the cut: per scene, the figures the narration says (the cited fact, the date the material gives for it and the figure's period when the data codex derived one), what the screen draws (each chart stage in drawing order with every value drawn, approx or withheld) and the facts the scene cites; per piece, the corpus policy, the closing card, the axes of the delivered final measured out of band, and the critic's scope — the house critic judges the script and does not see the charts or each figure's period. next names the following step. The server pushes no notifications: progress is visible only through a new call. $0.

Input Schema

Name	Required	Description	Default
`run_id`	No	Optional: a job id (`runId`) returned by an asynchronous tool of this project.
`project_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 27, 2026

addedInput schema / properties / run_id

Added value: +{
+  "description": "Optional: a job id (`runId`) returned by an asynchronous tool of this project.",
+  "type": "string"
+}

First observedSep 27, 2026

TDQS

A3.7/5.0

Behavior5/5

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

Annotations already establish the read-only, idempotent, non-destructive, closed-world safety profile, and the description adds substantial operational context: zero cost, no push notifications, polling-only visibility, how fidelityReport is derived, the house critic's scope, and what run_id job results can contain. There is no contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a dense run-on presentation of many return fields, with little structural separation. It is front-loaded with the overall purpose, but it is far longer than necessary and would benefit from bullets or grouping by return object.

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 and a complex return shape, the description does most of the work to explain lifecycle status, publication state, run objects, fidelityReport, job results, and next step. It is fairly complete for an agent to understand the response, though project_id semantics are left implicit.

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 50%, and only run_id has a schema description. The description meaningfully expands run_id by explaining that it is a job id returned by an asynchronous authoring, rewrite, or publication call and describing what the resulting job object reports, but project_id remains undocumented.

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 description clearly states that this tool reports where a project stands across lifecycle status, production drive, funding wait, cut versions, runs, publication, final video, and next step. It is specific and resource-focused, but it does not explicitly distinguish itself from siblings such as get_project_vbp or list_versions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description explains a specific usage mode for run_id, namely retrieving an asynchronous job's status/result, and notes that progress is visible only through a new call because the server pushes no notifications. However, it gives no explicit guidance on when to use this tool versus sibling status/list tools.

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

Resources

Need Help?