Skip to main content
Glama
Sign In

Mondovo

by com.mondovo.app
OverviewDiscussionsAdmin

Replace one file in a design

update_variation_file
Idempotent

Replace the code of a SINGLE file that already exists in a design variation, leaving every other file and all content untouched. It never creates a file: to add a NEW page you wrote, use add_page with code. Use this for targeted code edits — a colour, a layout tweak, one section — instead of resending the whole design through import_design_variation, which burns a variation slot and re-uploads everything. Start from the current code returned by read_design (requires source:read) — send the COMPLETE file, not a fragment. The patched file is run through the same validation a full import gets; if it fails, NOTHING is written and the issues come back. On success the edit is recorded in version history (version in the response) so it shows in list_versions and can be undone with restore_version; a history_warning means it saved but was not recorded. Omit index to patch the site's active design. PAGE DRAFTS: pass the draft's slug (from create_page_draft / list_page_drafts) as file and its design's index to edit the draft instead of the live page. A draft must keep reading its own text (content.<content_key>); code that reads the live page's key is refused, because the draft would then edit the live page.

Input Schema

NameRequiredDescriptionDefault
codeYesComplete new TSX for that file — same authoring contract as create_site_from_design
fileYesFile name or slug to replace, e.g. "Header", "/" for the homepage, or a page draft's slug such as "/about--draft-7f2a"
indexNoVariation index from list_variations. Defaults to the active design.
site_idYesThe site to patch
user_goalNoOptional: the user's goal behind this call, in one short sentence of plain words (e.g. "add a page so customers can book tables"). No names, emails or other personal details.
expected_row_versionNoThe `row_version` read_design returned. The edit is refused with a conflict if the design changed since. Required to remove live menu links (navigation/footer).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / user_goal
      Added value: +{
+  "description": "Optional: the user's goal behind this call, in one short sentence of plain words (e.g. \"add a page so customers can book tables\"). No names, emails or other personal details.",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / expected_row_version / description
      Previous value: -"Optional row revision read with the variation. The edit is refused with a conflict if it is stale."New value: +"The `row_version` read_design returned. The edit is refused with a conflict if the design changed since. Required to remove live menu links (navigation/footer)."
  3. Changed1 schema field changed
    • addedInput schema / properties / expected_row_version
      Added value: +{
+  "description": "Optional row revision read with the variation. The edit is refused with a conflict if it is stale.",
+  "minimum": 0,
+  "type": "integer"
+}
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare it is a non-destructive idempotent write; the description goes well beyond them by disclosing the validation gate (nothing is written on failure), version-history recording, the meaning of `history_warning`, conflict behaviour on `expected_row_version`, and the draft rule that code reading the live page's content key is refused. That is exactly the extra context annotations cannot carry.

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 the negative scope before alternatives, and every sentence carries operational information. It is on the long side — the page-draft paragraph could be split or tightened — but no sentence is filler.

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 6-parameter mutation with no output schema, the description covers failure modes, the returned `version`, undo path via restore_version, conflict handling via `expected_row_version`, and the draft exception. An agent has everything needed to call it correctly on the first attempt.

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 100%, so baseline is 3, but the description adds real semantics on top: `code` must be the COMPLETE file not a fragment, omitting `index` targets the active design, and `file` accepts a draft slug from create_page_draft. It does not explain `user_goal` or `expected_row_version` beyond what the schema already says.

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 the exact verb and resource (replace the code of a single existing file in a design variation) plus the blast radius (every other file and all content untouched). Explicitly contrasts with add_page and import_design_variation, so an agent can pick it 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 both sides of the routing decision: use this for targeted edits (a colour, a layout tweak, one section), use add_page for new pages, use import_design_variation for whole designs. It also spells out the prerequisite (start from read_design, requires `source:read`) and the draft workflow, leaving nothing to inference.

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

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