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

注解已声明非只读、非幂等、非破坏性、非开放世界，安全侧负担较轻；描述补充了「坐标为无限画布世界坐标、省略坐标自动排列」这一行为特性。但未提及单次最多 200 个元素的批量上限，以及版本冲突（虽然写在 expectedVersion 的 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?

仅两句，先用途后坐标语义，前置得当且无冗余解释。唯一可议之处是元素种类枚举几乎完整复述了 kind 的 enum，占用篇幅但信息增量有限。

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，返回值无需描述；expectedVersion 的冲突语义也已由 schema 承担。对一个批量写入工具而言，描述仍缺批量上限、权限要求以及「只追加不覆盖」的明确保证，整体够用但不够完整。

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 描述覆盖率仅 50%，描述部分弥补了 x/y 的语义（无限画布世界坐标、可省略并自动排布），这对调用者很有价值。但元素列表基本是复述 kind 的 enum，未对 mode、layout、points、branches 等未覆盖参数补充含义，补偿不完整。

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?

明确以具体动词「批量添加」加资源「白板元素」开头，并枚举了支持的九类元素（便签、文本、图形、箭头等）。与 add/update/delete_elements 三兄弟中后两者仅靠语义推断区分，未显式点名，但不影响调用者判断这是新增而非修改。

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?

描述隐含了用途（批量新增元素），并给出了一个关键使用条件——省略坐标时自动排列。但没有说明何时应改用 whiteboard_update_elements 或 whiteboard_align_elements，也没有交代前置条件（如是否需先 inspect 获取版本）。

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 declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds nothing behavioral beyond that: it does not mention that geometry is mutated in place, that stale writes return VERSION_CONFLICT (only found in the schema), or any failure modes.

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?

A single, front-loaded sentence with no filler. It is efficient, though its brevity is achieved partly by omitting information an agent would need.

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?

An output schema exists so return values need not be explained, and annotations cover mutability. However, for a mutating tool with a version-conflict hazard and no usage guidance or mode enumeration in prose, the description is too thin to stand as the primary narrative.

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 50%: boardId and expectedVersion are documented in the schema, while ids and mode are not. The phrase '按边缘、中心或间距' loosely maps to the mode enum's edge/center/distribute families, adding marginal meaning, but the 2-200 ids array constraint and required-ness are left entirely to 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 (align/distribute) and resource (two or more elements) plus the alignment bases (edge, center, spacing). It is clear on its own, but does not differentiate itself from siblings such as whiteboard_update_elements, which an agent might confuse for geometry changes.

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?

There is no statement of when to use this tool versus alternatives, no prerequisites (e.g., needing element IDs from whiteboard_inspect), and no note that it operates on existing elements rather than creating them. The agent must infer all routing decisions.

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 cover the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), and the description adds a genuine side-effect not derivable from them: the new document automatically contains one blank page. That is useful non-obvious behavioral context, though nothing is said about permissions or failure modes.

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 with the action front-loaded and zero filler. Well sized for a trivial single-parameter creation tool, though it could have spent one more clause on sibling differentiation.

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?

An output schema exists, so return values need not be explained, and the description covers the core action plus the auto-created blank page. It is nonetheless incomplete for a tool sitting among three closely related creation/routing siblings, since it never clarifies when this is the right choice.

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 100% and the single 'title' parameter is documented in the schema, so the schema does the heavy lifting. The description adds no extra meaning about the title (length limits, defaults, format), which is the expected baseline.

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 and resource: creating a standalone whiteboard document ('创建一个独立白板文档'). Clear enough to be understood, but it does not explicitly distinguish itself from sibling tools like whiteboard_create_page or whiteboard_duplicate, so an agent must infer which one creates the board itself.

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?

No when-to-use or when-not-to-use guidance is given, and no alternatives are named. With 15 siblings including whiteboard_create_page and whiteboard_duplicate, the description leaves the agent to guess which tool applies to a given intent.

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 declare the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the bar is lower. The description does add one genuinely useful trait beyond annotations — the new page is made the current page, which changes editor state. It says nothing about versioning requirements or permission needs, so it remains a partial 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?

