auth_statusVerify local CSDN cookie configuration and structure, and retrieve account name without network calls. Does not confirm server-side acceptance.
报告 Cookie 是否已配置、结构是否有效以及账号名，不发任何网络请求。它不判断 Cookie 是否被 CSDN 接受（那要联网），也不知道文章状态。需要更换 Cookie 时用 auth_login，不要靠反复调用本工具排查失效——失效只有联网调用才看得出来。
| 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 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.