Skip to main content
Glama

Update article

cms_update_article
DestructiveIdempotent

Update article. Guidance: Update one CMS article by article id. | context: id

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": {
      "id": "<id>"
    },
    "name": "cms_update_article"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesArticle id returned by cms_list_articles.
dateNoOmit to keep the current editorial date; send RFC 3339 to replace it.
metaNoOptional SEO payload with title and description.
slugNoOmit to keep the current slug; send to replace it.
titleNoOmit to keep the current headline; send to replace it.
authorNoOmit to keep the current byline; send to replace it.
leadinNoOmit to keep the current summary (Summary field of the back-office Info panel, also called deck); send to replace it. Plain text: HTML tags are removed, and so is the text after a bare '<' (write 'under 12', not '<12'). The `summary` field returned by read tools is a derived excerpt: it cannot be written and may not show this value right away, so check `leadin` instead.
pinnedNoOmit to keep the current pinning state; send true or false to replace it.
statusNoOmit to keep the current publication state. Do not send scheduled.
accessTierNoReplacement paywall tier. 'premium' locks the article behind an in-app purchase; 'free' leaves it open. Applies only to apps that sell in-app purchases.
categoriesNoOmit to keep placement. Send non-empty category ids to replace placement.
publishedDateNoFuture ISO datetime for deferred publication. Requires status='stock' when provided.
commentsEnabledNoOmit to keep the current comments setting; send true or false to replace it.
maxFreeParagraphsNoNumber of body paragraphs shown as a free preview before purchase, 0 to 5. Applies only to premium in-app-purchase articles.
publicationEndDateNoFuture ISO datetime for scheduled unpublication. Send an empty string to clear an existing scheduled unpublication.
displaySummaryInListNoWhether the article summary is shown in list views. Writable only when maxFreeParagraphs is 0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. First observed

TDQS

C2.5/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond that: it does not disclose the partial-update ('omit to keep') contract, the interaction rules between fields, or any side effects of a destructive mutation. Given 16 parameters with non-trivial coupling, this is a substantial gap the description leaves unaddressed.

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

Conciseness3/5

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

It is short and front-loaded, but the two sentences are redundant ('Update article.' followed by 'Update one CMS article by article id') and the trailing '| context: id' fragment is machine-artifact noise rather than useful prose. Nothing is wasted on length, but little is earned either.

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

Completeness2/5

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

For a mutation tool with 16 parameters, a nested meta object, conditional field constraints, destructive semantics, and no output schema, a two-sentence tautological description is inadequate. The critical behavioral fact — that unspecified fields are preserved while specified fields are replaced — exists only inside the schema and is never surfaced in the description.

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 100%, and the schema itself carries rich, specific semantics including 'omit to keep' defaults, enum restrictions, and conditional constraints like displaySummaryInList requiring maxFreeParagraphs=0. The description adds no parameter meaning beyond 'by article id', so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The definition does name a verb and resource ('Update one CMS article'), and 'by article id' clarifies the addressing key. However, it is essentially a restatement of the tool name and title, with no differentiation from near-identical siblings such as cms_update_article_paragraph or cms_update_event. Purpose is inferable but not sharpened.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus the many sibling update tools (article paragraphs, events, maps, photos) or when not to. The only usage information is 'Update one CMS article by article id', which is already implied by the name and required parameter. An agent must infer routing from names alone.

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.