A single, front-loaded sentence with zero filler — the action and its immediate side effect are stated first. It is efficient, though arguably terse given the gaps noted elsewhere.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. What is missing is the routing distinction from whiteboard_manage_pages and any signal about the undocumented name parameter, which leaves the definition only minimally sufficient for a mutating create 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 67%, and the description contributes no parameter information at all. The 'name' parameter has no schema description and no description coverage, leaving it entirely undocumented, while boardId and expectedVersion semantics live only in 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?

States a specific verb and resource (create a new page) plus scope (in the specified whiteboard) and a side effect (it becomes the current page). It does not, however, distinguish itself from the sibling whiteboard_manage_pages, which plausibly also manipulates pages, so an agent cannot fully route on purpose alone.

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?

There is no when-to-use guidance and no named alternative, despite whiteboard_manage_pages sitting in the same sibling list and likely overlapping in capability. The agent is left to infer whether page creation belongs to this tool or the manage_pages tool.

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?

Beyond the `destructiveHint: true` annotation, the description explicitly adds crucial behavioral traits: the operation is '不可撤回' (irreversible), and it provides the important caveat that '不会删除原始映射文件' (it will not delete the original mapping file).

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 definition is highly dense and efficient, covering scope, required inputs, behavioral constraints, and critical data preservation warnings in a minimal, impactful structure.

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 definition is highly complete. It not only details what the tool does but also addresses the critical 'how' (confirmation, version control) and 'what ifs' (irreversibility, file preservation).

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?

Since the schema description coverage is 0%, the description is responsible for defining semantics. It effectively clarifies the required constraints of 'confirm=true' and the purpose of providing 'expectedVersion.'

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 ('删除' - delete) and clearly defines the resource ('整张白板' - entire whiteboard). It explicitly distinguishes itself from sibling tools like those related to element deletion.

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 usage constraints, requiring 'confirm=true' and strongly suggesting the use of 'expectedVersion.' This guides the agent on necessary input conditions for a successful and safe call.

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 declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is known. The description adds the useful boundary that only the enumerated IDs are affected and no page/board is removed, but says nothing about partial-failure behavior, non-existent IDs, or auth needs.

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 zero filler, and the scope constraint is front-loaded. It is arguably terse to the point of omitting useful detail, but nothing stated is wasted.

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?

An output schema exists so return values need not be explained, and annotations cover the mutation semantics. The description establishes the deletion scope, leaving only edge cases (invalid IDs, partial deletes) unaddressed, which is acceptable for this level of 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 coverage is 67% – boardId and expectedVersion carry their own descriptions, while ids is self-evident as an ID array. The description contributes nothing about parameters, so the baseline of 3 is warranted given the schema does the documenting.

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 and resource (delete the explicitly given element IDs) and immediately bounds the scope, distinguishing it from whiteboard_delete_board and page-level deletion. The scope boundary makes it clear what the tool does not touch, though it does not name a sibling alternative.

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 negative scope ('will not delete pages or the whole whiteboard') implies when other tools like whiteboard_delete_board or whiteboard_manage_pages are appropriate, but no alternative is named explicitly. Usage is inferable rather than stated.

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 declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful trait beyond that: image and file references are preserved (not re-uploaded/deep-copied). However, it says nothing about the created board becoming a new separate board, permission requirements, or concurrency behaviour.

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 clauses, verb-first and front-loaded, with zero padding. Efficient, though it is arguably too terse given the parameter and usage gaps it leaves unaddressed.

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?

An output schema exists, so return values need not be described. Against a 3-parameter mutation tool with no annotation-level detail on versioning, the description covers the core effect and reference semantics but leaves the required title/versioning contract entirely unexplained.

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% for 3 parameters, so the description carries the full burden and says nothing. It never mentions that a required `title` names the new board, what `boardId` identifies, or that `expectedVersion` is an optional optimistic-concurrency guard — a notably confusing gap given the mutation also produces a new named resource.

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 (复制/duplicate) and resource (白板/whiteboard) with scope clarified as 全部页面与内容 (all pages and content), which separates it from whiteboard_create (new blank board) and whiteboard_export. It is clear, though it does not explicitly name a sibling as the alternative.

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?

