Pixelesq

Bind section to collection

bind_section_to_collection

Destructive

Connect a Uislice section on a page to a collection (datasource), so the section's items render entries from that collection instead of static placeholder content.

This mirrors the "Datasource" panel in the Apollo editor. It is a separate operation from save_section_content / save_page_content / save_partial_content; those tools do NOT change a section's collection binding. Use it after inserting a list-style section (cards, grid, listing) that should show collection entries.

A binding has two parts: the collection, and a mapping that says which entry fields fill which item fields. Pass the mapping as connection, keyed by the section's list path, for example {"ctx.items": {"dataSourcePath": "entries", "fields": {"title.value": "<%=entryName%>", "desc.value": "<%=summary%>", "media[0].src": "<%=image.src%>"}}}: entryName is the entry's name and the other names are the collection's fields (get_collection lists them). Without connection, a section that already has a mapping keeps it; otherwise a mapping is built from the section's items and the collection's fields (the entry name as the item title, a text field as the description), and the result says what it mapped. When no mapping can be built the result carries a warning and the section keeps showing its own items until one is sent.

Mechanics: looks up the section by sectionId (id or logicalId), validates that section.type === "Uislice", and applies one SET_COLLECTION operation with the mapping: both land on the page's draft under the revision lock, checked against the section's current anchor, and the draft is forked from the published head first when needed.

Errors: returns a clear error if the section is not found, the section is a Partial (binding partials is not supported here), the collection does not exist, or the section changed while the request was in flight (BASE_VERSION_MISMATCH: read the page again and retry with a new idempotencyKey).

Input Schema

Name	Required	Description
`pageId`	Yes	The page ID containing the section
`projectId`	Yes	The project ID
`sectionId`	Yes	The section's id or logicalId (from get_page_content)
`connection`	No	The mapping, keyed by the section path it fills, e.g. {"ctx.items": {"dataSourcePath": "entries", "fields": {"title.value": "<%=entryName%>"}}}. Omit to keep the section's mapping or have one built.
`collectionId`	Yes	The collection ID to connect
`idempotencyKey`	No	Stable key for a safe retry: the same key replays the first result instead of applying twice. Reuse a key only for a call that got no answer; after any error, read the page again and use a new key.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 22, 2026

addedInput schema / properties / connection

Added value: +{
+  "additionalProperties": {},
+  "description": "The mapping, keyed by the section path it fills, e.g. {\"ctx.items\": {\"dataSourcePath\": \"entries\", \"fields\": {\"title.value\": \"<%=entryName%>\"}}}. Omit to keep the section's mapping or have one built.",
+  "propertyNames": {
+    "type": "string"
+  },
+  "type": "object"
+}

changedInput schema / properties / idempotencyKey / description

Previous value: -"Stable key for a safe retry: the same key replays the first result instead of applying twice"New value: +"Stable key for a safe retry: the same key replays the first result instead of applying twice. Reuse a key only for a call that got no answer; after any error, read the page again and use a new key."

First observedOct 17, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations, the description discloses concrete mechanics: validates section.type === "Uislice", applies a single SET_COLLECTION operation, writes to the page draft under the revision lock, checks the section anchor, and forks the draft from the published head when needed. It also explains mapping fallback behavior, warning behavior when no mapping can be built, and specific error cases including BASE_VERSION_MISMATCH retry guidance with a new idempotencyKey.

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 with purpose and exclusion, then organized into mapping, mechanics, and errors. It is long and dense, but the complexity of the nested mapping and revision-lock behavior justifies most of the length; a few sentences could still be tightened.

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 mutation tool with no output schema, nested parameters, and existing safety annotations, the description covers validation, draft/revision behavior, mapping fallback, result reporting, and the key error/retry paths. An agent has enough information to invoke it correctly and interpret failures.

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 description coverage is 100%, so the baseline is 3; the description goes further by explaining the connection mapping structure, the special entryName placeholder, where other field names come from (get_collection), and what happens when connection is omitted. The remaining parameters are largely already covered by the schema, so this is meaningful added value but not a complete re-specification of all six parameters.

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 precise verb+resource: connecting a Uislice section on a page to a collection so its items render collection entries. It explicitly distinguishes this from save_section_content / save_page_content / save_partial_content, which do not change collection bindings, and explains the static-placeholder contrast.

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?

It gives a clear usage condition — use after inserting a list-style section (cards, grid, listing) that should show collection entries — and explicitly excludes save_* tools from this job. It does not mention the sibling unbind_section_from_collection as the inverse operation, nor does it state when binding should be avoided beyond the partial-section error later in the text.

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.

Bind section to collection

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources