Lucid AI + MCP: Help us build the future 🚀

Thank you for the invitation to share our thoughts ​@cesar m 

I’ve just completed the Maze survey and I hope the input was helpful to your team.

Looking forward to seeing how the MCP evolves and supports the work we do every day.

Happy to share more insights if needed!

Excited to contribute to this research! Just took the survey.

My use case is (in software development) that I’m drawing BPMN diagrams in LucidChart and writing textual specs in Google Docs. I want to read the text and diagrams to Claude Code in order to generate acceptance test procedures, e.g., set up test data for database, etc., for each scenario.

Currently I’ve generate python code to authenticate and download the specification Google Doc, I’m exporting diagrams as PDF from Lucid, and feeding all of them to Claude to do it’s magic.

In MCP, I’d be very interested seeing something that would allow my local Claude Code to connect to Lucid’s BPMN diagram and understand the structural content there without Claude needing to decipher pictures/PDF.

I would want to describe an AWS, Azure, or Google architecture and have it spit out an architecture diagram and read the diagram and make a terraform, ansible script that matched.

In code, you need to a lot of details and usually it doesn’t make sense to add all of the to diagrams, lest they would become unreadable. I recently created a non-trivial GCP architecture with Claude Code and Terraform, and that combination worked great. I’d be happy it I could somehow command Claude to use LucidChart to draw architectural diagrams based on existing Terraform code. Diagrams could be drawn at various levels of abstraction, i.e., overview and detailed.

Thanks for all the thoughtful responses. This thread is already influencing what we prioritize.

​@Ria S , ​@Humas1985 — appreciate the survey responses and the openness to share more. We’re clustering feedback now to identify the most impactful patterns.

​@rocketman , ​@Kbrewer — the direction you’re pointing to is aligned with where we want to go. We’re especially interested in enabling AI to understand structured diagrams, connect information across tools, and support generation workflows in a more intelligent way.

We’re starting with foundational APIs and layering up from there. Please keep sharing edge cases like these. It helps us shape what’s next.

I see some unofficial Lucid MCP servers on Github.  I’d prefer not to spend time on those if possible - do you have an approximate quarter for when you would release v1.0  or a beta of the official Lucid MCP server?

​@jfudge — I don’t have a public date to share yet, but our goal is to get an early version into customers’ hands as soon as possible this year. I’d recommend holding off on third-party versions, since the official release will be supported, secure, and kept up to date. We’ll share more details here as soon as we have a timeline.

It would be nice if you could somehow implement a diff’ing functionality. I mean when you’re modifying code with an AI, you usually have an option to view the proposed changes before applying them. Something similar would be nice in Lucid + AI combination too. Or at least “undo latest changes done by AI via MCP” kind of functionality would be needed. While I’m keen on interacting with diagrams using AI, I wouldn’t want to worry about accidentally creating a mess that takes an hour to clean up.

This is me interacting with Kiro in this case while trying to build an ASCII version of an architectural diagram:

in the archtiecture diagram in section 1.1, the react frontend component should interact with the API GW only.  It doesn't go direct to the Query Engine.  We need to add another layer between the [step funtions, elasticache, query engine] layer and the [users, React Frontend UI, API GW] layer.  This should have the [aws cognito] component in it.  The query engine should then be connected to the [aws cognito] component and to the [api gw] component.  The bottom layer should be ordered as [users, React Frontend UI, API GW] since the [users] interact with the [react frontend ui] which interacts with the [api gw].

This is the sort of conversation I want to have to build Lucid charts via a MCP rather than build them in ASCII

Just came across this thread. ​@cesar m - Any thoughts about the ETA of an official Lucid MCP server release, or should I just ask Claude to roll our own?

​@AJ Van Beest — I don’t have a public date to share yet, but our goal is to get an early version into customers’ hands as soon as possible this year.

We’ll share more details here as soon as we have a timeline.

Thanks again to everyone who’s shared ideas and use cases in this thread — your feedback has directly influenced how we’re designing Lucid’s Model Context Protocol (MCP) Server.

We’ve refined our research based on what we heard and built a short follow-up survey focused on real workflows, trust, and value when connecting AI tools to Lucid securely.

👉 Take the updated 7-minute survey — (https://t.maze.co/411108922)

If you’d like to go deeper, the final screen includes an option to schedule a 30-minute chat to share your experience directly with our team.

Your feedback helps us shape how tools like Claude, Copilot, and Gemini will work inside Lucid — securely and intelligently — as we prepare for Beta.

Thanks for continuing to help us build this right.

Hello ​@cesar m, 

I hope everything is going smoothly, I was wondering if the mcp is developed or do we still need to wait for it?

just completed the updated survey. hope my input helps :)

Hi Cesar, 

I was in a Lucid Legends session today, and I think the MCP server should have a name. For example, my credit union has one named Fran, named after the credit union’s first manager long long ago. And of course, there is Grok on X pulling information from all kinds of servers to provide info for users. 
 

MCP Server sounds very machine vs human when they are interacting with each other. It was just a thought. Ben is going to pass it along, too, since I mentioned it in his meeting. It doesn’t have to be named Teresa either. 😉

Teresa Potts

Has anyone created rules for this MCP? I am just getting started and it would be great if someone already has something, I think this would apply to Claud Code and Cursor.

Hi ​@Ross Hughey, thanks for adding to this thread! Would you mind elaborating a bit on what types of rules you’re envisioning and what it is you’re hoping to accomplish?

I’d love to point you to these great resources we have on the MCP so far as a great starting point to learn what’s currently available:

• 🚀 Introducing the Lucid Model Context Protocol (MCP) server

• Integrate Lucid with AI tools using the Lucid MCP server

I’d love to hear more details on what you're hoping to accomplish with the MCP server!

Sure, just as an example this is a set of rules I had Cursor create for me in the last day of testing. This is very specific to my use case, however another application I have used recently that also has an open source MCP leverages rules as well and it might be a better example of what I would be looking for. 

https://github.com/czlonkowski/n8n-mcp?tab=readme-ov-file#-claude-project-setup

---
description: Lucid MCP diagram creation conventions, swim lane formatting, shape/line/annotation standards
alwaysApply: false
---

# Lucid Diagram Standards

Standards for creating diagrams via the Lucid MCP tools. Ensures consistent formatting across all project diagrams.

---

## Tool Selection

| Tool | When to Use |
|------|-------------|
| `lucid_create_diagram_from_specification` | Precise layouts: swim lanes, flowcharts with specific shapes and connections |
| `lucid_create_diagram_from_description` | Quick conceptual diagrams where exact layout is not critical |
| `fetch` | Retrieve existing document content before creating related diagrams |
| `search` | Find existing diagrams by keyword before creating duplicates |

**Product selection:**

- `lucidspark` for collaborative boards (brainstorming, architecture proposals, meeting artifacts)
- `lucidchart` for formal technical diagrams (ERDs, sequence diagrams, network diagrams)

---

## Swim Lane Conventions

Use horizontal swim lanes (`vertical: false`) with actors stacked top to bottom (initiator at top, downstream systems at bottom).

**Title bar:** `height: 200`, `verticalText: false`

**Standard actor colors:**

| Actor | Header Fill | Lane Fill |
|-------|------------|-----------|
| Law Firm / Client | `#4A90D9` | `#F0F5FF` |
| E-Invoicing Platform | `#7B68EE` | `#F5F3FF` |
| Government Authority | `#E67E22` | `#FFF8F0` |
| Legal Tracker | `#27AE60` | `#F0FFF4` |
| AP System | `#E74C3C` | `#FFF5F5` |

For actors not listed, pick a distinct header color and derive a light tint (10-15% opacity) for the lane fill.

**Minimum sizing:** `w: 2400, h: 1400` for a 5-lane diagram. Scale proportionally for fewer lanes.

---

## Shape Conventions

| Shape Type | Use For | Example |
|------------|---------|---------|
| `terminator` | Start/end points | "Submit e-Invoice", "Send Payload" |
| `process` | Actions and steps | "Receive e-Invoice", "Route to AP" |
| `decision` | Branching logic (Yes/No) | "Approved?" |
| `document` | Data receipt or input | "Receive LEDES Invoice" |
| `text` | Labels and titles (no style property) | "PATH 1: Compliance + AP" |

**Shape fill:** Use a light tint that matches the lane the shape sits in.

**Example:**

```json
{
  "id": "p1_ep_receive",
  "type": "process",
  "boundingBox": {"x": 420, "y": 375, "w": 230, "h": 60},
  "text": "Receive e-Invoice",
  "style": {"fill": {"type": "color", "color": "#EDE7F6"}}
}
```

---

## Line Conventions

- Default line type: `"elbow"` for swim lane diagrams
- **Solid** lines (`"solid"`) for primary/default paths
- **Dashed** lines (`"dashed"`) for alternative/optional paths
- Color-code lines by path or function
- Stroke width: `2` for normal flow, `3` for emphasis (e.g., default rejection path)

**Standard line colors:**

| Path Type | Color | Example |
|-----------|-------|---------|
| Compliance / regulatory | `#4A90D9` (blue) | Path 1 flow lines |
| Legal review | `#27AE60` (green) | Path 2 flow lines |
| Rejection / error | `#E74C3C` (red) | Rejection notification lines |
| Alternative route | `#9B59B6` (purple, dashed) | Credit note alternative |

