Skip to main content
Glama
Sign In

Pixelesq

by com.pixelesq
OverviewDiscussionsAdmin

Update collection schema

update_collection_schema
Destructive

Define or update the field schema of a collection. Pass the FULL ordered list of fields you want. This is a wholesale replace at the schema level (it is not a JSON Merge Patch).

expectedUpdatedAt is required: the updatedAt from get_collection (or from create_collection or the previous update_collection_schema). The save is refused if the collection changed since, for example a field a teammate just added in the dashboard; then call get_collection again, merge your fields into the current list, and retry.

Each field has:

  • name: string identifier (used as the key in entry content)

  • label: human-readable label

  • type: one of name, slug, text, html, number, checkbox (a yes/no value; boolean is saved as checkbox), date, image, media, icon, option, reference, related. The legacy select, textarea, email and url types are accepted so a collection that already has them can be saved back unchanged; use option and text for new fields.

  • required: optional boolean

  • helpText: optional help string

  • options: for option type, a comma-separated string of choices; for reference type, the target collection id; otherwise empty

  • list: optional boolean (allow array of values)

  • to: alternative for reference target id

  • config: optional flat object of type-specific settings. For date fields: { format, time, timeFormat } where format is one of "MMM D, YYYY" (default), "MMMM D, YYYY", "D MMM YYYY", "D MMMM YYYY", "MMM D", "MMMM D", "ddd, MMM D, YYYY", "dddd, MMMM D, YYYY", "MM/DD/YYYY", "DD/MM/YYYY", "DD.MM.YYYY", "YYYY-MM-DD", "MMM YYYY", "MMMM YYYY", "YYYY"; time is a boolean (false = calendar date only, true = date with time; this decides the value shape entries store); timeFormat is "12h" or "24h". A field sent without a config key keeps its stored config; config: null clears it. Other types take no config.

An icon field holds one icon per entry: a library icon or the site's own uploaded SVG or PNG. Use it for the small symbol beside a service, feature or step; photos and logos stay media.

Every collection has built-in Name and Slug fields (type name and type slug); they are required, never list, and their values are not part of content: the entry's name and URL slug live on the entry itself and change through update_entry. Keep both in the list when updating a collection that has them (a built-in cannot be removed or renamed); a collection holds at most one of each. A legacy collection whose name or slug is a plain text field can convert it by changing that field's type to the built-in one. Reserved field names: _raw, _icon, _pagination, _filters.

The schema has no draft: live listings and entry pages read it as soon as it is saved. A field left out of the list is removed from the schema, and changing a date field's config, or removing or retyping a date field, republishes every published entry page of the collection.

Input Schema

NameRequiredDescriptionDefault
projectIdYesThe project ID
fieldSchemaYesFull ordered list of fields. Replaces the collection's existing fieldSchema.
collectionIdYesThe collection ID
expectedUpdatedAtYesupdatedAt as read from get_collection (or returned by create_collection or the last update_collection_schema); the save is refused if the collection changed since

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / expectedUpdatedAt
      Added value: +{
+  "description": "updatedAt as read from get_collection (or returned by create_collection or the last update_collection_schema); the save is refused if the collection changed since",
+  "minLength": 1,
+  "type": "string"
+}
    • changedInput schema / properties / fieldSchema / items / properties / type / enum
      Previous value: -[
-  "name",
-  "slug",
-  "text",
-  "html",
-  "number",
-  "boolean",
-  "date",
-  "image",
-  "option",
-  "reference",
-  "media",
-  "icon"
-]New value: +[
+  "name",
+  "slug",
+  "text",
+  "html",
+  "number",
+  "checkbox",
+  "boolean",
+  "date",
+  "image",
+  "media",
+  "icon",
+  "option",
+  "reference",
+  "related",
+  "select",
+  "textarea",
+  "email",
+  "url"
+]
    • changedInput schema / required
      Previous value: -[
-  "projectId",
-  "collectionId",
-  "fieldSchema"
-]New value: +[
+  "projectId",
+  "collectionId",
+  "expectedUpdatedAt",
+  "fieldSchema"
+]
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already flag destructive/write behavior, but the description adds substantial context beyond them: fields left out are removed, the schema has no draft, removing/retyping date fields republishes published entry pages, and saves are optimistically locked on expectedUpdatedAt. This is exactly the kind of higher-tier behavioral disclosure expected.

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?

Long but front-loaded with the operation and the replace semantics, then structured as a field-by-field bullet list. Dense and mostly waste-free, though a few details (icon field guidance, legacy type notes) could be trimmed for a tighter read.

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 complex destructive mutation with 4 required params and no output schema, the description covers edge cases a caller needs: built-in Name/Slug handling, legacy type acceptance, reserved names, config null semantics, and republish side effects. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (baseline 3), yet the description adds real value: it enumerates every field property with meaning, explains config semantics for date fields (format enum, time boolean effects on value shape, null-clears behavior), option/reference semantics, and reserved field names. Well beyond the schema.

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?

States a specific verb (define/update) and resource (field schema of a collection), and immediately clarifies it is a wholesale replace rather than a merge patch. This distinguishes it clearly from sibling tools like update_form_schema and update_entry.

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?

Gives explicit procedural guidance: pass the full ordered list, expectedUpdatedAt is required and where to get it, and what to do on conflict (re-fetch, merge, retry). No explicit when-not-to-use exclusions vs create_collection, but the usage flow is unambiguous.

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

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