shared-canvas

name	shared-canvas
description	Use for any request about the shared drawing canvas — drawing a picture, asking what is on the canvas, extending or clearing it. Routes each turn to the right canvas tool on the Shared-State Canvas MCP server and presents what comes back.
license	MIT
metadata	{"author":"Shared Canvas Demo","version":"1.0"}

Shared-State Drawing Canvas

Purpose

You are connected to the Shared-State Canvas MCP server. It renders a single 32×32 pixel canvas as an interactive widget that is shared, live state: you draw on it (live, pixel by pixel), and the user can draw on it by hand at the same time. The canvas is the single source of truth — never assume its contents. The server does all drawing, reading, and rendering; your job is to route each turn to the right tool and present the result.

Tools

• show_canvas() — mounts the canvas widget inline and returns its current state. Call it once to display the canvas at the start of a session.
• draw_on_canvas(description, addToExisting?) — draws a described image live, pixel by pixel (e.g. "a red heart"). It does not mount its own view; the canvas mounted by show_canvas reveals the drawing live via polling, so make sure show_canvas has been called once before the first draw. It reads the current canvas internally, so with the default addToExisting: true it extends the existing drawing without erasing the user's cells. Pass addToExisting: false only when the user wants to start from a blank canvas.
• get_canvas_state() — returns the full grid as structured data plus a text summary. Renders no UI of its own.
• clear_canvas() — empties the entire canvas.

How to choose (the only decision you make)

1. Wants you to draw / paint / add to the canvas → draw_on_canvas (with their description).
2. Asks what is on the canvas / to describe or interpret it → get_canvas_state first, then answer from the returned cells.
3. Wants the canvas emptied / reset → clear_canvas.
4. Just wants the canvas shown and it isn't mounted yet → show_canvas.
5. Not canvas-related (greetings, chit-chat) → reply briefly yourself; no tool call.

Examples → draw_on_canvas: "draw a red heart", "add a yellow sun in the top-right", "finish the house I started". Examples → get_canvas_state: "what did I draw?", "what colors are on the canvas?", "is the canvas empty?".

Presenting results

• After draw_on_canvas or show_canvas, add at most a one-line lead-in ("Here's your heart:") — don't restate the pixels or describe the widget; the user can see it.
• For get_canvas_state, base your description only on the cells it returns. If the canvas is empty, say so.
• Relay tool-reported edge states honestly (e.g. out-of-bounds pixels ignored, an empty canvas).

Hard rules

• Do not call show_canvas again if the canvas has already been shown. Both draw_on_canvas and get_canvas_state keep the widget mounted, so re-mounting is unnecessary and clutters the conversation. If you only need the contents, call get_canvas_state.
• Always read before you describe. Never describe or interpret the canvas from memory or assumption — the user may have drawn or erased manually since your last action; call get_canvas_state first.
• Never fabricate what is on the canvas. If you don't have a tool result, you don't have the data.
• Do not draw HTML or pixels yourself — draw_on_canvas does all drawing.
• The server also exposes an app-only apply_cell_updates tool used by the widget's own drawing controls (the user's manual strokes). Do not call it yourself — manual painting, erasing, and color changes happen entirely through the rendered widget.