**Example:**

```json
{
  "id": "line_p1_4",
  "lineType": "elbow",
  "endpoint1": {"type": "shapeEndpoint", "style": "none", "shapeId": "p1_gov_review"},
  "endpoint2": {"type": "shapeEndpoint", "style": "arrow", "shapeId": "p1_ep_route"},
  "stroke": {"color": "#4A90D9", "width": 2, "style": "solid"},
  "text": [{"text": "Approved", "position": 0.5, "side": "top"}]
}
```

---

## Annotation Conventions (Sticky Notes)

Place sticky notes **outside** the swim lane container (below or to the right) so they do not interfere with the flow.

**Color coding:**

| Color | Hex | Purpose | Text Prefix |
|-------|-----|---------|-------------|
| Green | `#A5D6A7` | Issue solved by this design | `"Solves #XX: ..."` |
| Yellow | `#FFF9C4` | Context for impacted issues | `"Context #XX: ..."` |
| Orange | `#FFECB3` | Business logic / configurability | (descriptive) |
| Blue | `#B3E5FC` | Future / roadmap items | `"Future: ..."` |
| Purple | `#E1BEE7` | Trade-offs and considerations | (descriptive) |

**Sticky notes require a `style` property.** Example:

```json
{
  "id": "note_solves_52",
  "type": "stickyNote",
  "boundingBox": {"x": 820, "y": 1560, "w": 310, "h": 130},
  "text": "Solves #52: No double billing risk - only Pagero sends to AP",
  "style": {"fill": {"type": "color", "color": "#A5D6A7"}}
}
```

---

## Layout Standards

1. Include a **title** (`text` shape) and **subtitle** above the swim lane
2. Label parallel paths with `"PATH 1: [name]"` and `"PATH 2: [name]"` text blocks in the top lane
3. Leave **150+ px** below the swim lane for annotation rows
4. Arrange sticky notes in a horizontal row, spaced ~40px apart
5. Group annotations by color (green solved issues first, then yellow context)

---

## Reminders

- `text` shapes do **not** accept a `style` property
- `stickyNote` shapes **require** a `style` property
- `decision` shapes render as diamonds; keep text short (e.g., "Approved?")
- Line endpoint `position` must be on **both** endpoints or **neither** (use smart lines when unsure)
- Shapes are contained by a swim lane when placed within its bounding box boundaries
- The Lucid MCP creates **new documents**; it cannot edit existing pages. Link new documents from existing boards if needed.

---

## Related Rules

- See `core_project_metadata.mdc` for team references and canonical URLs
- See `doc_markdown_style.mdc` for markdown formatting in text annotations
- See `github_issue_creation.mdc` for issue reference conventions used in sticky note annotations
- See `core_rule_attribution.mdc` for attribution format when creating diagrams

​@Ambar D  I posted a reply, but due to the content a mod needs to approve. I think it should be ok but lets see :P I will try posting inline perhaps that will be approved right away. 😁

This is an example of what I created for my own use case, but it should give you an idea:
 

---

description: Lucid MCP diagram creation conventions, swim lane formatting, shape/line/annotation standards

alwaysApply: false

---

# Lucid Diagram Standards

Standards for creating diagrams via the Lucid MCP tools. Ensures consistent formatting across all project diagrams.

---

## Tool Selection

| Tool | When to Use |

|------|-------------|

| `lucid_create_diagram_from_specification` | Precise layouts: swim lanes, flowcharts with specific shapes and connections |

| `lucid_create_diagram_from_description` | Quick conceptual diagrams where exact layout is not critical |

| `fetch` | Retrieve existing document content before creating related diagrams |

| `search` | Find existing diagrams by keyword before creating duplicates |

**Product selection:**

- `lucidspark` for collaborative boards (brainstorming, architecture proposals, meeting artifacts)

- `lucidchart` for formal technical diagrams (ERDs, sequence diagrams, network diagrams)

---

## Swim Lane Conventions

Use horizontal swim lanes (`vertical: false`) with actors stacked top to bottom (initiator at top, downstream systems at bottom).

**Title bar:** `height: 200`, `verticalText: false`

**Standard actor colors:**

| Actor | Header Fill | Lane Fill |

|-------|------------|-----------|

| Law Firm / Client | `#4A90D9` | `#F0F5FF` |

| E-Invoicing Platform | `#7B68EE` | `#F5F3FF` |

| Government Authority | `#E67E22` | `#FFF8F0` |

| Legal Tracker | `#27AE60` | `#F0FFF4` |

| AP System | `#E74C3C` | `#FFF5F5` |

For actors not listed, pick a distinct header color and derive a light tint (10-15% opacity) for the lane fill.

