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

描述披露了高风险、确认短语不能验证真人身份、模型也可调用、以及不会发布内容等关键行为特征。这些信息远超 annotations 中仅有的 readOnlyHint/destructiveHint 标记，且与 readOnlyHint=false 一致，未发现矛盾。

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?

对于高风险状态变更工具，描述覆盖了调用前提、非人验证警示和不下游发布的关键边界，已具备足够的操作约束。但在无 output schema 的情况下，未提及批准后的后续状态、reviewerNote 的用途或返回行为，存在轻微缺口。

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?

描述补充了 expectedContentHash 需要是'当前'值、confirmation 是固定确认短语，这两个参数因此获得额外语义。但 draftId 和 reviewerNote 在描述中没有说明；鉴于 schema_description_coverage=0%，描述只承担了部分参数的解释责任，其余依赖 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?

描述使用具体动词'把 in_review 草稿标为 approved'，明确指出资源和操作。同时声明'本工具不会发布到小红书'，与发布类兄弟工具明确区分，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?

给出了明确前置条件（需提供当前 contentHash 与固定确认短语），并强调不会发布到小红书，排除了对发布功能的期望。但未直接点出'发布请使用 create_publish_package'等替代工具，也未说明与其他状态流转工具的先后顺序，仍有少量推断空间。

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?

Annotations already flag destructiveHint=true and readOnlyHint=false. The description adds valuable behavioral context: it writes an audit record, does not access Xiaohongshu, and does not delete historical records. This meaningfully clarifies the nature and side effects of the destructive operation beyond what the annotations convey.

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 short sentences with no filler. The primary action is front-loaded, followed by the most important constraint and side-effect clarifications. 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 simple two-parameter mutation with no output schema, the description covers the essential constraints (unpublished only), side effects (audit, no deletion), and external behavior (no Xiaohongshu access). Minor gaps such as idempotency or failure behavior are not critical given the tool's low complexity and protected safety annotations.

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 for undocumented parameters. It never explains that 'reason' is a required free-text justification or how it relates to the audit entry. Only draftId can be loosely inferred from the phrase 'unpublished draft', leaving reason's semantics entirely underexplained.

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: mark an unpublished draft as cancelled and write an audit entry. It also clearly differentiates itself from sibling operations by noting it cannot cancel published content and does not access Xiaohongshu or delete history, making its scope 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 provides a clear boundary: only unpublished drafts can be cancelled, and published content is excluded. However, it does not explicitly name alternatives such as update_draft or approve_draft, nor does it give direct guidance on when to prefer this tool over them.

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?

The description goes beyond the readOnlyHint annotation by specifying deterministic local behavior, reading file bytes into contentHash, and failing on missing or unreadable asset paths rather than fabricating hashes (缺失或不读则失败并拒绝伪造哈希). This is valuable operational detail that the annotation 'readOnlyHint=true' alone does not convey. No contradiction with the read-only annotation.

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 three sentences, with the core purpose front-loaded in the first sentence. The second sentence adds essential failure semantics, and the third provides a necessary usage caveat. No redundant filler.

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 read-only pre-check tool with no output schema, the description explains purpose, operational constraints (deterministic, local, hash), and caveats about manual review. It does not describe the return value format or how check results should be interpreted, which is a gap given no output schema exists. The most critical behavior is covered, but the output semantics remain unclear.

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 carries the burden of explaining parameters. It names all four categories (title, body, topics, assetPaths) and elaborates on assetPaths behavior (reading file bytes, failing on missing). However, it does not clarify optionality, constraints, or the exact role of topics beyond being subject to checking.

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 action: 'perform local deterministic pre-check on title, body, topics, and assets' (对标题、正文、话题和素材做本地确定性预检). It clearly identifies the resource (Xiaohongshu content draft) and differentiates from sibling tools by emphasizing 'pre-check' rather than submission, approval, or publishing. The added hash behavior further clarifies its role.

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 implies a pre-publication context and explicitly cautions that 'rules are tips, not legal advice' and that 'manual review of current platform rules is still required before publishing' (发布前仍须人工复核平台现行规则). This tells an agent when the result is not authoritative. However, it does not name any alternative sibling tool or state when not to use it in favor of safety_status or submit_for_review.

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?

Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description aligns with this by stating it marks drafts as pending publication. It adds meaningful behavioral context by explicitly stating that the tool will not log in or call Xiaohongshu private APIs, which is useful safety information beyond the 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?

