Pixelesq

Insert section

insert_section

Destructive

Insert a brand-new section at a given position on a page. It is added to the page's draft as one section; existing sections are not sent back and are untouched.

Use get_section_defaults first to get a valid section template for the type you want (e.g. HeroWithMedia, Faqs). Assign one fresh UUID and use it for both section.id and uislices[0].id. That UUID becomes the section's logicalId, which every section tool accepts; the result also gives the id hermes stored it under. Then call insert_section with position set to the zero-based index where the new section should appear, or -1 to append at the end. uislices[0].props needs both ctx and cfg, and uislices[0].type must be a type from list_section_types.

Set section.type to "Uislice" for a regular content section (or "Partial" for an embedded partial). The component name (HeroWithMedia, Faqs, etc) goes on uislices[0].type, not on section.type. When inserting a Partial (shared header/footer), use the partial's id (from list_partials) as section.id; its content stays in the partial, so uislices may be left empty.

A uislices[0].collectionId binds the new section to that collection in the same step. Script tags, event handlers and script links in content are refused.

You MUST provide lastVersion from get_page_content latestRevision.version; the insert is refused when the page changed since.

Input Schema

Name	Required	Description
`pageId`	Yes	The page ID
`section`	Yes	The full new section. section.id and uislices[0].id must be the same fresh UUID.
`position`	Yes	Zero-based index where the new section should appear. Use -1 to append at the end.
`projectId`	Yes	The project ID
`lastVersion`	Yes	The current revision version. Required for conflict detection.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 22, 2026

addedInput schema / properties / position / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / position / minimum
```
Added value: +-9007199254740991
```

changedInput schema / properties / position / type

Previous value: -"number"New value: +"integer"

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"
+]

First observedOct 17, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations: the write lands in the draft, existing sections are untouched, script tags/handlers/links are refused, and the insert is rejected when lastVersion is stale. It also explains the identity model — the supplied UUID becomes logicalId while the response carries the internal id hermes stored.

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-loads the core operation before the setup workflow, which is the right order. Some material restates the schema's own field descriptions (the Uislice vs component-name note appears in both), but nearly every sentence carries non-obvious operational guidance.

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 destructive, deeply nested, five-required-parameter mutation with no output schema, the description covers sequencing, identity, refusal conditions, and Partial-vs-Uislice branching. An agent has what it needs to construct a valid call without trial and error.

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 the schema lacks: section.type is 'Uislice' vs 'Partial' while the component name belongs on uislices[0].type, Partial sections may leave uislices empty, and collectionId binds in the same step. The lastVersion parameter is explained only by reference to another tool rather than its format.

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?

Opens with a specific verb+resource+location: 'Insert a brand-new section at a given position on a page,' and immediately clarifies scope ('added to the page's draft as one section; existing sections are not sent back and are untouched'). It does not explicitly contrast itself with save_section_content, reorder_sections, or remove_section, so an agent must infer the boundary from names alone.

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 an explicit ordered workflow: call get_section_defaults first, assign one fresh UUID, then call insert_section with position as a zero-based index or -1 to append. It also names prerequisites (get_page_content latestRevision.version) and the conditions under which the call is refused.

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.

Insert section

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources