Skip to main content
Glama
Sign In

PixelGlass

by co.pixelglass
OverviewDiscussionsAdmin

Add pages to a collection

add_collection_pages

On one site of the account, named in site. A branch of a collection in one call: pages, each with the pages under it in children, any depth the levels allow — a country with its states, each state with its spots. They go on the top level, or under the page parent_id names (get_collection gives the ids). Each page is a title, Markdown for its body (create_post's Markdown), and an optional slug, subtitle, cover and the fields its level names. A cover at an outside address is fetched into the library first, once for each address. All or nothing: one page refused makes none, and the refusal names it. Drafts unless publish is true (editors and above). Up to 200 pages a call. Answers every page made in tree order, with its id, address and preview link.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "site": "<site>",
      "collection": "<collection>",
      "pages": "<pages>"
    },
    "name": "add_collection_pages"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteYesThe site to work on, as list_sites names it
pagesYes
publishNoPublish every page now; drafts when left out
languageNoA BCP 47 tag; the parent's language, else the site's default
parent_idNoThe page the branch goes under; the top level when left out
collectionYesIts id, slug or name

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare the mutation profile (readOnly=false, destructive=false, idempotent=false, openWorld=true), so the bar is lower and the description clears it comfortably: it discloses all-or-nothing atomicity, that the refusal names the offending page, drafts-unless-publish semantics with an editor gate, a 200-page cap, and the side effect of fetching external covers into the media library once per address. These are exactly the behavioral facts annotations cannot convey.

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?

Roughly 130 words carry purpose, structure, atomicity, permissions, limits and return shape with no filler, and the scale limit and atomicity are placed where an agent will encounter them before invoking. The elliptical, clause-heavy style ('A cover at an outside address is fetched into the library first, once for each address') costs some readability but nothing is redundant.

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 6-parameter mutation tool with no output schema, the description covers everything an agent needs: what the call does, how nesting works, prerequisites (get_collection ids, editor role), failure mode (atomic rollback with named offender), scale limit (200), and what comes back (every page in tree order with id, address, preview link). No material gap remains.

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 already 83%, so the schema does most of the work, but the description adds meaning beyond it: parent_id's default to top level, publish's permission gate, the per-level interpretation of fields, and the deduplication rule for external cover addresses. It explains how parameters interact (children nesting depth limited by levels) rather than restating field descriptions.

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?

The description states a specific verb and resource — adding a branch of pages to a collection on a named site, with nested children at any depth — and gives a concrete example (country > states > spots) that separates it from flat post creation tools like create_post. The telegraphic opening fragment ('On one site of the account, named in site.') is slightly oblique, but the core action and scope are unmistakable.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: it explains that pages go at the top level or under parent_id, and points to get_collection for the ids needed, which is real routing help. However, there is no explicit when-to-use vs. create_post/write_site_page guidance, and the editor-permission note is attached to publish rather than framed as a prerequisite for the call as a whole.

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

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