Skip to main content
Glama
Sign In
moki-whiteboard

moki-whiteboard

by JKZeng-cell
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

原生白板编辑操作

whiteboard_native_edit

Edit native whiteboard properties, group or collapse items into folders, and manage mind-map branches; inspect or export exact IDs first to target records accurately.

Instructions

Use the native canvas editor for properties, grouping, collapsing groups into virtual folders, expanding folders, and mind-map branches. Inspect/export exact IDs and records first. Rotation is in degrees. 直接调用与 UI 相同的 MOKI 原生编辑器。支持原生 props 编辑、分组/资料夹，以及真正的思维导图分支操作。先 whiteboard_inspect/whiteboard_export 获取准确 ID 和记录；rotation 使用角度。

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": {
      "pageId": "<pageId>",
      "action": "<action>"
    },
    "name": "whiteboard_native_edit"
  }
}

Input Schema

NameRequiredDescriptionDefault
idsNo
textNo
actionYes
pageIdYes
boardIdNo白板 ID；省略时使用最近更新的白板，建议始终指定准确 IDdefault
recordsNo
parentIdNo
expectedVersionNo

Output Schema

NameRequiredDescriptionDefault
boardNo
errorNo
boardsNo
pageIdNo
boardIdNo
currentNo
deletedNo
versionNo
alignedIdsNo
deletedIdsNo
elementIdsNo
updatedIdsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.7

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare non-read-only, non-idempotent, non-destructive; the description adds useful context that this executes the same native editor as the UI and that IDs/records should be fetched first. It says nothing about the 200-item cap, the meaning of expectedVersion concurrency control, or what happens on version mismatch, which matter for a mutating tool.

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

Conciseness3/5

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

The precondition is front-loaded and each English sentence is useful, but the entire content is then restated in Chinese, roughly doubling length with zero added information. Efficient in ordering, wasteful in duplication.

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

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Return values are covered by the output schema, but for a mutating tool with 8 parameters, 13 actions, and version control, the description omits action-level behavior, concurrency/expectedVersion semantics, and the ids/records payload contract. An agent cannot reliably construct a call from this description plus the thin schema alone.

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 13% across 8 parameters, so the description must compensate and largely doesn't. It clarifies only that rotation is in degrees; the 13-value action enum, ids, text, parentId, records shape, and expectedVersion are all unexplained, leaving most call semantics to guesswork.

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 names a specific verb and resource ('native canvas editor' for props, grouping, folders, mind-map branches) and signals it mirrors the UI editor, which separates it from lower-level element tools. However, it doesn't explicitly distinguish itself from siblings like whiteboard_update_elements or whiteboard_manage_page_groups, so an agent still has to infer the boundary.

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

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is one concrete guideline: 'Inspect/export exact IDs and records first', which is a real precondition. But it never says when to pick this tool over whiteboard_update_elements, whiteboard_align_elements, or whiteboard_manage_page_groups, so the choice between overlapping siblings 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.

Deploy Server

Other Tools