Skip to main content
Glama
Sign In

Pixelesq

by com.pixelesq
OverviewDiscussionsAdmin

Save section content

save_section_content
Destructive

Save a single section on a page. Only this section changes: the change is applied to the page's draft as one section edit, and sibling sections are never sent back. The section is matched by id or logicalId.

Use this for any edit to one section. Start with get_section_content to read the section, modify the fields you want, then pass the (partial or full) section object back.

Merge semantics (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: send the full array you want, including any items you are keeping. To remove one item, send the array without it. To add one, send the array with it.

section.type must be "Uislice" for regular content sections. The component name (HeroWithMedia, Faqs, etc) goes on uislices[0].type, not on section.type. An embedded header or footer ("Partial") is saved with save_partial_content instead.

A change of an existing section's component type (uislices[0].type, e.g. Faqs -> FaqsOnCard) is refused: use remove_section followed by insert_section with the new type. Script tags, event handlers and script links in content are refused.

Collection-fed items: when a section is bound to a collection, the paths get_section_content lists as collectionFed show the collection's entries and are read-only here; an edit there is refused, so 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.

Icons: a stored svgStr is drawn in place of pqIcon. On section and item icons, setting pqIcon drops the stored svgStr; on a button, menu or social icon send svgStr: null with the new pqIcon. An svgStr reference such as svg:1a2b3c4d from a compact read keeps that icon.

You MUST provide lastVersion for optimistic concurrency: get_section_content returns it as lastVersion, get_page_content as latestRevision.version, and each save returns the next one as revision.version. The save is refused when the page changed since that version was read.

Input Schema

NameRequiredDescriptionDefault
pageIdYesThe page ID
sectionYesThe updated section. Its id names the section to change: the section's id or its logicalId (the logicalId stays the same when a draft is forked from the published page; the id does not). Include type and uislices with the ctx and cfg fields you are changing.
projectIdYesThe project ID
lastVersionYesThe current revision version. Required for conflict detection.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / section / 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 / section / 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 / section / properties / uislices / minItems
      Removed value: -1
    • changedInput schema / properties / section / required
      Previous value: -[
-  "id",
-  "type",
-  "uislices"
-]New value: +[
+  "id",
+  "type"
+]
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the merge semantics (RFC 7396), wholesale array replacement, null-clearing behavior, id/logicalId matching, optimistic concurrency requirements, and specific refusals such as script tags and component-type changes. It also explains icon behavior and what to do when a collection-fed path is edited, which is substantial behavioral context for a destructive write 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 long but well-structured: the core purpose and workflow are front-loaded, and the merge, type, and version rules are broken out as distinct concerns. A few passages are dense, but nearly every sentence earns its place given the complexity of the nested section object.

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?

No output schema exists, but the description says each save returns the next version as revision.version, completing the concurrency loop. For a write tool with a deeply nested section payload, the description covers the critical semantics an agent needs 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains how lastVersion is used for conflict detection and how the section object is matched by id or logicalId. It also clarifies that section.type must be 'Uislice' and the component name belongs on uislices[0].type, which goes beyond the schema's field descriptions.

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?

The description states a specific verb (save) and resource (a single section on a page), and immediately scopes it: only this section changes, siblings are never sent back. It also distinguishes its role from save_partial_content and save_page_content, so an agent can select it without opening sibling schemas.

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?

It explicitly says 'Use this for any edit to one section' and prescribes a workflow starting with get_section_content. It names alternatives and when-not conditions: save_partial_content for Partial sections, remove_section plus insert_section for component-type changes, update_entry/save_entry_content for collection-fed paths, and revert_page_revision_to_version instead of revert_page_revision for failed drafts.

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

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