The description is concise and front-loaded: the first sentence states the core action and target state, and the second sentence adds a valuable non-behavior guarantee. There is no redundant or vague wording.

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 tool with annotations and a clear sibling context, the description covers the prerequisite state, the resulting state, and a key external-behavior guarantee. It does not describe return values, but there is no output schema and the operation is simple enough that this is not a major gap.

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%, and the description does not explain either draftId or expectedContentHash. '已批准草稿' loosely implies draftId, but the purpose and computation of expectedContentHash are left entirely to the parameter name, so the description does not compensate for the missing schema descriptions.

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 operation: '生成结构化交接包' and '标记为待发布' for approved drafts. It identifies the resource and action, and the target state '已批准草稿' distinguishes it from review or approval tools, though it does not explicitly name sibling tools.

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 phrase '为已批准草稿' tells the agent this tool should be used after approval and before actual publication. It provides clear context but does not explicitly mention alternatives or when not to use this tool relative to siblings like record_publication.

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?

Annotations already signal read-only and closed-world behavior; the description adds meaningful context by stating it does not access external services and does not verify the caller is human. This goes beyond the structured annotations and helps set expectations for side-effect-free, local-only execution.

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?

Two short sentences with no filler; the action and object are front-loaded and the behavioral caveats earn their place. It is appropriately sized for a one-parameter read tool.

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 simple read-only tool with one parameter, the description covers what it returns (draft + current hash), its local scope, and its non-human-verification behavior. It does not describe not-found or error behavior, but those are minor for this complexity level.

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% and the description does not compensate: saying '按 ID' mostly restates the draftId parameter name. The UUID format and constraints are only in the schema, and the description adds no guidance on requiredness, format, or special values.

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 opens with '按 ID 读取一条本地草稿及其当前哈希', a specific verb+resource+scope. It clearly identifies the tool as a single-draft read with hash retrieval, which separates it from list_drafts and the mutation siblings.

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 phrase '按 ID' implies this is the tool to retrieve one draft when an ID is known, but it never names alternatives such as list_drafts for browsing or states when not to use it. No exclusions or selection criteria beyond the single-item read.

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?

Annotations already mark the tool as read-only and closed-world, and the description adds useful operational context: it lists only local drafts and does not access external services. It does not describe return ordering or payload shape, but for a simple lister this is a reasonable level of 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?

One concise sentence front-loads the action, resource, filter capability, and an important behavioral constraint. Every clause 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 simple read-only listing tool with two optional parameters, a clear schema, and no output schema, the description is adequate: it names the resource, the filter, and the local/non-external scope. It could mention return format or default unfiltered behavior, but the schema and verb list make these reasonably inferable.

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 clear meaning for the status parameter ('filter by status') but says nothing about limit. The schema's default, min, max, and enum still make both parameters reasonably self-explanatory, so partial compensation is enough for a 3.

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: list local drafts, with an explicit selection criterion (filter by status). This clearly distinguishes it from singular operations like get_draft and mutation tools like update_draft/cancel_draft.

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 implies usage: use this for listing local drafts, optionally filtered by status, and it explicitly says it does not access external services. However, it does not name alternative sibling tools or provide explicit when-not-to-use conditions beyond the local/non-external distinction.

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?

