Skip to main content
Glama
yahavf6

claude-monet-mcp

by yahavf6
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

What is this?

  • 🎨 Visual thinking, amplified - Some ideas are easier to draw than describe. Sketch freely and let AI see what you mean.

  • ✨ Beautifully simple - A lightweight canvas that does one thing well: bridge your imagination to AI understanding.

  • 🔄 Instant connection - Your strokes flow to AI in real-time via MCP. No exports, no uploads—just draw.

Related MCP server: Overboard Studio

Quick Add

Claude Code

claude mcp add claude-monet -- npx -y claude-monet-mcp

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "claude-monet": {
      "command": "npx",
      "args": ["-y", "claude-monet-mcp"]
    }
  }
}

Cursor

Add to your Cursor MCP settings (Cursor Settings → Features → Model Context Protocol):

{
  "mcpServers": {
    "claude-monet": {
      "command": "npx",
      "args": ["-y", "claude-monet-mcp"]
    }
  }
}
TIP

After adding the server, restart Claude Desktop/Code/Cursor to load the MCP tools.

Manual Installation

If you prefer to run from source:

Prerequisites

  • Node.js 18+

  • pnpm (or npm)

Install and Build

# Clone the repository
git clone https://github.com/yahavfuchs/claude-monet-mcp.git
cd claude-monet-mcp

# Install dependencies
pnpm install

# Build the React app
pnpm run build
IMPORTANT

Runpnpm run build before starting the server for the first time.

Start the Server

pnpm start

The web interface will be available at http://localhost:51423

Configure MCP

Add to your MCP settings:

{
  "mcpServers": {
    "claude-monet": {
      "command": "node",
      "args": ["/path/to/claude-monet-mcp/server.js"]
    }
  }
}

Usage

  1. Start the server - Run pnpm start or use npx claude-monet-mcp

  2. Open the canvas - Navigate to http://localhost:51423 in your browser

  3. Draw your idea - Use Excalidraw tools to sketch rectangles, circles, arrows, text, or freehand

  4. Ask Claude - "Can you see my sketch? What do you think?"

TIP

Keep the browser tab open while chatting with Claude. Your drawings sync in real-time.

Perfect for:

  • Explaining UI layouts visually

  • Sketching architecture diagrams

  • Wireframing ideas quickly

  • Visual communication with Claude

MCP Tools

Tool

Description

get_sketch

Returns the current sketch as SVG text

clear_sketch

Clears the canvas to start fresh

Example:

Claude receives SVG like:
<svg>
  <rect x="100" y="50" width="200" height="100"/>
  <text x="150" y="100">Header</text>
</svg>

Claude understands: "A rectangle labeled 'Header' - this is a header component"

Why SVG instead of images?

  1. Text-based - Claude reads SVG paths directly, no vision model needed

  2. Smaller - No base64 encoding overhead

  3. Accurate - Exact coordinates, no compression artifacts

  4. Simpler - Just strings, no blob conversion

Development

# Development mode (Vite dev server)
pnpm run dev

# Build for production
pnpm run build

# Start MCP server
pnpm start

# Build and start together
pnpm run dev:full

Project Structure

claude-monet-mcp/
├── server.js           # MCP server + Express (~104 lines)
├── src/
│   ├── App.jsx         # Excalidraw React app (~80 lines)
│   ├── App.css         # Styling (~28 lines)
│   ├── main.jsx        # React entry point
│   ├── index.html      # HTML template
│   └── public/         # Logo assets
├── dist/               # Built output (from Vite)
├── vite.config.js      # Build configuration
└── package.json

Why build this?

Existing Excalidraw MCP servers are complex (~2000+ lines) and focused on "Claude creates diagrams". This tool is minimal and focused on "user sketches → Claude reads".

Acknowledgements

Built with excellent open-source technologies:

Contributing

Contributions welcome! This project is intentionally simple to encourage contributions.

License

MIT

Available Tools

2 tools
clear_sketchB

Clear the drawing canvas to start a new sketch

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are present, so the description carries full burden. It states 'Clear the drawing canvas' implying destructive behavior, but lacks details on reversibility, confirmation prompts, or what happens to existing content beyond being cleared.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single concise sentence that directly states the action and purpose. Every word earns its place; no extraneous information.

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

Completeness3/5

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

The description is adequate for a simple, zero-parameter action. However, it does not explain the result (e.g., success feedback, return value) or any side effects. With no output schema, slightly more context about what the user can expect after clearing would improve completeness.

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?

There are no parameters (0), and schema coverage is 100%. The description adds no parameter information, but none is needed. Baseline 3 applies for high coverage, but given zero parameters, a 4 is warranted as no additional meaning is required.

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

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Clear' and the resource 'drawing canvas', indicating a specific action. It distinguishes from sibling 'get_sketch' which retrieves data. However, it does not explicitly differentiate the tool's purpose from alternatives.

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

Usage Guidelines2/5

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

No guidance on when to use or not use this tool. There is no mention of prerequisites, alternatives, or scenarios where this tool should be avoided. Only a single sibling exists but no comparison is provided.

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

get_sketchA

Get the current sketch as SVG. The user can draw rectangles, circles, arrows, text, and freehand. Use this to see what the user drew.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.4/5.0
Behavior4/5

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

The description accurately describes the tool's behavior as returning an SVG of the current sketch. Since no annotations are provided, it carries full burden. It does not mention that the operation is non-destructive, but the sibling's name implies it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only two sentences, both front-loaded with the core purpose and usage. Every word adds value with no redundancy.

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

Completeness4/5

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

For a simple getter tool with no parameters and no output schema, the description adequately explains the return format and content. It could optionally mention that it does not alter state, but this is implied by the sibling tool.

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?

The input schema has zero parameters, and schema description coverage is 100%, so no additional parameter information is needed. Baseline of 4 for zero parameters is appropriate.

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 clearly states that the tool retrieves the current sketch in SVG format and lists drawable shapes, distinguishing it from the sibling tool 'clear_sketch' which clears the sketch.

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?

The description explicitly says 'Use this to see what the user drew,' providing clear context for usage. It does not specify when not to use it, but the sibling context is sufficient for differentiation.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.2
    • First observedclear_sketch
    • First observedget_sketch
Deploy Server
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

TDQS

A3.8/5.0

Scored across 2 tools

Disambiguation5/5

The two tools, clear_sketch and get_sketch, have clearly distinct purposes: one clears the canvas, the other retrieves the current drawing. There is no overlap.

Naming Consistency5/5

Both tool names follow the consistent verb_noun pattern (clear_sketch, get_sketch), making their actions predictable.

Tool Count3/5

With only 2 tools for a drawing server, the count is slightly low but reasonable if the server's scope is limited to clearing and viewing the sketch made by the user.

Completeness4/5

For the apparent purpose of allowing Claude to clear and inspect the user's drawing, the tool surface is mostly complete. However, there might be a minor gap if Claude could benefit from adding elements programmatically.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Napkin

    sshwarts
    A
    license
    Not graded
    quality
    D
    maintenance
    A shared whiteboard for you and your AI agent I wanted my AI agent and me to be able to point at the same thing. Any MCP-capable agent can read the canvas, draw on it, drop thought bubbles, animate elements, and react when you sketch something.
    1
    MIT

  • Overboard Studio

    alona-iaig
    A
    license
    Not graded
    quality
    D
    maintenance
    Create visual whiteboards, diagrams, flowcharts, and project plans from AI conversations. 17 MCP tools for board management, element creation, and real-time collaboration.
    1
    MIT