Skip to main content
Glama

Outil.io

Update page

update_page
Destructive

Modifier atomiquement une page par IDs. publish=true régénère immédiatement le HTML statique public, sans CI. Une version périmée renvoie 409 : relire avant de réessayer. Opérations: update_block (content/style/custom/sm/md), add_block, remove_block, update_section (name/style/custom), add_section, remove_section, move_section, set_theme, layout_images (voir describe_editor_capabilities). Carrousels: composant=carousel, slider ou banner; custom.donnees={slides:[{title,text,imageUrl,imageAlt,buttonLabel,href,canvas?}],autoplay,interval(2–120 secondes),transition(slide|fade),loop,perView(1–4),arrows,dots,appearance:{background,color,accent,buttonColor,fontFamily,radius,imageFit,imageOnly}}. Animations: custom.animation={type,duration,delay,repeat}; repeat=true rejoue à chaque retour dans la fenêtre. Survol: custom.hover=lift|zoom|glow|underline|fade. Une slide peut utiliser canvas: section native complète avec enfants et sm/md (300 blocs maximum, pas de carrousel/navigation/popup imbriqué). Valeurs locales : composant=range|stepper, donnees={label,value,min,max,step?,disabled?,sourceLayout?}, sans formulaire ni transmission. range sans pas explicite conserve step=any ; describe_editor_capabilities expose styles et cadres source. Choix exclusifs locaux : composant=choice-group, donnees={label,value,options:[{value,label,disabled?}],orientation,sourceLayout?}, sans navigation ni envoi de formulaire ; voir describe_editor_capabilities. Défilement continu natif : carousel.donnees.sourceScroll={desktop,tablet,mobile} conserve viewport, contentWidth, initialScrollLeft et items en coordonnées source ; exclusif avec miniatures et sourceLayoutBySlide, sans index actif ni commandes discrètes. Voir describe_page_composition. Miniatures synchronisées : slides[i].thumbnail={label,canvas,activeStyles?}, defaultIndex et sourceLayoutBySlide, un seul slider maître ; describe_page_composition expose le contrat et get_page_outline part=thumbnail donne les IDs éditables. Onglets composés : composant=tabs, donnees.items:[{title,canvas}] (1–12), defaultIndex, orientation. Les IDs des canevas imbriqués sont disponibles via get_page_outline ; update_block sectionId/blockId les modifie directement, sans renvoyer tout le parent. Les navigations sont des blocs composant= navigation dont custom.donnees contient brand, showBrand, logoUrl, links [{label,href?,children?:[{label,href}]}], ctaLabel/ctaHref, background, color, sticky. Les formulaires sont des blocs composant=form : content = titre, custom.donnees = {fields:[name,email,phone,message], hideTitle, fieldLabels:{name,email,phone,message}, consent, buttonLabel, accent (couleur du bouton), accentText, successMessage}. Fenêtres composées : popup.donnees.canvas est une section native avec label et sourceLayout facultatif ; aucun formulaire implicite. Ajouter un vrai enfant form ou une vidéo reconnue ; les enfants sont éditables via sectionId/blockId, get_page_outline part=popup. Voir describe_page_composition pour cadres, fermeture et limites. Popups : composant=popup, custom.donnees.trigger = delay (après donnees.delay secondes) | click (un bouton dont custom.href = « # » l’ouvre) | both.

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": {
      "pageId": "<pageId>",
      "expectedVersion": "<expectedVersion>",
      "publish": "<publish>"
    },
    "name": "update_page"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageIdYes
contentNo
publishYes
operationsNo
expectedVersionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Added
  4. Removed
  5. First observed

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description earns credit for what it adds on top: optimistic concurrency via expectedVersion with a 409 contract, the immediate non-CI static republication side effect of publish=true, and atomicity of the operation batch. It stops short of describing what a failed batch leaves behind or what the response contains.

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

Conciseness2/5

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

After a strong two-sentence opening the description becomes a multi-paragraph dump of component schemas (carousels, range/stepper, choice-group, tabs, navigation, forms, popups) that it itself says live in describe_page_composition and describe_editor_capabilities. The invocation-critical facts (atomicity, 409, publish) are front-loaded, but the bulk of the text does not help an agent call this tool correctly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive 5-parameter tool with no output schema, the essential behavioral facts (atomic batch, version conflict, immediate publication, nested block editing via sectionId/blockId) are present. Gaps remain around the 'content' parameter, per-operation index/value semantics, and the 100-operation cap, which matter for correct invocation.

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?

Schema description coverage is 0%, so the description must carry all parameter meaning. It does explain publish (immediate static regen), expectedVersion (stale version yields 409) and the op enum plus sectionId/blockId targeting for nested canvases, but the 'content' parameter is never mentioned and neither 'index' nor 'value' is given semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb and resource ('Modifier atomiquement une page par IDs') and the description enumerates the exact operation types the tool accepts (update_block, add_block, remove_block, update_section, move_section, set_theme, layout_images). It never positions itself against close siblings like apply_page_changes, batch_update_pages, edit_live_page or compose_page, so an agent still has to infer which mutation entry point to pick.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

There is real guidance for the retry path: a stale version returns 409 and you must re-read before retrying, and publish=true regenerates public HTML immediately without CI. But there is no when-to-use/when-not guidance relative to the many sibling write tools, and the repeated 'voir describe_page_composition' / 'describe_editor_capabilities' pointers are capability lookups rather than selection criteria.

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.