The annotations already declare readOnlyHint=true and openWorldHint=false. The description adds useful behavioral context beyond those annotations by explicitly stating that no external services are accessed and that the summary draws on local draft state and recent manual metrics.

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 a single sentence that front-loads the action and scope. Every phrase earns its place: what is summarized, what data is included, and the external-service boundary. There is no filler.

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, read-only summary tool, the description is largely complete: it identifies the covered data and the local-only constraint. It does not detail the output shape, but no output schema exists and the word '汇总' implies a high-level summary.

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 description has no parameter burden. The schema already fully covers the empty parameter set, and the baseline of 4 for zero-parameter tools applies here.

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 uses a specific verb '汇总' (summarize) and names the exact scope: '本地草稿状态与最近手工指标'. It also states '不访问外部服务', which helps distinguish it from tools that interact with external services or that record metrics rather than summarize them.

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 context for the tool's use — summarizing local draft status and recent manual metrics without external access. However, it does not explicitly mention when not to use it or name alternative sibling tools, so usage guidance is implied rather than explicit.

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?

The annotations provide no strong safety signals (readOnlyHint=false, destructiveHint=false), so the description must carry the behavioral burden. It does disclose that the tool writes to a local ledger and does not fetch pages, but it does not explain whether repeated calls append or overwrite existing metrics, or what happens after a successful write.

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 a single, tightly written sentence with no filler. The core action is front-loaded, and the clarifying exclusion '不抓取页面' earns its place by preventing a common misuse.

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 tool with six parameters, no output schema, and zero schema description coverage, this description is too sparse. It omits how draftId relates to the metrics, whether data is accumulated or replaced, and what the result of the operation looks like.

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, but it only says 'public metrics' and does not map properties like likes, saves, views, follows, comments, or draftId to specific meanings. The parameter names are self-descriptive, but draftId's role is left entirely unexplained.

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 names a specific verb ('写入' / write), a specific resource ('本地台账' / local ledger), and a clear input class ('人工查看到的公开指标' / manually observed public metrics). The explicit qualifier '不抓取页面' distinguishes this from page-fetching or scraping tools such as check_content.

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 a clear condition: only record metrics that were manually observed, and explicitly states that this tool does not crawl pages. It does not name a specific alternative sibling to use when fetching is required, so it stops short of full guidance.

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?

The description adds valuable behavioral context beyond the annotations: it only updates the local ledger and makes no external API call. This clarifies the side-effect scope and avoids confusion with publishing tools, even though annotations already indicate a write, non-destructive operation.

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 exceptionally concise: two sentences, no filler, with the core action front-loaded and the boundary condition stated immediately after. Every word 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 simple two-parameter local recording tool, the description covers the trigger, the core action, and the side-effect boundary. It does not describe return values or error behavior, but the low complexity and lack of an output schema make this a minor gap.

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 0% schema description coverage, the description partially compensates by identifying externalPostId as the public note ID and implying draftId refers to a manually published draft. However, it does not explain the relationship between the two parameters or provide more detailed semantics for each field.

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: after manual publishing, record the public note ID. It also distinguishes itself from siblings by explicitly saying it only updates the local ledger and does not call Xiaohongshu, making its purpose unmistakable.

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 a clear trigger condition: '人工发布后' (after manual publishing). It also implies when not to use it by stating it does not call Xiaohongshu, though it does not explicitly name alternative sibling tools.

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?

Annotations already provide readOnlyHint=true, and the description adds concrete behavioral boundaries beyond that flag: '不会访问小红书或修改数据'. This gives additional assurance about external access and side-effect absence. The description is consistent with the annotations and adds meaningful context, though not extensive detail about response format.

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 a single, front-loaded sentence: it first states the purpose, then the read-only condition, then the key negative guarantee about not accessing Xiaohongshu or modifying data. There is no filler or repetition of annotation/schema content.

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, read-only informational tool, the description covers the essential decision factors: purpose, scope, and data-safety guarantees. It does not explicitly describe the exact return shape, and there is no output schema to compensate, but the promise to explain whether the service is in read-only mode is sufficiently clear for an agent to know what to expect.

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 and the schema is an empty object with 100% coverage. Per the baseline for zero-parameter tools, the description is not expected to explain parameter semantics, and it correctly adds no unnecessary param-related details.

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 communicative purpose: it explains what the service will and will not do, and whether it is in read-only mode. This clearly distinguishes it from the sibling tools, which are content operations like submit_for_review or update_draft, making it an introspective rather than data-modifying tool.

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 makes the usage context clear: call this tool when you need to know service capabilities, boundaries, or the current read-only status. It does not explicitly name alternatives, but no sibling tool serves a similar introspective role, so the implied usage is unambiguous.

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?

