Pondchat

Remove board strokes

remove_strokes

DestructiveIdempotent

Delete specific board strokes by id — any owner's, including human strokes (a power beyond the human Undo, which only takes back your own). Get ids from get_board_state. Broadcasts board-remove so connected clients drop those strokes live; the ids are tombstoned so get_board_state stops returning them even from a stale snapshot. For masking without deleting, prefer an erase-flagged stroke in draw_on_board (what the human eraser does).

Input Schema

Name	Required	Description
`ids`	Yes	Stroke ids to delete (1-144, from get_board_state — human ids look like user:<id>:<seq>, agent ids like ai:<sender>:<seq>).
`roomId`	Yes	The room ID whose board to edit.
`senderId`	No	Optional stable identity for the agent (max 64 chars). Defaults to "mcp-agent".
`agentSecret`	No	Optional agent credential (8-128 chars — keep it random). Must match the secret that claimed this senderId. REQUIRED on a locked pond.

Output Schema

Name	Required	Description
`ids`	Yes
`note`	Yes
`roomId`	Yes
`removed`	Yes	Stroke count removed
`aiUserId`	Yes
`delivered`	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). Must match the secret that claimed this senderId. 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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered structurally; the description goes further by disclosing the live broadcast ('board-remove') to connected clients and the tombstoning effect that makes deleted ids stop appearing in get_board_state even from stale snapshots. Those are non-obvious downstream consequences an agent could not infer from annotations or schema.

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?

Three sentences, front-loaded with the core action, and each sentence carries distinct information (scope, id source, side effects, alternative). The stacked parentheticals make it denser than ideal but nothing is filler.

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?

With four well-documented parameters, a full annotation set and an output schema, the description only needs to supply action scope and side effects, and it does both, including the human-Undo comparison and the eraser alternative. Nothing an agent needs to invoke this correctly is missing.

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 description coverage is 100%, so the ids, roomId, senderId and agentSecret semantics are already documented in structured form. The description only reinforces that ids come from get_board_state, adding little syntax or format detail beyond the schema, so the baseline 3 applies.

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 opens with a specific verb and resource ('Delete specific board strokes by id') and immediately scopes it ('any owner's, including human strokes'), which separates it from undo_board (own strokes only) and clear_board (everything). An agent can choose among these siblings without opening their schemas.

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

Usage Guidelines5/5

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

It names the prerequisite source of ids ('Get ids from get_board_state') and routes the agent to an alternative when deletion is the wrong action ('For masking without deleting, prefer an erase-flagged stroke in draw_on_board'). Both a when-to-use and a when-not-to-use path are explicit.

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?