Skip to main content
Glama
Sign In

Pixelesq

by com.pixelesq
OverviewDiscussionsAdmin

Save partial content

save_partial_content
Destructive

Save sections to a partial (header, footer, or other reusable section). Replaces the partial's sections list with the provided sections (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. Sections are matched by id or logicalId.

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.

section.type must be "Uislice" for regular content sections or "Partial" for embedded partials. The component name (HeaderWithMenu, SimpleFooter, etc) goes on uislices[0].type. A new section needs both props.ctx and props.cfg (get_section_defaults gives both) and a type from list_section_types.

Refused instead of silently dropped: a change of an existing section's component type (save the partial without it, then with the new section), a section that keeps a logicalId but is no longer on the partial (read it again), and script tags, event handlers or script links in content.

You MUST provide lastVersion from get_partial_content latestRevision.version for optimistic concurrency. The result carries the new latestRevision with its headAnchor for publish_partial.

Input Schema

NameRequiredDescriptionDefault
sectionsYesComplete list of sections on the partial. Replaces existing sections wholesale.
partialIdYesThe partial ID
projectIdYesThe project ID
lastVersionYesThe current revision version from get_partial_content latestRevision.version. Required for conflict detection.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • 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"
+]
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, and the description earns that hint by spelling out exactly what is destroyed: omitted sections are removed explicitly on every project, and arrays (ctas, items, media, icons, menu, social, legal) are REPLACED wholesale. It further discloses merge semantics (RFC 7396), explicit refusals (component type changes, stale logicalIds, script tags), and concurrency requirements.

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 operation and replace semantics, then proceeds to merge rules, type guidance, refusal cases, and the version requirement in a logical order. The bullet list for merge semantics is dense but every line carries non-obvious behavioral information; only the prose paragraph on refusals is slightly verbose.

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?

Complete for a destructive, nested mutation with no output schema: it covers prerequisites, replacement scope, per-field merge behavior, refusal conditions, concurrency, and the returned latestRevision.headAnchor needed for publish_partial. 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.

Parameters5/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 substantial meaning beyond field types: merge behavior for cfg and ctx, the null-clears rule, array replacement, the distinction between section.type ('Uislice'/'Partial') and the component name on uislices[0].type, and matching by id or logicalId. This is exactly the kind of semantics the schema cannot express.

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 specific verb and resource ('Save sections to a partial (header, footer, or other reusable section)') and immediately distinguishes it from save_page_content and save_section_content via the 'partial' scoping. An agent can identify the target and operation without reading the schema.

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

Usage Guidelines4/5

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

Specifies prerequisites very clearly: lastVersion from get_partial_content, defaults from get_section_defaults, types from list_section_types, and the follow-up publish_partial. It also gives a valid alternative flow when a component type change is refused ('save the partial without it, then with the new section'). It doesn't explicitly say when to use save_page_content or save_section_content instead, but the scoping makes the boundary clear.

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