There is no when-to-use guidance and no mention of alternatives such as whiteboard_create or whiteboard_export. The agent must infer that duplication makes a full copy rather than reusing or exporting.

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 establish readOnlyHint and openWorldHint, so safety is covered. The description adds valuable behavioral facts beyond them: the plain snapshot path requires an API call, the includeArchive path returns image/file archive as Base64 without the API, and there is an 8 MiB size ceiling. This is well above the annotation baseline.

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?

A single dense sentence that front-loads the primary return (snapshot + download URL) before the conditional archive behavior. Every clause carries information (return type, API requirement, size limit, fallback); 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?

With an output schema present, return shapes need not be spelled out, yet the description adds the useful operational constraints (API requirement, 8 MiB limit, app-export fallback) for a read-only tool. It is complete enough for correct invocation, though it omits how the result compares to the lighter thumbnail sibling.

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 50%: boardId is documented in the schema, includeArchive is not. The description compensates by explaining exactly what includeArchive=true does (returns an image/file archive as Base64, API-free) and its size constraint, so the uncovered parameter is meaningfully explained.

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 output-oriented purpose: it returns a full snapshot plus a .moki ZIP download URL, with an alternate Base64 archive mode. This is clear enough to distinguish the tool's function from most siblings (which mutate or list). It stops short of explicitly contrasting itself with near-alternatives like whiteboard_get_thumbnail.

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 gives conditional guidance: use includeArchive=true to avoid the API, and fall back to app export for boards over 8 MiB. That is real when-to-use context, including an exclusion. However, it never tells the agent how this differs from sibling retrieval tools such as whiteboard_get_thumbnail, so cross-tool selection is left to inference.

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 readOnlyHint=true and openWorldHint=false already covering safety, the description adds meaningful context beyond annotations: it reads the last saved screenshot rather than live content, warns that unedited boards may have no screenshot, and states that the response includes a screenshot version and freshness flag. It does not contradict 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?

Two sentences with no waste. The first sentence front-loads the tool's purpose, and the second efficiently adds the availability caveat and return contents.

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 thumbnail tool with one fully documented parameter, an output schema, and safety annotations, the description is largely complete: it covers purpose, availability caveat, and return semantics. The only notable gap is the absence of explicit routing guidance versus sibling tools.

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 100%, so the single boardId parameter is already fully documented in the schema, including its default and the recommendation to specify it. The description adds no additional meaning about the parameter, so the baseline score of 3 is appropriate.

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: reads the real whiteboard screenshot saved at the last edit. It is clear what the tool does, but it does not differentiate itself from sibling tools such as whiteboard_export or whiteboard_inspect, which an agent might reasonably consider for related image or board data.

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 the tool's use case and adds a useful availability caveat: whiteboards that have not been opened for editing may lack a screenshot. However, it gives no explicit when-to-use guidance versus alternatives like whiteboard_export or whiteboard_inspect, leaving routing to inference.

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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered by structured data. The description adds the useful behavioral cue that this is the ID-discovery step preceding mutation, but says nothing about pagination behavior (limit) or result shape, which the output schema presumably covers.

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 compact sentences, front-loaded with what is returned and followed by the action-oriented trigger. No filler 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?

An output schema exists, so return values need not be described, and annotations cover the read-only safety profile. The remaining shortfall is the undocumented limit/pagination parameter, which leaves a small gap for a tool returning potentially large element lists.

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 67%: pageId and boardId carry their own descriptions, but limit is undocumented anywhere. The description adds no parameter-level detail (no mention of paging, page scoping, or board selection), so it does not compensate for the gap – baseline 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 names a concrete resource set – pages, element IDs, positions, sizes, colors, and text – so an agent can tell this is the element/page inspector rather than a board lister like whiteboard_list or an image fetcher like whiteboard_get_thumbnail. It stops short of explicitly contrasting itself with those siblings, but the enumerated fields make the distinction inferable.

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?

