Skip to main content
Glama
cmssy-io

@cmssy/mcp-server

Official
by cmssy-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

update_block_content

Update a block's content on a page. Default merge; replace mode overwrites fully. Works for content and layout blocks.

Instructions

Update a specific block's content on a page. Defaults to merging with existing content; pass mode: 'replace' to overwrite the block's whole content. Works for content and layout blocks. Only call after the user confirms. If the result includes blockWarnings, the saved content violates the workspace block manifest (unknown block type, unknown field or wrong value shape) - correct the content and save again.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo'merge' (default) shallow-merges the given content per language into what's already there. 'replace' sets the block's entire content to exactly what you provide, dropping any language or field you don't include - use it to fix legacy/malformed content (e.g. a repeater stored as an object instead of an array).
pageIdNoPage id
targetNo'draft' (default) edits the shared page draft. 'devDraft' edits YOUR per-user dev draft overlay (owned by the token's user; starts from the current page blocks when no overlay exists) - for block types not deployed yet; promote with promote_dev_draft.
blockIdNoBlock instance id (UUID) to update
contentNoContent keyed by language, e.g. { en: { title: 'New Title' } }. In 'merge' mode only the given fields change; in 'replace' mode this becomes the block's entire content. A relation field stores record id(s) from list_records - a single id string (hasOne) or an array of id strings (hasMany); the delivery API resolves them to records at render time. A relation field with mode 'all' stores no value.
settingsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.73.1

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so strongly. It discloses the destructive nature of 'replace', the merge default, supported block types, and the meaning of blockWarnings including how to recover. This is exceptional behavioral detail for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with the core purpose, followed by mode behavior, scope, a user-confirmation guard, and an error-recovery note. Every sentence earns its place with no wasted text.

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?

The description covers operation semantics, destructive behavior, supported block types, prerequisite user confirmation, and a specific error condition with corrective action. It lacks an explicit description of the full return payload, and with no output schema that would add completeness, but the six parameters are well covered by the schema.

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

Parameters3/5

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

Schema description coverage is 83%, and the schema already documents mode, target, content, and relation semantics in detail. The description repeats the merge/replace default but adds little new parameter-level meaning, so the baseline of 3 is appropriate.

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 verb and resource: 'Update a specific block's content on a page.' It also clarifies scope ('works for content and layout blocks') and distinguishes the operation from page-level or block-add/remove tools. The merge/replace distinction further pins down what the tool does.

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 behavioral guidance: default is merge, pass mode 'replace' to overwrite, and it should only be called after user confirmation. It does not explicitly name alternatives such as patch_block_content or state when not to use this tool, so it stops short of a 5.

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