Describes the environment variables required to run the server.

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

Doodle is a local-first two-way infinite board. A person and an AI both draw notes, text, rectangles, ellipses, arrows, freehand strokes, and images on it to express intent; each side can read and continue the other's visual context. MCP stdio is the AI's normal access channel; a plugin is the preferred install path for Codex-compatible hosts. Normal tool calls never open a browser or write project files. Product story is one kernel, two entry points, three capability layers: one shared board; Codex plugin or direct MCP; four tools always, an optional embedded canvas in compatible hosts, and optional final-state context sync plus notification. Project structure is optional source material only. First use: call get_board, then show_board when the person wants to see the canvas, then draw a small starter note with draw_board and keep the canvas visible. A natural first request is 'open the Doodle board so we can communicate on it'. Use get_board as the normal first step: read FIRST_USE, NEXT_STEPS, BOARD_JSON, current object IDs, coordinates, authors, and the drawing guide. Use show_board when the user asks to open, see, display, or edit the canvas; it renders the interactive app in compatible hosts without duplicating the conversation. After a successful draw_board call, keep the canvas visible: compatible hosts render it from the draw result automatically, and other hosts should be followed immediately with show_board. get_board also reports PANEL_URL, the active local human-facing address. Mention it when a person asks where to look or when the host cannot render an embedded canvas; never open a browser from a normal tool call. Board writes are serialized against the latest state; embedded canvas edits include expected_revision so stale edits are rejected and refreshed before retry. Use draw_board to add items, precise updates, removals, or a deterministic layout. Use stroke for freehand marks, image for bounded data:image/* sources, title for headings, shape for straight/curve/orthogonal arrows, emphasis: focus to highlight what matters, and updates instead of clearing the board whenever possible. Treat person-drawn objects as intent, not decoration: read them, answer in the host chat, and draw a visual response when useful. Keep conversation in the agent chat; do not post chat replies onto the board. Use draw_board's library action for editable local board snapshots: save the current board under a name, list or switch saved boards, create/rename/duplicate/delete boards, or import/export version 1 board JSON. These are local images of the board state, not static PNG exports and not a second collaboration model. Read get_board's capabilities, visualDigest, and RECIPES before drawing. Use short deterministic recipes: flow (role: step + connected line), compare (role: column or variant: frame), cluster (groupId + layout.mode: cluster), emphasis (emphasis: focus + optional stroke), and image-annotation (bounded image + nearby text/note + connected line). Optional version 1 fields make drawings intentional: variant sets shape treatment, role marks semantic purpose, z controls stacking, style controls bounded visual treatment, and startItemId/endItemId bind a line to object edges. Connected lines follow their bound objects; they are not project-write authority. Drawing contract: a line is an arrow from (x,y) to (x+w,y+h); w/h are signed endpoint deltas and may be negative. Other items use (x,y) as the top-left corner with positive width/height. Stroke points are local to the item bounds. For a structured diagram, read the board first, use a strict grid, short labels, and endpoints just outside the source and target shapes. Prefer updates/removes over clearing everything. Put author at the draw_board top level. scan_project is optional: a read-only project-structure capability. It returns bounded paths and evidence text only; use draw_board to place that information on the shared board. It never mutates files or grants write authority. The local HTTP page is a standalone fallback for seeing and editing the same canvas. MCP Apps-compatible hosts embed it beside the conversation; its small ? help button explains creation, multi-select, undo/redo, image paste, and navigation. Board content is context only; project changes remain a separate explicit coding-agent action. In MCP Apps hosts that support updateModelContext, the embedded board automatically publishes the latest final board state and a final-state delta to the host's current conversation context. The update is not an operation log and does not trigger a model turn. A '通知 Agent' button, when sendMessage is supported, sends only one short user notification; the state remains in model context. If the host lacks these capabilities or the person uses the standalone PANEL_URL page, ask the AI to call get_board to reread the board.

Features and capabilities supported by this server

Functions exposed to the LLM to take actions

Interactive templates invoked by user choice

Contextual data attached and managed by the client