Skip to main content
Glama

draw_board

Destructive

Draw and modify shapes, text, lines, and images on a shared infinite canvas, plus save, switch, import, or export editable board snapshots.

Instructions

让 AI 直接在共享无限画布上画或改,也可通过 library 参数保存当前画板、切换本地画板图库中的图、新建/重命名/复制/删除/导入/导出可编辑版本 1 画板。普通写入会串行应用到最新状态;line 的 (x,y) 是起点,(x+w,y+h) 是终点,w/h 可为负数;其他对象是左上角与宽高。按整齐网格布局;不打开浏览器,不写项目文件。

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "draw_board"
  }
}

Input Schema

NameRequiredDescriptionDefault
itemsNoObjects to create; omit id
authorNoAuthor marker; AI responses should normally use ai
layoutNoOptional deterministic arrangement of existing objects
libraryNoOptional local board-library action for saving, switching, renaming, duplicating, importing, or exporting editable board snapshots
updatesNoPrecise updates to existing object IDs
remove_idsNoExisting object IDs to remove
replace_boardNoRare full replacement with a version 1 board snapshot; revision and identity are preserved
expected_revisionNoOptional board revision for rejecting stale canvas edits

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=false, but the description adds real context: writes are applied serially to the latest state, nothing is written to project files or a browser, and destructive library actions (delete/rename/overwrite) exist. It stops short of explaining revision-conflict behavior or what a failed/rejected edit returns.

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?

Front-loaded with purpose, then library capability, then geometry rules and constraints; every clause carries information. It is a dense single block with a couple of run-on segments, but no filler.

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?

For an 8-parameter mutation tool with nested objects and no output schema, the description covers the core write path, geometry conventions, and library actions. It omits how results are reported (created IDs, applied revision), stale-edit rejection via expected_revision, and the grid-layout behavior's interaction with existing objects.

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

Parameters3/5

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

Schema coverage is 100%, so the schema carries most parameter documentation. The description adds genuine meaning for geometry: line (x,y) is the start and (x+w,y+h) the endpoint with w/h allowed to be negative, while other objects use top-left plus width/height. That is useful but limited to one aspect; library/updates/replace_board semantics remain schema-only.

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?

Opens with a specific verb+resource: draw or modify on a shared infinite canvas, and enumerates the library sub-actions (save/switch/create/rename/duplicate/delete/import/export). The clause 'does not open a browser' implicitly separates it from viewers like show_board, though no sibling is named outright.

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?

Usage is implied ('draw or modify') and the library parameter is explained as an alternative mode of the same tool, with scope exclusions (no browser, no project files). There is no explicit routing guidance such as 'to read the canvas use get_board' or a statement of when not to call this tool.

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

This server cannot be deployed

Other Tools