**Minimum sizing:** `w: 2400, h: 1400` for a 5-lane diagram. Scale proportionally for fewer lanes.

---

## Shape Conventions

| Shape Type | Use For | Example |

|------------|---------|---------|

| `terminator` | Start/end points | "Submit e-Invoice", "Send Payload" |

| `process` | Actions and steps | "Receive e-Invoice", "Route to AP" |

| `decision` | Branching logic (Yes/No) | "Approved?" |

| `document` | Data receipt or input | "Receive LEDES Invoice" |

| `text` | Labels and titles (no style property) | "PATH 1: Compliance + AP" |

**Shape fill:** Use a light tint that matches the lane the shape sits in.

**Example:**

```json

{

  "id": "p1_ep_receive",

  "type": "process",

  "boundingBox": {"x": 420, "y": 375, "w": 230, "h": 60},

  "text": "Receive e-Invoice",

  "style": {"fill": {"type": "color", "color": "#EDE7F6"}}

}

```

---

## Line Conventions

- Default line type: `"elbow"` for swim lane diagrams

- **Solid** lines (`"solid"`) for primary/default paths

- **Dashed** lines (`"dashed"`) for alternative/optional paths

- Color-code lines by path or function

- Stroke width: `2` for normal flow, `3` for emphasis (e.g., default rejection path)

**Standard line colors:**

| Path Type | Color | Example |

|-----------|-------|---------|

| Compliance / regulatory | `#4A90D9` (blue) | Path 1 flow lines |

| Legal review | `#27AE60` (green) | Path 2 flow lines |

| Rejection / error | `#E74C3C` (red) | Rejection notification lines |

| Alternative route | `#9B59B6` (purple, dashed) | Credit note alternative |

**Example:**

```json

{

  "id": "line_p1_4",

  "lineType": "elbow",

  "endpoint1": {"type": "shapeEndpoint", "style": "none", "shapeId": "p1_gov_review"},

  "endpoint2": {"type": "shapeEndpoint", "style": "arrow", "shapeId": "p1_ep_route"},

  "stroke": {"color": "#4A90D9", "width": 2, "style": "solid"},

  "text": [{"text": "Approved", "position": 0.5, "side": "top"}]

}

```

---

## Annotation Conventions (Sticky Notes)

Place sticky notes **outside** the swim lane container (below or to the right) so they do not interfere with the flow.

**Color coding:**

| Color | Hex | Purpose | Text Prefix |

|-------|-----|---------|-------------|

| Green | `#A5D6A7` | Issue solved by this design | `"Solves #XX: ..."` |

| Yellow | `#FFF9C4` | Context for impacted issues | `"Context #XX: ..."` |

| Orange | `#FFECB3` | Business logic / configurability | (descriptive) |

| Blue | `#B3E5FC` | Future / roadmap items | `"Future: ..."` |

| Purple | `#E1BEE7` | Trade-offs and considerations | (descriptive) |

**Sticky notes require a `style` property.** Example:

```json

{

  "id": "note_solves_52",

  "type": "stickyNote",

  "boundingBox": {"x": 820, "y": 1560, "w": 310, "h": 130},

  "text": "Solves #52: No double billing risk - only Pagero sends to AP",

  "style": {"fill": {"type": "color", "color": "#A5D6A7"}}

}

```

---

## Layout Standards

1. Include a **title** (`text` shape) and **subtitle** above the swim lane

2. Label parallel paths with `"PATH 1: [name]"` and `"PATH 2: [name]"` text blocks in the top lane

3. Leave **150+ px** below the swim lane for annotation rows

4. Arrange sticky notes in a horizontal row, spaced ~40px apart

5. Group annotations by color (green solved issues first, then yellow context)

---

## Reminders

- `text` shapes do **not** accept a `style` property

- `stickyNote` shapes **require** a `style` property

- `decision` shapes render as diamonds; keep text short (e.g., "Approved?")

- Line endpoint `position` must be on **both** endpoints or **neither** (use smart lines when unsure)

- Shapes are contained by a swim lane when placed within its bounding box boundaries

- The Lucid MCP creates **new documents**; it cannot edit existing pages. Link new documents from existing boards if needed.

---

## Related Rules

- See `core_project_metadata.mdc` for team references and canonical URLs

- See `doc_markdown_style.mdc` for markdown formatting in text annotations

- See `github_issue_creation.mdc` for issue reference conventions used in sticky note annotations

- See `core_rule_attribution.mdc` for attribution format when creating diagrams

Hi ​@Ross Hughey, apologies that your comment was caught up in approval, thanks for such a detailed example here and for explaining that use case.

This is a great question- I am checking in with our product team to see if they have some insight to share with you here, and I hope to have an answer back to you shortly!