FeatureOS

Update article

update_article

Destructive

Update an article. Partial update — only the fields you pass are changed.

Draft rule for description: if the article is already published (live), the new description is saved to the DRAFT only and the live version is left untouched — the result tells you it is live and that only the draft changed, and asks you to confirm. To publish the draft, run update_article again with publish=true. If the article is not yet live (draft/in_review), description updates it directly.

Confirmation: publish=true, a status change, or any other field (title, tags, privacy, ...) on a live article changes what readers see, so it needs the user's approval. Without confirm=true nothing changes and the pending change is returned.

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": {
      "article_id": "<article_id>"
    },
    "name": "update_article"
  }
}

Input Schema

Name	Required	Description
`title`	No	New title for the article (also updates the slug).
`locale`	No	Language code, e.g. 'en', 'es', 'fr'.
`status`	No	New status. To take a parked draft live, prefer publish=true over status='published'.
`confirm`	No	Required to publish, change status, or change any field other than description on a live article. Set true ONLY after the user has explicitly approved this exact change in the conversation. Without it the tool changes nothing and returns the pending change for the user to approve.
`privacy`	No	New privacy: 'public', 'unlisted', or 'private'.
`publish`	No	Set True to make a parked draft live: promotes the saved draft to the live version and publishes. Use this after a normal update reported that the edit was saved as a draft on a live article.
`tag_ids`	No	Tag IDs to attach. Replaces existing tags. Pass a JSON array of integers, e.g. [1, 2]. Do NOT pass a quoted string.
`position`	No	Display position of the article within its collection.
`seo_title`	No	Custom SEO title for the article.
`article_id`	Yes	The ID of the article to update (from list_articles).
`cover_image`	No	Cover image URL (jpeg, jpg, png, or gif; max 10 MB).
`description`	No	New body/content. Accepts HTML. See the draft rule in the tool description: on a LIVE article this is saved to the draft only.
`assignee_ids`	No	Team-member IDs to assign. Replaces existing assignees. Pass a JSON array of integers, e.g. [1, 2]. Do NOT pass a quoted string.
`collection_id`	No	Move the article to a different collection.
`seo_description`	No	Custom SEO meta description.

Output Schema

Name	Required	Description	Default
`article`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and openWorldHint=true, and the description adds the crucial behavior the annotations cannot express: what actually happens to a live article versus a draft, what gets left untouched, and that without confirm=true nothing changes and a pending change is returned instead. That is exactly the kind of 'what gets destroyed / what is gated' disclosure this 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?

Front-loaded with the core semantics, then two logically separated blocks (draft rule, confirmation). It is somewhat long and the confirmation paragraph partly duplicates the confirm param's own description, but every sentence carries decision-relevant content.

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 15-parameter mutation tool with destructive and open-world hints, the description covers the non-obvious flow that an agent would otherwise get wrong: draft parking on live articles, the second-call publish step, and the approval gate. An output schema exists, so return-value detail is correctly left out.

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 coverage is 100%, so the baseline is 3; the description still earns a bump by explaining the ordering relationship between the description field and publish=true, which the individual param docs only state in isolation. It does not add meaning for the remaining 13 params, but the schema already handles those thoroughly.

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

Purpose4/5

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

The description opens with a specific verb+resource ("Update an article") and immediately clarifies the partial-update semantics: "only the fields you pass are changed." That distinguishes it from create_article/delete_article by behavior, though it never names a sibling explicitly.

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

Usage Guidelines5/5

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

It gives explicit when-to-use rules for the two-step flow: on a live article, run update_article with description first, then run it again with publish=true; and it says to prefer publish=true over status='published' (also mirrored in the schema). The confirmation gating (confirm=true only after explicit user approval) is stated as a hard prerequisite.

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

All FeatureOS tools Inspect

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.