Introduction
You finish discussing a system design with your AI, and then you open a separate tool to manually redraw everything you just talked about. It's a small interruption, but it breaks your flow every single time. With OpenClaw and CodePic MCP connected, that step goes away — describe what you need in Telegram or Discord, and the AI calls CodePic directly, draws the diagram, and sends you a link.
What Is OpenClaw
OpenClaw can connect messaging channels and agent tools through a gateway. A locally hosted gateway does not mean all data stays local: messages, model requests and remote CodePic operations can cross service boundaries.
Use the current getting-started documentation for installation requirements. This article focuses on the CodePic connection rather than promising that every channel, model and runtime uses the same setup.
Setting Up CodePic MCP
Current OpenClaw documentation places managed outbound servers under mcp.servers, not the older top-level mcpServers example.
- Sign in to CodePic and create an API key from API key settings. Keep it out of chat messages, screenshots and shared repositories.
- In OpenClaw’s Control UI, open Settings → MCP and add a Streamable HTTP server using https://codepic.cc/api/mcp/mcp. Use the scoped configuration editor to supply the Authorization bearer header through the supported secret or environment mechanism for your installed version.
- Check the saved server with the installed version’s MCP status tools, then probe live capabilities. Confirm the CodePic tools appear in the intended agent session; saving a URL is not evidence of a working connection.
- Keep document-changing tools subject to the client’s tool policy. Test with a non-sensitive example and inspect the returned document before using it in a real conversation.
See the official connection guide and configuration reference. The exact UI and runtime projection can vary by version. This guide does not claim an end-to-end test of your installed OpenClaw environment.
In Practice: Drawing Diagrams from Chat
Scenario 1: Creating a Microservices Architecture Diagram from Scratch
You're doing a technical design review and need an architecture diagram — without drawing it by hand.
Send this to your AI in Telegram:
Draw an e-commerce microservices architecture diagram in CodePic.
Components:
- Client: Web, iOS App, Android App
- API Gateway: single entry point, handles auth and routing
- Microservices: User Service, Product Service, Order Service, Payment Service
- Message queue: Kafka, connecting Order Service and Payment Service
- Data layer: PostgreSQL (users/orders), Redis (cache), Elasticsearch (product search)
Use arrows for call direction, dashed arrows for async Kafka messages. Bold the connection between Payment Service and Order Service.
The AI calls CodePic's create_diagram, generates the diagram, and replies with a CodePic link. Open it and the diagram is there.
Not happy with it? Keep going:
Replace Elasticsearch with Meilisearch, add an image storage component (S3) next to Product Service, connect them with a dashed line.
The AI calls update_diagram, makes the change, and sends a new link. You never opened CodePic manually. Nothing was dragged or dropped.
Scenario 2: Iterating on an Existing Diagram
You already have an order processing flowchart. After a team discussion, you decide to add a caching layer and a retry mechanism for payment failures.
In Discord:
Make two changes to the current order processing diagram:
1. Add a caching layer: put Redis cache before the "query order" step. Check cache first — on hit, return immediately; on miss, query the database and write the result back to cache. Mark the cache component with a dashed border.
2. Add a retry mechanism: on payment failure, add a "retry queue" node with a max of 3 retries. After 3 failures, route to a "manual review" branch.
Keep the main flow unchanged — these are additions only.
The AI retrieves the diagram ID, calls update_diagram, adds both pieces to the existing structure, and sends you the updated link.
One tip: when using update_diagram, explicitly say "keep the main flow unchanged, only add X." The AI works from the existing diagram by default, but that phrase reduces the chance of accidental changes.
Who This Is For, and How to Start
Good fit:
- Individual developers with a machine that runs continuously, who want to call AI and generate diagrams from a desktop environment
- Technical teams using Discord or Telegram to collaborate, who want to produce visual diagrams directly in the conversation
Not a good fit:
- Situations that require real-time collaborative diagram editing (CodePic doesn't support that yet)
- Pixel-perfect design work (use a dedicated design tool)
Three steps to get started:
- Install OpenClaw and connect Telegram (fastest to set up, under 5 minutes)
- Get your CodePic API key, add it to
~/.openclaw/openclaw.json - Restart the Gateway, send "draw me a flowchart in CodePic" to test
Docs:
- OpenClaw setup: docs.openclaw.ai
- CodePic MCP configuration: codepic.cc/zh/blog/codepic-mcp-launch
Frequently asked questions
Where should CodePic be configured in current OpenClaw?
Current OpenClaw documentation places managed outbound MCP definitions under mcp.servers. Check the documentation for the installed version and verify live tool discovery.
Does a locally hosted gateway keep all diagram data local?
No. A cloud model, messaging service or remote MCP server may receive the information required for its work. Review each part of the chosen route.
How should I revise an existing diagram safely?
Identify the document, read its current state with get_diagram, request a bounded edit and review the returned diagram before sharing it.
Troubleshoot the connection in layers
Start by separating configuration, connectivity, authentication and tool policy. A server entry appearing in settings proves only that the definition was saved. A successful capability probe shows the server can answer, but a document-changing tool still needs the correct authentication and permission in the actual agent session.
If tools are absent, check whether the intended runtime receives that server and whether filters exclude the tool. If a read-only discovery request works but creation fails, inspect the authentication and authorization result rather than repeatedly reinstalling the client. Keep secrets out of copied logs and screenshots.
When an operation returns a document link, open it and compare the result with the requested components and relationships. A successful tool call is not proof that the diagram communicates the intended architecture. Ask for a bounded correction using the existing document identifier rather than creating a new document for every small edit.
For an update, read the current document first and confirm the intended target. Record a short change request such as “add one queue between the API and worker; keep the other connections.” Review labels, connector direction and any deleted content afterward. If the result is wrong, use the available document recovery or editing workflow; do not assume a chat message automatically reverses the last write.
Finally, test the route in the channel where it will actually be used. A Control UI test does not establish that every messaging session has identical tools, identity or approval behavior. Keep an agreed human review step before sending architecture diagrams to a wider audience.
A shared channel may also have a different audience from a private agent session. Confirm the intended document and readers before posting a view link, and distinguish a draft for review from an approved architecture reference.
