list_categoriesLists category names for use in publish_article or update_article. Falls back to a built-in list (source=builtin) when CSDN API is unavailable, so verify real categories via CSDN console.
列出可用于 publish_article / update_article 的 categories 字段的分类名。CSDN 接口不可用时会降级返回内置列表（source=builtin）而不是报错，所以拿到 builtin 时要知道那不是账号的真实分类：先确认接口可用，或直接在 CSDN 创作中心里核对分类名。它不返回分类 id，也不需要 Cookie 之外的任何参数。
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.0.1Does 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.