Pondchat

Draw on board

draw_on_board

Draw on the room's shared board as an AI agent. Pass drawing PRIMITIVES (not pixel data) — the room converts them to board strokes and broadcasts them to admitted participants over the signaling channel; agents have no WebRTC stack, so strokes arrive via server relay, not P2P. Kinds: path (freehand pts), line (from/to), arrow (from/to, auto head), rect (x,y,w,h), circle (cx,cy,r), ellipse (cx,cy,rx,ry), text (at + text label — rendered as a font, not ink). All coordinates and sizes are normalized 0-1 canvas fractions (size = stroke width / font height). The latest batch is also replayed to participants who join after the draw. Use get_board_state to read what's on the board first.

Input Schema

Name	Required	Description
`roomId`	Yes	The room ID whose board to draw on.
`strokes`	Yes	Drawing primitives (max 48). Each: {kind, color?, size?, erase?, ...geometry}. color = #hex or rgb(), size = normalized width (default 0.009; for text = font height, default 0.035).
`senderId`	No	Optional stable identity for the agent (max 64 chars). Defaults to "mcp-agent".
`senderName`	No	Optional display name announced to participants (max 32 chars).
`agentSecret`	No	Optional agent credential (8-128 chars — keep it random). Claims the senderId on first use; must be repeated on every later call. REQUIRED on a locked pond.

Output Schema

Name	Required	Description
`note`	Yes
`roomId`	Yes
`aiUserId`	Yes
`buffered`	Yes	true when nobody was connected — the batch is replayed to the next joiner
`delivered`	Yes
`strokeIds`	Yes
`strokeCount`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

addedInput schema / properties / agentSecret

Added value: +{
+  "description": "Optional agent credential (8-128 chars — keep it random). Claims the senderId on first use; must be repeated on every later call. REQUIRED on a locked pond.",
+  "maxLength": 128,
+  "minLength": 8,
+  "type": "string"
+}

AddedNov 1, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations it discloses delivery mechanics an agent could not infer: strokes are broadcast to admitted participants over the signaling channel via server relay rather than P2P, and 'the latest batch is also replayed to participants who join after the draw'. That replay behavior plus the no-WebRTC constraint is exactly the kind of non-obvious context annotations cannot carry, and nothing conflicts with destructiveHint=false or idempotentHint=false.

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?

The definition is front-loaded with the core verb and input model before details, and nearly every clause carries information. It is dense, though, with long semicolon-chained sentences that could be broken for faster scanning.

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

Completeness5/5

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

For a multi-primitive drawing tool this is complete: kinds, geometry, coordinate system, delivery path, replay behavior and the prerequisite read step are all covered, and an output schema exists so return values need no explanation.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description earns above that by defining each primitive kind and its geometry (path pts, line/arrow from-to, rect x,y,w,h, circle/ellipse, text at) and by stating that all coordinates and sizes are normalized 0-1 canvas fractions with size meaning stroke width or font height. That coordinate normalization is not stated in the schema itself, so it is genuine added meaning.

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

Purpose5/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 ('Draw on the room's shared board as an AI agent') and immediately qualifies the input model ('Pass drawing PRIMITIVES (not pixel data)'). This separates it cleanly from siblings like get_board_state, undo_board, remove_strokes and clear_board.

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

Usage Guidelines4/5

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

It explicitly directs the agent to 'Use get_board_state to read what's on the board first', which is real when-to-use routing. It stops short of naming when-not-to-use or pointing at undo_board/remove_strokes/clear_board for correction, so it is strong but not exhaustive.

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

All Pondchat tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?