"修改前先调用此工具取得准确 ID" gives an explicit triggering condition: call before any modification to obtain accurate IDs, which naturally routes the agent here ahead of update_elements/delete_elements/align_elements. No when-not-to-use or explicit alternatives are named, keeping it short of a 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered structurally. The description adds a meaningful filter nuance (only boards the agent can operate on), but says nothing about ordering, result limits, or what a listing entry contains — the output schema covers the latter, so this is a modest addition.

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?

A single short sentence with zero filler, with the scope qualifier front-loaded alongside the verb and resource.

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 no-parameter, read-only listing tool with an output schema and safe annotations, the description gives enough to call it correctly. Only a hint about result ordering or typical follow-up (pass an id to another whiteboard_* tool) is absent.

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 takes zero parameters, which is the baseline-4 case; no parameter semantics are needed and none are missing.

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 (列出/list) and resource (白板文档/whiteboard documents), and adds a scope qualifier '可供 Agent 操作' that distinguishes it from a raw enumeration. It does not explicitly contrast with whiteboard_inspect or the other siblings, but the purpose 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 phrase '可供 Agent 操作' implies this is the discovery step before operations, but the description never says when to call it instead of whiteboard_inspect or whiteboard_get_thumbnail. Usage is only implied.

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 declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description then adds genuinely new behavior: deleting a group preserves its pages and returns them to ungrouped, which clarifies the blast radius beyond the annotation. It does not state which of the four actions is destructive or note the version-conflict rejection path, so it stops short of a 5.

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?

A single front-loaded sentence that enumerates the actions first and the destructive nuance second, with no filler. It is efficient, though it leaves parameter and usage detail unstated rather than merely compact.

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?

An output schema exists, so return values need not be described. However, for a 5-parameter, destructive, version-gated mutation tool with 40% schema coverage, the description omits which action pairs with which parameters and says nothing about permission or version requirements beyond what the schema already states. Adequate but with clear gaps.

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 only 40%; boardId and expectedVersion are documented in the schema, but action, name, and groupId have no descriptions anywhere. The description mentions 重命名 (implying name + update) but adds no syntax, format, or required-combination detail to compensate for the gap.

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 specific verbs (创建/重命名/删除/列出) against a specific resource (页面分组), so the agent knows it manages group entities rather than pages. It does not explicitly differentiate itself from the closely-named sibling whiteboard_manage_pages, which tempers the score.

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 enumerated actions imply the tool's scope, but there is no when-to-use, when-not-to-use, or alternative guidance, and no prerequisites such as needing an inspected version before writes. An agent must infer that this is the right tool versus whiteboard_manage_pages.

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 declare destructiveHint=true and idempotentHint=true, so the safety profile is known; the description goes further by disclosing two non-obvious behaviors: deleting a page also destroys its content, and a whiteboard must always retain at least one page. It does not cover permission requirements or the version-conflict behavior beyond what the schema notes.

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, front-loaded with the operations and then the destructive/minimum-page constraint. No filler or restatement of the name.

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?

An output schema exists so return values need no explanation, but for a 7-parameter, three-action tool with very low schema description coverage, the description omits which parameters each action requires (e.g. name for rename, pageId for delete) and omits prerequisites. Just adequate.

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 only 29% across 7 parameters, and the description names none of them or their formats (name length, groupId nullability, pageId vs boardId, which params apply to which action). Phrases like 'move to group' hint at groupId but add no actionable semantic detail, so the coverage gap is not compensated.

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 resource (whiteboard pages) and enumerates the concrete operations: list, rename, move to group, delete. This is clear and lets an agent map intent to the action enum, but it never distinguishes itself explicitly from siblings like whiteboard_create_page or whiteboard_manage_page_groups.

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 only implied: by listing the four operations the description indirectly signals 'use this to manage existing pages', but there is no when/when-not statement, no prerequisites, and no pointer to the sibling tools that handle page creation or group management.

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 declare this a non-readOnly, non-idempotent, non-destructive write operation, lowering the bar. The description adds that it drives the same native editor as the UI and requires accurate IDs fetched beforehand, but says nothing about reversibility, permission needs, or the expectedVersion concurrency control implied by 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?

