Skip to main content
Glama
cmssy-io

@cmssy/mcp-server

Official
by cmssy-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

update_model

Update a data model by id or slug, changing its fields, labels, validation, unique constraints, product settings, or delivery access after the user agrees.

Instructions

Update a data model by id or slug: name, slug, description, icon, color, displayField, defaultSort, statusField, fields, product capability config, uniqueFields (replaces the whole list; refused while records already share a value), or deliveryAccess ("public" lets the user's app read the model through the delivery API; "none" is admin only). fields is a PATCH - listed fields are added or replaced by key, unlisted fields stay untouched; use removeFields to delete fields. product is also a PATCH of the commerce capability config (enabled, priceField, skuField, inventoryField, variantAxes) - omitted keys keep their stored values. Only call AFTER the user explicitly agreed to the change.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
iconNo
nameNo
slugNo
colorNo
fieldsNoFields to ADD or UPDATE, matched by key. A listed key replaces that field's whole definition; fields not listed are kept untouched. To remove a field use removeFields.
productNoProduct capability config PATCH: omitted keys keep their stored values (defaults on first enable: skuField 'sku', priceField 'price', inventoryField 'inventory', variantAxes []). E.g. {variantAxes: []} clears the axes without touching anything else.
idOrSlugNoThe model's id or slug (from list_models)
defaultSortNo
descriptionNo
statusFieldNo
displayFieldNo
removeFieldsNoKeys of existing fields to REMOVE. Removing a field abandons its data on existing records - only pass keys the user explicitly asked to remove.
uniqueFieldsNoKeys of top-level text, email, url, phone or number fields whose value no two records may share (not translatable fields, not the product price/stock fields). Replaces the whole list; [] removes every constraint. Refused while existing records already share a value - the error lists them.
deliveryAccessNoWho can read this model through the delivery API: "public" (any app with the workspace endpoint - required for a content API), "members" (signed-in site members only), "none" (admin only, the default).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.73.1

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries full burden, and it delivers: it discloses that uniqueFields replaces the whole list and is refused on conflicts, fields and product are PATCH operations, omitted keys are preserved, and removeFields is the way to delete fields. These are non-obvious behavioral traits that an agent needs to avoid destructive or rejected calls.

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 long but proportionate to a 14-parameter, deeply nested update tool. It front-loads the action and property list, then adds necessary PATCH and safety semantics; there is little filler, though the dense parentheticals could be structured more cleanly.

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 complex mutation tool with no annotations and no output schema, the description covers the critical invocation semantics: patch behavior, destructive removeFields, unique constraint conflicts, access levels, and the user-consent precondition. It does not explain return values or the formats of a few simple fields, but nothing essential for safe invocation is missing.

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 only 43%, so the prose compensates meaningfully for the complex parameters: fields PATCH behavior, product PATCH semantics, uniqueFields replacement and refusal, removeFields usage, and deliveryAccess access levels. A few simpler parameters like icon, color, and statusField are listed but not enriched, though the schema supplies partial structure for them.

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 opening phrase 'Update a data model by id or slug' names the verb and resource precisely, immediately separating it from record-level tools like update_record. The long property list leaves no doubt that this operates on model definitions, not individual records.

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?

The description gives strong when-to-call guidance with 'Only call AFTER the user explicitly agreed to the change' and explains internal decision rules like 'use removeFields to delete fields' and PATCH semantics. It does not explicitly route away from siblings such as create_model or update_record, but the context is clear enough for correct selection.

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

Deploy Server

Other Tools