sketchboard-excalidraw-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| statusA | Report server identity and which capability groups are wired up yet. This is the one real tool in the day-1 scaffold - everything else is registered but returns an explicit not_implemented result. Return Format{"server": str, "version": str, "capabilities": dict[str, str]} Examplesstatus() |
| render_svgA | Render Excalidraw element JSON to SVG via headless Chromium (Playwright). NOT IMPLEMENTED YET. Day 2 work: port bassimeledath's warm-Chromium exportToSvg approach into sketchboard_excalidraw_mcp/render.py using a locally vendored excalidraw JS bundle (no CDN dependency at runtime). Return Format{"success": False, "error": str, "error_type": "not_implemented", "suggestions": list[str]} |
| mermaid_to_excalidrawA | Convert a Mermaid diagram to Excalidraw elements and optionally render it. NOT IMPLEMENTED YET. Planned to wrap the official @excalidraw/mermaid-to-excalidraw npm package via a small Node/Bun shim rather than reimplementing Mermaid parsing. Return Format{"success": False, "error": str, "error_type": "not_implemented", "suggestions": list[str]} |
| batch_renderA | Batch-render README diagrams across a list of fleet repos. NOT IMPLEMENTED YET. Day 2/3 work: browser-context pool over the one warm Chromium instance (not one page reused sequentially), so a 200-repo run doesn't serialize behind a single tab. Return Format{"success": False, "error": str, "error_type": "not_implemented", "suggestions": list[str]} |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
The four tools have clearly distinct purposes: status for server info, render_svg for single-file rendering, mermaid_to_excalidraw for format conversion, and batch_render for multi-repo processing. Even though three are unimplemented, their intended roles are unambiguous and non-overlapping.
All names use snake_case and mostly follow a verb_noun pattern (render_svg, batch_render), with mermaid_to_excalidraw being a noun_to_noun exception and status being a simple noun. The pattern is mostly consistent and readable, only minor deviations.
Four tools is a well-scoped number for this server's purpose, covering status, single render, conversion, and batch processing. The count is neither too thin nor too heavy, and each tool has a clear intended role.
Three of four tools are marked NOT IMPLEMENTED YET and return explicit not_implemented errors. This creates severe dead ends for any agent attempting real diagram conversion or rendering; the only functional tool is status, leaving the server's stated purpose almost entirely unfulfilled.