PixelGlass

Create a collection

create_collection

On one site of the account, named in site. A new collection: a tree of pages, for pages that sort into levels — surf spots by country, state, city and spot; boards by brand and model. Name its levels top first, one to 6; every level is a page of its own, so the country's page can say something about the country. The collection answers at / (made from the name when not given) and a page in it at ///. A level may name fields its pages carry — a spot's location and break — which themes and the JSON read. Fill it with add_collection_pages. Posts never go in one.

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>",
      "name": "<name>",
      "levels": "<levels>"
    },
    "name": "create_collection"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Up to 60 characters, unique without regard to case
`site`	Yes	The site to work on, as list_sites names it
`slug`	No	Its address on the site; free of every post's, page's and site page's
`fields`	No	The fields of each level's pages, by level name: {"Spot": [{"name": "location", "type": "point", "label": "Location"}, {"name": "break", "type": "choice", "label": "Break", "options": ["Beach", "Reef", "Point"]}]}. A level left out keeps its fields; [] removes them. Up to 20 a level
`levels`	Yes	The levels' names, top first: ["Country", "State", "Spot"]
`description`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A4.3/5.0

Behavior4/5

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

The annotations already declare this is a non-readonly, non-destructive, non-idempotent creation tool, so the description does not need to restate that. It adds meaningful behavior by explaining the hierarchy, that every level is its own page, the URL pattern, and that level fields are read by themes and JSON. It does not discuss permissions or the created return value, but the structural behavior is well covered.

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 information-dense and appropriately sized for a complex hierarchical creation tool. The examples and URL explanation earn their place, though the opening is slightly indirect and the whole definition is delivered as one dense paragraph rather than a tightly front-loaded statement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter nested creation tool with no output schema, the definition covers the important conceptual pieces: what a collection is, how levels work, URL generation, fields, and the follow-up tool for adding pages. The main gaps are the unexplained `description` parameter and no indication of what the creation call returns.

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 high at 83%, so the schema already carries most parameter documentation. The description adds useful meaning beyond the schema: levels are named top-first and capped at six, the slug can be generated from the name, and level fields are consumed by themes and JSON. It does not explain the `description` parameter at all, which keeps it from a higher score.

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 create action for a collection and explains that it is a tree of pages organized into levels. The examples (surf spots by country/state/city/spot, boards by brand/model) make the resource model concrete and distinguish it from posts or ordinary pages.

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 clear usage context: collections are for pages that sort into levels, and the agent should fill one with add_collection_pages. It also explicitly excludes posts. It does not compare against create_site_page or update_collection, but the intended use case is still easy to infer.

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

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

Resources

Need Help?