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: load 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 loaded skill stays loaded for the conversation: never load 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 loading 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.

Input Schema

TableJSON 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.7/5.0
Behavior5/5

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

Despite annotations covering the safety profile (destructive, idempotent, not read-only), the description adds substantial context the annotations cannot: build/type-check failures reject the write before committing, warnings do not block, the previous source and revision remain intact, and it lists required skills, allowed packages, the mandated atTime API, and the refusal of animate()/animateIn()/animateOut() generators.

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?

Most sentences carry load-bearing rules, but they are delivered as one dense unbroken block with no grouping or bullets, mixing skill-loading rules, import rules, the animation API, and shared-module semantics. The core purpose is front-loaded, yet the remaining wall of text is hard to scan.

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 high-complexity mutation tool with no output schema, the description covers the return value (Asset ID), failure/rejection behavior, version preservation, dependency compilation across the project, and the full source authoring contract. An agent has everything needed to call it correctly.

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?

With 75% schema description coverage the baseline is 3, but the description compensates heavily: the undocumented `source` parameter is fully specified (required imports, atTime contract, export shape, forbidden generator methods, shared-module variant), and it clarifies the shared/<name> naming form. branchId and projectId explanations largely restate the schema, which caps this at 4 rather than 5.

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 ('Create or replace the complete TypeScript component source') and immediately distinguishes itself from siblings, naming import_element for unchanged library elements and scaffold_component for skeletons. An agent can select this over add_from_library, patch_component, or scaffold_component 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 rules: use import_element for an unchanged library element, scaffold_component for a skeleton, replace_component for a full source write, and patch_component implicitly for targeted edits. It also states the condition for shared/<name> modules and the branchId semantics for writing a version without switching the editor.

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.