Lucid AI + MCP: Help us build the future 🚀

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!