delete_articleRemove a published CSDN article by ID. By default it moves to the recycle bin for recovery; set permanent=true only to permanently erase it.
删除一篇文章，默认进回收站（permanent=false，可在创作中心的回收站里恢复）。只有确认文章永远不该存在时才传 permanent=true——那是彻底删除，无法恢复。不要用它清理草稿以外的临时状态，也不要因为"想改标题"而删除重建：元数据直接改 update_article 就行，只有误发布的文章才必须走"删除后重建"这条路。
| Name | Required | Description | Default |
|---|---|---|---|
| permanent | No | ||
| article_id | Yes |
Changes observed during successful MCP inspections.
v1.0.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the default recycle-bin behavior, recoverability, and the irreversibility of permanent=true. It also warns against misuse, which is essential for a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of three dense, purposeful sentences. It front-loads the default behavior, then covers the irreversible case, and finally gives exclusions and alternatives. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter delete operation with no annotations and no output schema, the description covers destructive behavior, parameter semantics, and alternatives comprehensively. It provides everything an agent needs to decide whether and how to call it correctly. Return-value details are not essential for understanding this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates well for the permanent parameter by explaining both values and their consequences. article_id is not explicitly described, but its meaning is obvious from the tool name and the phrase 'delete an article.' This is a minor gap rather than a significant deficiency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: deleting an article, with a default soft-delete behavior and an optional permanent deletion mode. It explicitly distinguishes itself from update_article by explaining that title/metadata changes should not be handled by deleting and recreating. This is a specific verb+resource description with clear sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use guidance. It says permanent=true should only be used when the article should never exist, warns against using the tool for temporary states, and routes title changes to update_article. It also identifies the one legitimate delete-and-recreate scenario: mistakenly published articles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.