get_articleRetrieve an article's full record by ID, including drafts, to check its exact status. Use include_content=false to fetch metadata only and avoid large payloads.
按 id 读取一篇文章的完整记录（草稿也能读到），这是确认 status 原始状态码、判断草稿/审核/发布的权威口径。文章很长时传 include_content=false，只取元数据、不返回正文，避免把上下文挤爆。想浏览已发布文章列表用 list_articles；想验证一次写入是否真的生效用 verify_article。
| Name | Required | Description | Default |
|---|---|---|---|
| article_id | Yes | ||
| include_content | No |
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. 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.