Skip to main content
Glama
Sign In

Mondovo

by com.mondovo.app
OverviewDiscussionsAdmin

Edit a design's copy without touching code

patch_variation_content
Idempotent

Merge a JSON patch into a design variation's content — headlines, prices, FAQ answers, image URLs, link targets. Because content and code are separate, most refinements are pure content edits and need no code change at all. Merge semantics: objects recurse (so patching content.hero.headline keeps hero.subhead), null deletes a key, everything else replaces. Validated against the code's references before writing — removing a key the code reads is rejected rather than silently blanking a section. Prefer this over refine_site for any copy change: it is instant and needs no AI round-trip. The edit is recorded in version history (version in the response) and can be undone with restore_version; a history_warning means it saved but was not recorded. Omit index to patch the active design. NOTE: form definitions (forms, modalForms) are site-global — a form id the site already defines is ONE definition shared by every design, so editing it applies site-wide regardless of index, and the response echoes the key in site_global_keys so you can say so rather than reporting a per-design change. Send the full edited form entry (same id); new form ids stay with this design. PAGE DRAFTS: a draft's text lives under its own content_key (from create_page_draft / list_page_drafts) — patch ONLY that key, with the draft's design index, to change the draft without touching the live page. Patching the live page's keys (hero, page_about, …) changes the live site.

Input Schema

NameRequiredDescriptionDefault
indexNoVariation index from list_variations. Defaults to the active design.
patchYesContent keys to merge, e.g. { "pricing": { "monthly": "$29" } }
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?

Well beyond what annotations supply: it documents merge semantics (recursion, null deletes, replace otherwise), pre-write validation that rejects removing keys the code reads, version-history recording with `version`, the `history_warning` failure mode, and the site-global forms caveat with `site_global_keys` in the response. These are exactly the behaviors an agent could not infer from readOnlyHint=false/idempotentHint=true alone.

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 merge rules, then progressive detail on version history, forms, and drafts. It is dense and long, but nearly every clause carries operational information; the forms and drafts paragraphs are the longest but also the least inferable.

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 nested-patch mutation tool with no output schema, the description still names the response fields the agent needs (`version`, `history_warning`, `site_global_keys`), covers conflict refusal, and explains the draft-vs-live key trap. Nothing an agent needs to call this 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?

Schema coverage is 100%, so baseline is 3, but the description adds genuine semantics the schema cannot express: the merge behavior of `patch` (recurse vs delete vs replace), what omitting `index` means, and the consequence of `expected_row_version` conflicts. Marginal deduction because `user_goal` is never mentioned in the description.

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 ('Merge a JSON patch into a design variation's content') and immediately enumerates what that content includes (headlines, prices, FAQ answers, image URLs, link targets). It distinguishes itself explicitly from refine_site and update_variation_file, so an agent can pick it out of a large sibling list.

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: 'Prefer this over refine_site for any copy change: it is instant and needs no AI round-trip', omit `index` for the active design, and use the draft's own `content_key` for page drafts vs live-page keys. It also warns that form edits are site-global and that expected_row_version is required to remove live menu links.

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