Skip to main content
Glama
Sign In

Vidova

by ai.vidova
OverviewDiscussionsAdmin

Create a component

scaffold_component

Write a compiling TypeScript skeleton and return the Asset ID. Pass name and kind (node|circle|rect|shader|counter|video|gradient). Do not pass source. Use kind=gradient for a scrim with typed colors and local coordinates; read guide/gradients-overlays. Use kind=shader for an SkSL adjustment layer. Read builtin-shaders before a shader. Required: read builtin-vidova-basics first unless that body is already in this conversation. Read builtin-fonts before setting fontFamily. After it succeeds, edit with replace_component or place with patch_film using the Asset ID. Read builtin-film-custom-components before that placement. branchId null (or left out) means the current version; a version id from list_branches writes that version without switching the editor to it. Not for a published library element; that is import_element. Not for film XML tags.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "kind": "<kind>",
      "name": "<name>",
      "branchId": "<branchId>",
      "projectId": "<projectId>"
    },
    "name": "scaffold_component"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindYes
nameYesComponent class name, a JavaScript identifier, or shared/<name> for a shared module that components import as ./shared/<name>.
branchIdYesVersion id from list_branches to write to, without switching the editor to it. null, or leaving it out, means the current version.
projectIdYesThe project this call runs on without changing the open project. null (or leaving it out) uses the open project. wait_for_jobs takes the projectId of the calls that started the jobs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare non-read-only, non-destructive, non-idempotent, closed-world, so the bar is lower; the description still adds real context: the required pre-reading of docs, the 'Do not pass source' prohibition, the Asset ID return, and the branchId null-vs-version-id write semantics. It does not cover failure modes such as name collisions, whether an existing component is overwritten, or what the error surface looks like for a non-idempotent create.

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 action and return value, then ordered by need: kinds, then doc prerequisites, then follow-up tools, then branchId semantics, then exclusions. Dense but nearly every sentence carries a distinct routing or prerequisite rule; the few imperative 'read X' clauses make it feel list-like rather than sentence-flowing.

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 correctly states the return value (Asset ID) and how to use it downstream. For a 4-param non-idempotent create it covers kinds, prerequisites, follow-ups, and branch targeting; it is only thin on the outcome of name reuse and on the projectId parameter.

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 75% and the schema already documents name and branchId, but the description adds genuine meaning beyond the raw enum: gradient is a scrim with typed colors and local coordinates, shader is an SkSL adjustment layer, and it ties kind values to the required reference docs. projectId is left entirely to the schema, which is the main gap.

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 artifact ('Write a compiling TypeScript skeleton and return the Asset ID') and names the exact discriminators against siblings: 'Not for a published library element; that is import_element' and 'Not for film XML <component> tags.' An agent can distinguish this from import_element, replace_component, patch_component, and patch_film without opening any schema.

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?

Gives explicit routing by kind ('kind=gradient for a scrim...', 'kind=shader for an SkSL adjustment layer'), states prerequisites ('read builtin-vidova-basics first unless that body is already in this conversation', 'Read builtin-fonts before setting fontFamily'), and prescribes the follow-up path ('After it succeeds, edit with replace_component or place with patch_film'). It also names two explicit exclusions with the correct alternative tool.

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

All Vidova 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