Annotations already mark this as a write operation (readOnlyHint=false). The description adds useful behavioral detail beyond that: it only writes local data, never accesses Xiaohongshu, and imposes a constraint that assetPaths must point to readable regular files. The contentHash note adds extra specificity about how file bytes are counted.

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?

Two sentences, front-loaded with the primary purpose and no fluff. The contentHash mention is slightly cryptic given it's not in the input schema, so it doesn't fully earn its place, but overall the description is tight and efficient.

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 5-parameter write tool with no output schema, the description states scope and a key constraint, but misses important operational details: whether it creates a new draft or overwrites an existing one, what the response contains, and how to reference the saved draft later. This leaves an agent with several practical unknowns.

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, but it only clarifies assetPaths (must be readable files) and mentions contentHash (not even a schema parameter). It leaves title, body, topics, and campaign semantically unexplained; their meanings are left to inference from names.

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 names a specific action (save) and resource (content to local workspace), and immediately distinguishes itself from publishing/posting tools by stating it will not access or publish to Xiaohongshu. This clearly differentiates it from siblings like submit_for_review and create_publish_package.

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 clear context: use this tool to write content locally, not to publish or access external platforms. It doesn't explicitly name alternatives or state 'when not to use', but the local-only boundary gives an agent enough guidance to route correctly among publishing siblings.

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?

Annotations only express readOnly/openWorld/destructive hints as false. The description adds meaningful behavior beyond that: it changes draft status to pending review, may set a scheduled publish time, and does not publish externally. This is valuable context not available in the 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?

One short sentence conveys the core action, optional scheduling capability, and a safety clarification with no filler. It is front-loaded and every clause 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 2-parameter mutation with no output schema, the description covers what the tool does, what it avoids, and the optional scheduling parameter. It could add post-submit expectations or status outcomes, but the essential invocation context is present.

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. '可同时安排发布时间' clarifies scheduledAt's role and optionality, but draftId receives no semantic explanation beyond its schema name and format.

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 uses a specific verb and resource: '把本地草稿标为待审核' (mark local draft as pending review). It also explicitly states '不会对外发布' (will not publish externally), which distinguishes it from publishing or approval siblings.

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?

Usage is implied: use when a local draft should transition to pending review, optionally with a scheduled publish time. It does not explicitly name alternatives or state when not to use it, though '不会对外发布' gives an implicit exclusion from publication tools.

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?

The description goes well beyond the annotations (readOnlyHint=false, destructiveHint=false), disclosing that material files are re-read, contentHash is recomputed, approval is cleared and state reverts to draft on hash change, and that Xiaohongshu is never accessed. These are exactly the side effects an agent must predict before calling a mutating tool, with no contradiction against the annotation flags.

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?

Five short sentences, each carrying distinct information: the action, the partial-update rule, side effects, an immutability constraint, and a system boundary. The main action is front-loaded and there is no filler.

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?

Lifecycle constraints, side effects, partial-update behavior, and the closed-world boundary are all covered, which is strong for a mutating tool. The main gap: with no output schema present, the description never states what the tool returns or what failure modes exist (e.g., validation errors or unknown draftId).

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 the critical partial-update semantics ('省略的字段保持原值') that governs every optional parameter, and explains that assetPaths drive contentHash recomputation. However, the meanings of campaign and topics still rely on inference from their names, with no per-parameter guidance.

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 — '更新本地草稿字段' (update local draft fields) — reinforced by the title '更新运营草稿'. The partial-update and hash-recomputation details distinguish it from lifecycle siblings like submit_for_review, approve_draft, and cancel_draft.

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?

Clear context is given: omitted fields retain their values (partial update), and an explicit exclusion is stated — published or canceled drafts cannot be modified. However, no sibling is named as an alternative (e.g., when save_draft should be used instead), so the when-not condition exists but alternative routing is left implicit.

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