Skip to main content
Glama
Leaderxin

csdn-mcp

by Leaderxin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

更新文章

update_article

Updates specific fields of an existing article while preserving unchanged fields. For published articles, markdown edits only apply to a draft copy requiring manual republish.

Instructions

更新已有文章：只传要改的字段，未传的字段保持原值（saveArticle 会整条重写，所以未传的字段由本工具从当前记录合并回来）。已公开发布文章的线上正文（markdown）不会被接口更新：正文修改只写入草稿副本，需要在编辑器 UI 里重新发布才生效，工具会在返回里明确说明。不传 mode 时保持文章当前可见性（不会把已发布的文章退回草稿）；想发布一篇草稿请显式传 mode=publish。不要用它校正正文之外的东西（那要重新发布），也不要传空字段试图"清空"某个值——省略即保持原值。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo
tagsNo
titleNo
markdownNo
read_typeNo
article_idYes
categoriesNo
cover_imageNo
descriptionNo
scheduled_atNo定时发布时间（ISO 8601，需配合 mode=publish）。实验特性：线上单位未验证，见 docs/API-NOTES.md
upload_local_imagesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.0.4
    • addedInput schema / properties / read_type
      Added value: +{
+  "enum": [
+    "public",
+    "private"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / scheduled_at
      Added value: +{
+  "description": "定时发布时间（ISO 8601，需配合 mode=publish）。实验特性：线上单位未验证，见 docs/API-NOTES.md",
+  "minLength": 1,
+  "type": "string"
+}
    • addedInput schema / properties / upload_local_images
      Added value: +{
+  "type": "boolean"
+}
  2. First observedv1.0.1

TDQS

A3.8/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 well. It discloses the non-obvious behavior that published live markdown is not updated by the API, that changes only go to a draft copy, that a UI republish is required, and that the return explicitly states this. It also explains the merge-based partial update, mode default behavior, and the rule that omitted fields preserve original values.

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 front-loaded with the core update behavior and then proceeds through important warnings in a logical order. It is somewhat dense and includes a modest amount of repetition around republishing, but every major sentence adds relevant behavioral information for a complex mutation tool.

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

Completeness3/5

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

The description covers the most important behavioral traps: partial merge semantics, draft-only markdown changes, publish mode behavior, and omission versus clearing values. However, for an 11-parameter tool with no annotations and very low schema coverage, it leaves parameter-level guidance for most fields unstated and does not mention authentication or other operational constraints.

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

Parameters2/5

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

Schema description coverage is only 9% for 11 parameters, so the description must compensate but largely does not. It adds important semantics for mode (omission preserves visibility, publish explicitly publishes a draft) and a general omission-means-keep-original rule, but it says nothing about article_id, tags, title, read_type, categories, cover_image, description, scheduled_at, or upload_local_images.

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 states a specific verb and resource: '更新已有文章' and explains that it performs a partial update that merges omitted fields back from the current record. It clearly distinguishes itself from saveArticle and from republishing via the editor UI. However, it does not mention the sibling publish_article tool, and in fact tells the agent to use mode=publish here, leaving some sibling differentiation ambiguous.

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 usage context: pass only fields to change, omitted fields stay unchanged, mode omission preserves visibility, and mode=publish is needed for drafts. It also excludes misuse cases such as trying to correct non-body content or clear values with empty strings. But it does not explicitly say when to use this tool versus publish_article, which is a relevant sibling.

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