Pixelesq

Save page content

save_page_content

Destructive

Save sections to a page. Replaces the page's sections list with the provided sections (section-level add/remove/reorder happens here; a section you leave out is removed explicitly, on every project), but within each matching section, cfg and ctx are merged against the server's current state.

Each section has: id (uuid), name, type ("Uislice" for regular content sections, "Partial" for embedded partials), and uislices array. Each uislice has: id (uuid), type (the component name like HeroWithMedia, Faqs), collectionId (optional), and props with ctx (content) and cfg (layout config).

Common uislice component types (uislices[0].type): HeroWithMedia, HeroWithMediaBelow, StickyFeatures, StickyFeaturesCard, HowItWorks, Faqs, FaqsOnCard, SimpleForm, PqPricing, CardWithMedia, TextGrid, LogoGrid, MediaBentoCards, TestimonialGrid.

Merge semantics for cfg and ctx within each section (RFC 7396 JSON Merge Patch):

Fields you send override the server's values.
Fields you omit are preserved unchanged.
To explicitly clear a field, send it as null.
Arrays (ctas, items, media, icons, menu, social, legal) are REPLACED wholesale.

Sections are matched by id or logicalId. A section that keeps a logicalId but matches nothing is refused with a request to read the page again. A new section needs both props.ctx and props.cfg: call get_section_defaults first to get properly structured defaults, then change text values (title.value, desc.value, CTA labels/urls, media src/alt) while preserving structure.

Refused instead of silently dropped: a change to an embedded header or footer's content (save it with save_partial_content; a "Partial" section may be sent with an empty uislices list to keep it in place), a change of an existing section's component type (use remove_section then insert_section), an unknown section type, and script tags, event handlers or script links in content. Items a section draws from a collection are kept as stored; change the entries with update_entry or save_entry_content. If a page draft stops loading after a save, undo that save with revert_page_revision_to_version (get_page_revisions lists the save numbers), not revert_page_revision.

You MUST provide lastVersion from get_page_content latestRevision.version for optimistic concurrency.

Input Schema

Name	Required	Description
`pageId`	Yes	The page ID
`sections`	Yes	Complete list of sections. Replaces existing sections wholesale. Call get_section_defaults to get the correct shape for each section type.
`projectId`	Yes	The project ID
`lastVersion`	Yes	The current revision version (from get_page_content latestRevision.version). Required for conflict detection.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 22, 2026

addedInput schema / properties / sections / items / properties / logicalId

Added value: +{
+  "description": "The section's stable identity from a read; keep it when sending a section back",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedInput schema / properties / sections / items / properties / uislices / description

Added value: +"One uislice for a 'Uislice' section. A 'Partial' section may send an empty list: it is placed by reference and keeps its own content."

removedInput schema / properties / sections / items / properties / uislices / minItems
```
Removed value: -1
```

changedInput schema / properties / sections / items / required

Previous value: -[
-  "id",
-  "type",
-  "uislices"
-]New value: +[
+  "id",
+  "type"
+]

First observedOct 17, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the destructiveHint annotation by explaining the replacement semantics, which omissions cause removal, how cfg/ctx merge against server state, which changes are refused rather than silently dropped, and which recovery tool to use after a bad save. This is exactly the behavioral context needed for a destructive save tool.

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?

The description is front-loaded and logically organized, but it is lengthy and includes a long list of common component types that is helpful yet not strictly essential. For a complex destructive save operation the length is mostly justified, though some sections could be tighter.

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?

Given the complex nested schema, destructive behavior, and lack of an output schema, the description is complete: it covers prerequisites, merge semantics, matching rules, refusal cases, alternatives, and post-failure recovery. An agent has enough information to call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is already 100%, the description adds crucial semantic meaning: section/uisclice structure, matching by id or logicalId, RFC 7396 merge behavior, array replacement rules, and the requirement that lastVersion come from get_page_content. These details materially affect correct parameter construction.

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?

Starts with a specific verb and resource ('Save sections to a page') and immediately clarifies the exact operation: replacing the page's section list while merging cfg/ctx within matching sections. It also distinguishes page-level section work from sibling operations like insert_section, remove_section, save_section_content, and save_partial_content.

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?

Explicitly says when section-level add/remove/reorder should happen here and names alternatives for adjacent operations: save_partial_content for embedded header/footer content, remove_section then insert_section for component type changes, update_entry/save_entry_content for collection items, and get_section_defaults for new sections.

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

All Pixelesq tools Inspect

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

Need Help?