Vidova

Edit a component

patch_component

Apply exact source replacements to an existing component in one compile. Each replacement needs find, replace, all (false for a unique match). Empty replace deletes a span. Returns the Asset ID. Build and type-check failures reject the write before committing. The previous source and revision remain intact. Warnings do not block the build. Fix errors; do not chase warnings unrelated to visible defects. branchId null (or left out) means the current version; a version id from list_branches writes that version without switching the editor to it. Skills: read builtin-vidova-basics before the first component write, builtin-fonts before the first fontFamily, builtin-data-files before the first DataSrc prop (a map or chart from an uploaded data file), builtin-layout-flexbox before the first flex layout (a row of chips or pills, a card around text), and builtin-film-custom-components before the first placement with patch_film. A skill read once stays in the conversation: never read it again. Import @vidova/2d, @vidova/core and the packages in builtin-component-libraries; for a 3D scene also @vidova/components (View3D), three/webgpu and three/tsl, after reading builtin-3d. Export the named class and write atTime(time, duration), the only animation API: it sets every animated property from time and never yields or awaits. A source that declares an animate(), animateIn() or animateOut() generator is refused. Media signals use VideoSrc or AssetSrc, never string. Never shadow Node methods such as draw, scale or position. Use import_element for an unchanged library element and scaffold_component for a skeleton. name shared/ writes a shared module instead: plain TypeScript exports (functions, constants, types; no class, no Asset ID) at src/components/custom/shared/.ts that components import as ./shared/. The whole project is compiled and the write is rejected when a component that imports it breaks. Components import each other as ./Name; the parent calls child.atTime(time, duration) itself.

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": {
      "replacements": "<replacements>",
      "name": "<name>",
      "branchId": "<branchId>",
      "projectId": "<projectId>"
    },
    "name": "patch_component"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Component class name, a JavaScript identifier, or shared/<name> for a shared module that components import as ./shared/<name>.
`branchId`	Yes	Version id from list_branches to write to, without switching the editor to it. null, or leaving it out, means the current version.
`projectId`	Yes	The 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.
`replacements`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 19, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations: build and type-check failures reject the write before committing, the previous source and revision remain intact, the whole project is compiled and the write is rejected if an importing component breaks. It also discloses hard refusals (animate/animateIn/animateOut generators) and constraints (atTime is the only animation API, no shadowing Node methods, media signals use VideoSrc/AssetSrc).

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

Conciseness3/5

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

The purpose is front-loaded in sentence one, but the body is a dense wall mixing skill-reading policy, import/package rules, API contracts and naming conventions — much of which reads like documentation rather than tool selection guidance. Several clauses duplicate the schema verbatim and could be trimmed without loss.

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 a destructive-ish mutation with no output schema, the description covers everything an agent needs: atomicity, failure/rejection behavior, revision retention, name variants, and the constraint set for generated source. No material gap remains.

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?

With 75% schema coverage the schema already documents find, replace, all, branchId and projectId in near-identical wording; the description largely restates these ("Empty replace deletes a span", "branchId null means the current version"). Its genuinely additive points — atomic single compile and the shared/<name> naming variant — are useful but modest against a schema doing the heavy lifting.

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?

Opens with a precise verb+resource: "Apply exact source replacements to an existing component in one compile." It also names the sibling alternatives it is not (import_element for an unchanged library element, scaffold_component for a skeleton), so an agent can route 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.

Usage Guidelines5/5

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

Explicit alternatives and selection rules: import_element vs scaffold_component vs patch_component, plus the shared/<name> variant that writes a plain TypeScript module instead of a component. It also gives error-handling policy ("Fix errors; do not chase warnings unrelated to visible defects") and preconditions (which skills to read before which write).

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

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