Three tight, front-loaded sentences with no padding: purpose first, then capabilities, then the prerequisite and a unit note. The brevity is structural, not wasteful, though it leaves the action vocabulary unexplained.

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 multi-action tool with 13 enum actions, 8 parameters at 13% schema coverage, and no nested-object documentation, this description is far too thin. An output schema exists so return values needn't be covered, but the action semantics and expectedVersion behavior are unaddressed.

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 only 13% across 8 parameters, so the description must carry the load. It contributes one meaningful detail ('rotation 使用角度') and a vague ID/records hint, but the 13-value action enum, ids, text, records, parentId, and expectedVersion remain entirely undocumented.

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 ('直接调用与 UI 相同的 MOKI 原生编辑器') and enumerates its capability scope: native props editing, grouping/folders, and mind-map branch operations. This distinguishes it from the plain add_elements/update_elements siblings by framing it as the native UI-equivalent editor, though the 13 discrete actions live only in the 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?

Provides a real prerequisite workflow ('先 whiteboard_inspect/whiteboard_export 获取准确 ID 和记录') naming two sibling tools, which is genuine guidance. However it never says when to choose this over whiteboard_add_elements, whiteboard_update_elements, or whiteboard_delete_elements, the most likely ambiguity given the sibling set.

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 declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is largely covered. The description adds the useful behavioral detail that the tool supports version validation (optimistic concurrency), but does not explain what happens on a version mismatch or what permissions are needed.

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 clauses with no padding, and the core action is front-loaded. It is efficient, though arguably too terse given the zero schema coverage it needs to compensate for.

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?

An output schema exists, so return values need not be described, but for a mutation tool with 0% parameter description coverage and no permission/auth or conflict-handling detail, the description is too thin to fully guide correct invocation.

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 only alludes to version checking, without explaining expectedVersion semantics on mismatch, the meaning of boardId, or the title length constraints (minLength 1, maxLength 120) enforced by the schema. This leaves most parameter behavior undocumented.

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 (重命名/rename a whiteboard), which cleanly distinguishes it from siblings like whiteboard_create, whiteboard_delete_board, and whiteboard_duplicate. It does not, however, explicitly differentiate against similarly mutation-oriented siblings such as whiteboard_native_edit, leaving some routing inference to the agent.

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?

There is no when-to-use, when-not-to-use, or alternative-tool guidance. The phrase '支持版本校验' merely hints that version checking is available, without saying when an agent should supply expectedVersion versus omit it, or what to do when a rename is not appropriate.

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 declare destructiveHint=false, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds nothing beyond them: it never states that omitted fields are left unchanged (partial-update semantics), that up to 200 elements may be batched, or that a stale write raises VERSION_CONFLICT instead of overwriting — the latter only appears 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?

A single, front-loaded sentence with no filler; the ID requirement appears before the list of modifiable properties. It is efficient, though its brevity is part of why behavioral and usage context is thin.

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?

An output schema exists, so return values need not be described, and the mutation's risk is tempered by destructiveHint=false plus idempotency. Still, for a batch mutation tool touching up to 200 elements with optimistic concurrency, the absence of any note on partial updates or the inspect-then-update version flow leaves a meaningful 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 coverage is 67%, with boardId and expectedVersion documented inline, so the baseline is 3. The description does add that updates are keyed by exact element ID and enumerates the modifiable attributes, but it does not explain the array-of-updates structure or that each item needs only an id plus the changed fields.

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 gives a specific verb (更新/批量修改), the resource (白板元素) and the update dimensions (文本、位置、尺寸、颜色、旋转), plus the key constraint that elements are addressed by exact ID. This implicitly separates it from whiteboard_add_elements, whiteboard_delete_elements and whiteboard_align_elements, though no sibling is named.

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?

No when-to-use or when-not-to-use guidance, and no mention of the obvious prerequisite workflow (calling whiteboard_inspect to obtain element IDs and the version). The phrase 按准确元素 ID hints that IDs are required but never says where to get them or how this differs from whiteboard_align_elements or whiteboard_native_edit.

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