Skip to main content
Glama

Create a CMS collection

create_collection

Creates a collection: from blank (a required Title field) or a starter (Blog posts, Projects, Team, Products, Events, Jobs, Testimonials, FAQ, with fields and sample items), plus extra fields and page settings. On a Xodia template or Vite React site it also installs the CMS kit when missing and creates the collection page (src/pages/collections/Page.tsx on //:slug) with its route: never hand-write collection.json, item files or that page's route. Plain HTML sites get the collection only. Writes go to the branch the workspace has open as unsaved changes the user reviews and saves in Xodia, the same as the Content tab. Works on every plan within its collection and item limits (Free: 2 collections and 100 items a site); turning a folder into a Xodia collection needs a paid plan. Reference fields (up to 10 a collection) need their target collection to exist first.

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

Input Schema

NameRequiredDescriptionDefault
idNoOptional id (the folder name); default from the name
fromNo"blank" (a Title field only; add yours in fields) or a starter with its fields and sample items: blog (Blog posts), projects (Projects), team (Team), products (Products), events (Events), jobs (Jobs), testimonials (Testimonials), faq (FAQ)blank
nameYesThe collection's name, like "Blog" or "Team"
pageNoCollection page settings (same as update_collection page)
branchNoOptional branch; default the branch the workspace has open
fieldsNoFields to add after the starter's (or after Title on blank)
pluralNo
samplesNoStarters: write their sample items (default true). Use false when you add your own items next
singularNoOne item, like "Team member"
projectIdYesProject id from list_projects
urlFolderNoOptional: item pages are /<urlFolder>/<slug>; one or more folder levels ("blog", "resources/blog"); default from the starter or the id

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare it as a non-read-only, non-destructive, closed-world write. The description goes well beyond that: writes land on the open branch as unsaved changes the user reviews and saves, the CMS kit and route file are auto-installed when missing, and plan/quota limits (Free: 2 collections, 100 items; folder conversion needs paid) are stated. This is exactly the kind of consequence disclosure a mutation tool needs.

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?

Three dense sentences, front-loaded with the creation modes before side effects and limits. Nearly every clause carries information, though the middle sentence about CMS kit paths is parenthetical-heavy and could be tightened.

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 an 11-parameter mutation with nested objects and no output schema, the description covers modes, side effects, prerequisites, and quota limits thoroughly. The one omission is what the call returns (collection id, created files), which matters since there is no output schema to fall back on.

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 91%, so the baseline is 3, but the description adds real meaning: it enumerates the starter values by human name, explains that extra fields append after the starter's fields, and states a constraint absent from the schema ('Reference fields (up to 10 a collection)'). It does not cover page settings or branch override semantics beyond what the schema already says.

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 opens with a specific verb and resource ('Creates a collection') and immediately enumerates the two creation modes (blank with a required Title field, or one of eight named starters), plus the side effects on Xodia/Vite React sites. An agent can distinguish this from update_collection or create_items without opening any 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?

It gives strong when/when-not guidance: 'never hand-write collection.json, item files or that page's route', 'Plain HTML sites get the collection only', 'samples: false when you add your own items next', and the prerequisite that reference-field targets must exist first. The main gap is that it never names update_collection as the alternative for existing collections.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources