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

无 annotations，因此描述承担了全部行为披露责任，且做得非常充分。它说明了设置后立即生效、不需要重启进程、本地结构校验不发请求、不判断 Cookie 是否被 CSDN 接受、失效 Cookie 何时暴露等关键行为特征。

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?

四句话没有冗余信息，主操作、使用条件、替代工具、行为限制各占一句，结构清晰且重要信息前置。没有浪费任何文字。

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?

对只有一个参数、无输出 schema 的简单设置型工具，描述覆盖了使用方法、校验规则、使用时机、替代工具和已知局限。agent 据此可以正确决定何时调用以及如何构造参数。

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 覆盖率为 0%，且只有一个 cookie 字符串参数，描述补充了关键语义：必须是'整段 Cookie 头'，且缺少 UserToken 或 UserName 会被本地校验拒绝。这超越了 schema 本身提供的信息，虽未给出示例格式，但对单参数工具已足够。

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?

描述以明确的动词和资源开头（'在运行期设置/更新 CSDN Cookie'），并说明作用范围是整段 Cookie 头。它还通过指向 auth_status 来区分自己，agent 无需打开 schema 即可理解该工具与状态查询工具的不同。

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?

明确说明使用时机：'仅在首次配置或 Cookie 失效后才需要调用'，并直接给出替代工具：'只想知道当前状态请用 auth_status（不发网络请求）'。这既说明了何时使用，也说明了何时不使用时改用其他工具。

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

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

With no annotations, the description carries the full burden and does so thoroughly: it states that no network request is sent, that it does not determine whether the Cookie is accepted by CSDN, and that it does not know article status. This prevents common misunderstandings about the tool's scope.

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 two sentences with no filler. It front-loads the tool's purpose, then adds limitations and usage guidance. Every sentence earns its place.

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 zero-parameter diagnostic tool, the description covers purpose, limitations, and routing to an alternative. It lacks an explicit return format example, but the reported fields are enumerated clearly, making the tool usable without additional context.

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?

The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific semantics, but none are needed; the reported items (configuration, structure, account name) clarify what the tool inspects.

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 states a specific verb and resource: it reports whether the Cookie is configured, whether the structure is valid, and the account name. It also explicitly distinguishes itself from related tools by declaring it does not judge acceptance or know article status.

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 gives clear when-to-use guidance and names the alternative: use auth_login when replacing a Cookie, and do not use this tool to troubleshoot invalidation because that requires network calls. This is explicit and actionable.

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

Does 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.

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

With no annotations, the description carries the full burden. It discloses that it reads drafts, returns the full record, and explains the effect of include_content. It does not explicitly state it is read-only, but this is implied. It does not mention error handling or authentication, but for a read tool these are minor omissions given the provided context.

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?

Three sentences, front-loaded with purpose, then parameter guidance, then alternatives. No fluff; every sentence contributes to correct usage.

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?

The description covers purpose, parameter behavior, and alternatives. It lacks details on error cases and authentication, but these are not critical for a simple read operation. With no output schema, it does not need to describe return structure.

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 coverage is 0%, so the description must compensate. It explicitly explains include_content's purpose (metadata-only when false) and implies article_id's usage via '按 id 读取'. Both parameters are well clarified beyond the raw schema.

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 it reads a complete article record by id, specifies that drafts are included, and identifies it as the authoritative source for status codes. It distinguishes itself from siblings by naming list_articles and verify_article explicitly.

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?

It provides explicit when-to-use guidance: use list_articles for browsing published articles, verify_article for write verification, and advises setting include_content=false for long articles to avoid context overflow. This fully covers alternatives and conditional usage.

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

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

With no annotations, the description discloses critical behavior: public vs cookie-required backend access, server-side page-size enforcement, actual pageSize in response, draft counts behavior, and the limitation that 'not seen' does not mean 'not published'. This fully compensates for missing annotations.

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?

Dense but every clause adds operational value: scope defaults, cookie requirements, draft visibility, server page-size behavior, and exclusion of publish verification. Information is front-loaded and no filler exists.

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?

Given no output schema, the description still explains key response aspects (pageSize actual value, counts categories) and covers prerequisites, alternatives, and limitations. An agent has enough context to invoke and interpret the tool correctly.

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%, so the description must carry parameter meaning. It thoroughly explains scope semantics and page_size being potentially ignored, but does not explicitly describe the page parameter, though its pagination meaning is standard and schema-enforced.

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?

Description starts with a specific '列出账号的文章' (lists account articles) and clearly separates the two scopes: published via public API and all via author backend. This distinguishes it from siblings like get_article and verify_article.

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?

Explicitly states when to use scope='all' (to see drafts) and why it is the only way to answer 'what drafts do I have', noting get_article requires an ID. It also explicitly says not to use it to verify publish success and directs to verify_article instead.

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

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

With no annotations, the description carries the full burden and handles it well: it discloses the fallback to a built-in list with source=builtin, warns that builtin does not reflect the account's real categories, states that no category id is returned, and notes the Cookie requirement. This is strong behavioral disclosure.

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?

Three sentences, each with a distinct job: purpose, fallback caveat, and result/parameter constraints. The most important purpose is front-loaded, and every sentence earns its place.

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?

The description is complete for a zero-parameter read tool: it explains what the return contains (category names, no ids), how to detect and handle degraded output (source=builtin), and when it should be consulted. No output schema exists, but the description provides enough operational context.

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?

With zero schema parameters, the baseline is already 4, and the description adds extra clarity by stating that no parameters are required beyond Cookie. It confirms the input surface for the agent in plain terms rather than leaving it inferable from an empty schema.

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 opens with a specific verb ('列出') and resource ('文章分类'), and states exactly what the result is for: the categories field in publish_article / update_article. This makes its role unambiguous and distinguishable from sibling tools like list_tags.

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?

It explicitly ties the tool to preparing publish_article / update_article requests and tells the agent how to handle the degraded builtin result (verify API availability or check the CSDN editor). It does not explicitly name alternatives or exclusion conditions, so it stops short of 5.

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

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

With no annotations provided, the description fully covers behavioral aspects: it may degrade to a builtin list (source=builtin), does not create tags, does not validate existence, and misspelled tags will appear as-is. This is more thorough than typical descriptions and covers critical side effects and data reliability.

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 efficient and well-structured: purpose first, then fallback behavior, then key caveats. Every sentence adds value without redundancy, and it is appropriately sized for the tool's simplicity.

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 zero-parameter tool without an output schema, the description is remarkably complete. It covers purpose, usage context, fallback, and behavioral caveats. The only minor omission is the exact return structure, but the mention of source=builtin and the clear intent make it sufficient.

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?

The tool has zero parameters, so the baseline is 4. The description correctly omits parameter details, and there is no schema coverage concern. It adds no misleading information about parameters.

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?

States a specific verb (列出), resource (账号常用/推荐的标签), and explicitly connects it to the publish_article tags field. It distinguishes itself from sibling tools by being the only tag-related tool, and clearly indicates its purpose of providing candidates.

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?

Provides clear context on when to use this tool (to select tags for publish_article, with a max of 5) and describes the fallback behavior when the interface is unavailable. However, it doesn't explicitly state alternatives or when not to use it, though no sibling tag tool exists to contrast with.

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

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

With no annotations, the description carries full burden and discloses critical behaviors: default mode is draft, publish is irreversible and cannot revert to draft, published articles can only be deleted and recreated, markdown is rendered to HTML while retaining source, tags are capped at 5, and description is auto-generated when omitted. This goes well beyond basic 'create' semantics.

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 dense and information-rich, with the core purpose front-loaded and the most important warning about irreversibility placed early. Every sentence contributes either parameter semantics, behavioral warnings, or usage exclusions; there is no filler or repetition.

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?

Given no annotations, no output schema, and eight parameters, the description covers the most safety-critical aspects and common usage pitfalls thoroughly. It omits return-value behavior and a few parameter details, but the description provides sufficient context for an agent to invoke the tool correctly in the main workflows.

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%, so the description must compensate. It adds meaning for mode (default draft, publish semantics), markdown (source stored and rendered), tags (max 5), and description (auto-generation). However, it does not explain verify, categories, or cover_image, leaving some parameters only minimally understood through the schema.

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 states a specific verb and resource: creating a new article and saving it to CSDN. It also explicitly distinguishes itself from updating existing articles ('不要用它更新已有文章（那会新建一篇）'), which differentiates it from the sibling update_article.

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 gives explicit when-to-use guidance: keep the default draft mode when review is needed. It also provides clear when-not-to-use exclusions: do not use it to update existing articles and do not pass mode=publish as a test, because publishing is irreversible.

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

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

With no annotations provided, the description carries the full burden and handles it very well. It discloses that the underlying operation rewrites the whole record and merges omitted fields back, that published markdown is not updated by the API and only gets written to a draft copy, that the tool will state this in the return, and that omitted fields are preserved rather than cleared. These are exactly the non-obvious behaviors an agent needs to know before calling.

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 front-loaded with a strong one-sentence summary of the partial-update model, followed by the most important warning in bold. It is dense but every sentence adds behavioral or usage value. The implementation note about saveArticle rewriting the whole record is explanatory rather than redundant, though the paragraph is slightly long and could be broken into tighter points.

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 mutation tool with no annotations and no output schema, the description covers the major risks: merge behavior, the live-markdown exception, mode defaults, and the empty-field trap. It also mentions that the return will explicitly state the published body outcome. It does not mention authentication/permission requirements or explicitly clarify what mode=draft does to a published article, which keeps it just short of complete.

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%, so the description must add meaning beyond field names and types. It does so by explaining the update contract across all parameters: only pass fields to change, omitted fields keep their original value, empty fields do not clear values, and mode has special default and publish-draft semantics. It does not provide per-field business meaning for title, tags, categories, cover_image, or description, but their names and schema constraints make them fairly self-explanatory.

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 opens with '更新已有文章' (update existing article), naming a clear verb and resource, then immediately defines partial-update semantics: only changed fields need to be passed and unpassed fields retain their current values. It also calls out the surprising markdown behavior for published articles, which differentiates this tool from a simple 'edit article' sibling. The scope is unambiguous.

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 gives explicit when-not guidance: do not pass empty fields to clear values, do not use this tool to correct live body content, and explicitly says omitting mode preserves current visibility while passing mode=publish publishes a draft. It does not name alternative sibling tools such as publish_article or get_article directly, but the behavioral instructions are specific enough for an agent to choose correctly in most cases.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses the return value (public URL), the anti-leech behavior requiring the absolute URL, and the non-interchangeability of channels. It also warns about the key not being a public address. However, it omits auth requirements and error handling, which are relevant for a tool that uploads data, though the sibling auth tools suggest authentication is expected.

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 compact and front-loaded with the core purpose and output. It delivers essential usage instructions and warnings in a few sentences without redundancy. Every sentence adds value, covering purpose, channel selection, and exclusions.

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?

Given the tool's simplicity (two parameters, no output schema), the description covers the main behavioral expectations: what it does, what it returns, and what to avoid. It lacks explicit auth prerequisites and response format details, but these are partially implied by sibling tools and the clear output statement. Overall, it is sufficiently complete for an agent to invoke correctly in most scenarios.

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 coverage is 0%, so the description must compensate. It explains 'kind' (cover vs body) and implies 'path' refers to the local image file, but does not specify path format (absolute/relative), file size limits, or other constraints. While it adds meaning beyond the enum, the path parameter remains underspecified, leaving the agent to infer from the tool name and context.

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 tool's action (upload local image to CSDN image hosting) and its primary output (public URL). It also differentiates from sibling tools by specifying the kind-based channel selection (cover vs body), which is unique among the listed siblings that are all article-related.

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?

Provides explicit usage guidance: instructs to use the returned absolute URL in article content due to anti-leech, explicitly states not to use it for non-image files, and warns against using the returned key as an image address. It also clarifies that cover and body channels are not interchangeable, giving clear conditions for when to use which.

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

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 it well. It discloses that the tool is read-only, modifies nothing, requires two signals (interface status and HTTP code) to avoid misjudgments, and notes the failure modes of relying on only one signal. This is rich behavioral context beyond the bare tool name and schema.

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 compact and information-dense: three sentences cover purpose, verification logic, read-only nature, and usage trade-offs. Every sentence earns its place, and the core purpose is front-loaded.

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?

Given no annotations, no output schema, and only two parameters, the description provides a strong operating picture: what it checks, why both signals matter, what happens when expected is omitted, and when it is unnecessary. The main omission is the exact return/output format, but an agent can likely infer the result from the verification purpose.

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%, so the description must compensate. It does clarify that 'expected' is optional and that when omitted the tool infers based on current state, but it does not fully explain the semantic meaning of 'expected' (e.g., expected status used for comparison). 'article_id' is trivially inferable as the article identifier, but the description adds little parameter-specific detail.

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 states a specific verb ('回查'/verify), a clear resource (a single article), and a concrete method (CSDN interface status + public page HTTP code). It also differentiates itself from sibling tools by explaining that publish_article and update_article already perform self-checks, so this tool is supplemental rather than required.

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?

It explicitly explains when not to use the tool: publish_article and update_article already default to self-checking, and repeated verification only wastes two requests. It also identifies the alternatives by name and clarifies the trade-off, giving an agent clear routing guidance.

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