moki-whiteboard

Overview Schema Source Related Servers Discussions Admin

管理白板页面

whiteboard_manage_pages

DestructiveIdempotent

List, rename, reorder, group, or delete whiteboard pages while keeping at least one page. Deleting a page also removes its content, so manage page structure without leaving an empty board.

Instructions

List, rename, reorder, group, or delete pages. Deleting a page also deletes its content; at least one page must remain. 列出、重命名、移动到分组或删除页面。删除页面也会删除该页内容，且白板至少保留一页。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "whiteboard_manage_pages"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No
`index`	No
`action`	Yes
`pageId`	No
`boardId`	No	白板 ID；省略时使用最近更新的白板，建议始终指定准确 ID	default
`groupId`	No
`expectedVersion`	No	先 inspect 获得版本；过期写入会返回 VERSION_CONFLICT 而不会覆盖内容

Output Schema

Name	Required	Description	Default
`board`	No
`error`	No
`boards`	No
`pageId`	No
`boardId`	No
`current`	No
`deleted`	No
`version`	No
`alignedIds`	No
`deletedIds`	No
`elementIds`	No
`updatedIds`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.7Oct 21, 2026

TDQS

B3.2/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, so the description's job is to add substance, and it does: it warns that deleting a page also destroys its content and that the board must retain at least one page. It does not mention concurrency behavior (VERSION_CONFLICT on stale writes) or that the 'list' action is a safe read inside an otherwise destructive tool, but the core risk is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences, verbs front-loaded, with the destructive constraint placed last where it reads as a guard rail. The only slack is the verbatim bilingual duplication, which is conventional but doubles the token cost without adding information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

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 safety profile is covered by annotations. But for a 7-parameter, three-action multiplexed tool at 29% schema coverage, the description leaves the action-to-parameter mapping, groupId semantics, and expectedVersion workflow unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 29% out of 7 parameters, and the description compensates for essentially none of it: name, index, pageId, groupId, and the action enum are unexplained. Worse, the prose verbs ('rename', 'reorder', 'group') do not match the actual enum values (list/update/delete), so the agent must infer that 'update' subsumes all three mutations — a mapping the description never states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description enumerates concrete operations on a concrete resource (list, rename, reorder, group, delete pages), which is far better than a tautology. However, it does not distinguish this tool from siblings such as whiteboard_manage_page_groups, whiteboard_create_page, or whiteboard_rename, which appear to overlap with 'group' and 'rename' here, so the agent must guess which tool owns which operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 consolidated manager versus whiteboard_rename, whiteboard_manage_page_groups, or whiteboard_create_page, despite obvious overlap in the sibling list. The only usable guidance is an internal precondition ('at least one page must remain'), which is a constraint rather than routing advice.

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

Deploy Server