Skip to main content
Glama

Replace a component

replace_component
DestructiveIdempotent

Create or replace the complete TypeScript component source. 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": {
      "source": "<source>",
      "name": "<name>",
      "branchId": "<branchId>",
      "projectId": "<projectId>"
    },
    "name": "replace_component"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesComponent class name, a JavaScript identifier, or shared/<name> for a shared module that components import as ./shared/<name>.
sourceYes
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.6/5.0
Behavior4/5

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

Adds substantial context beyond the annotations: build/type-check failures reject the write before committing, warnings do not block, the previous source and revision remain intact, and sources declaring animate()/animateIn()/animateOut() generators are refused. The 'previous source and revision remain intact' line sits in mild tension with destructiveHint=true, but is best read as recoverable-via-revision rather than a direct contradiction.

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 purpose and return value, then constraints, so the agent can stop reading early. It is dense and long, with the branchId semantics restated from the schema and skill rules stacked into one paragraph, but nearly every sentence describes a condition that will cause rejection, so little is disposable.

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?

No output schema exists, and the description covers the return (Asset ID), the failure modes (type-check rejection, project-wide compile break), the recovery story (revision intact), and the cross-component contract (children imported as ./Name, parent calls child.atTime). Nothing an agent needs to invoke this destructive write 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?

The source parameter has no schema description, and the description compensates heavily: required named class export, the mandatory atTime(time, duration) API, allowed imports, the generator refusal, no shadowing Node methods, and the shared-module export shape with its file path. The branchId explanation largely repeats the schema text, and projectId gets no mention.

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 specific verb+resource+scope: 'Create or replace the complete TypeScript component source,' and states the return (Asset ID). It explicitly names the siblings it is not — import_element for unchanged library elements, scaffold_component for skeletons, patch_component implied by 'complete ... source' versus patching.

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 rules to alternatives ('Use import_element for an unchanged library element and scaffold_component for a skeleton') plus conditional prerequisites: which skill to read before the first component write, first fontFamily, first DataSrc prop, first flex layout, first patch_film placement. It also states the shared-module alternative mode for name shared/<name>.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.