How to connect Lucid MCP with Claude Code

Read a Lucid document's visual style to use when creating diagrams. Use when the user asks to match or copy the style of an existing document. Returns a compact style profile and guidance for applying its colors, typography, shapes, connectors, sizing, and spacing. Does not create or modify documents or copy their prose. If the source document is not identified, search for it first. Args: document: Source document UUID or HTTPS Lucid document URL. page_index: Optional one-based page number; omit to analyze all pages.

Reads a resource from this MCP server by URI. When a tool description says to read a resource (e.g. "read lucid://skills/diagram-specification"), use this tool with that URI to retrieve the full content. Call with no arguments to list all available resources and their URIs. The "lucid://skills" resource lists all available skills. Args: resource_uri: The URI of the resource to read (e.g. "lucid://skills/diagram-specification"). Leave empty to list available resources.

Search the user's Lucid account for documents by title/keyword. This is the default tool for a generic "search for X" request. Use it unless the user explicitly wants shapes to insert (`lucid_shape_library`) or text inside a document (`lucid_search_document`). If a document is referenced but not identified, search first. Ask only if more than one plausible match comes back. Args: query: String containing space-separated keywords to be searched for (max 400 characters) product: Optional list of product types to filter by. Valid values: "lucidchart", "lucidspark", "lucidscale" created_start_time: Optional ISO 8601 timestamp to filter documents created after this time (e.g., "2024-01-01T00:00:00Z") created_end_time: Optional ISO 8601 timestamp to filter documents created before this time (e.g., "2024-12-31T23:59:59Z") last_modified_after: Optional ISO 8601 timestamp to filter documents modified after this time (e.g., "2024-01-01T00:00:00Z") owned_by_me: Optional. When true, only return documents you own. Note: ownership can change when a document is moved out of a team folder or transferred to another user, so this reflects current ownership rather than original authorship. Returns: Search results with document titles, IDs, URLs, and parent folder IDs, sorted by relevance. Returns up to 200 results (API maximum).

Retrieves the structured content of a specific Lucid document by its ID. Returns document content organized by pages, each containing spatial regions of diagram elements (flowcharts, ERDs, mind maps, etc.) with their properties. By default, returns the first page of the document. Use page_index to fetch a specific page. The response metadata includes page_count and page_region_counts so you know what pages and regions are available. For large pages with many regions, use region_index to fetch specific spatial regions instead of the entire page. Call with metadata_only=True first when you don't know the document's size — that returns page_count, page_region_counts, title, and edit_url without the content payload, so you can decide whether to fetch by page or by region before paying the size cost. If the response is too large, you MUST ask the user if they would like to fetch the document contents region by region. Args: id: Valid UUID of the document page_index: Optional 1-based page index. Defaults to 1 (first page). region_index: Optional list of 1-based indices selecting spatial regions within the requested page. Each page is independently chunked, so the valid range is 1 through the value in page_region_counts for that page. Pass multiple values (e.g. [1, 3, 5]) to fetch several regions in one call. Omit to fetch all regions on the page. metadata_only: When True, skip fetching content and return only document metadata (page_count, page_region_counts, title, edit_url). Use this to size up a document before deciding how to fetch it.

Locates regions of a Lucid document that contain specific text. Use this BEFORE `fetch` when you're looking for content you can describe with specific words or phrases — it tells you which (pageIndex, regionIndex) pairs contain matches so you can then `fetch` only those regions instead of paging through the whole document. Matching is case-insensitive substring over each region's TextAreas content (shape labels, sticky-note text, etc.). It does NOT match against notes, tags, links, colors, or other metadata. Returns a JSON object of the form: { "matches": { "<query>": [ {"pageIndex": 1, "regionIndex": 3, "context": ["Q3 KPI Tracking"]}, ... ], "<otherQuery>": [] }, "title": "..." } Every query you pass appears as a key in `matches`, even when it has no hits — so you can rely on `matches[query]` without first checking presence. `pageIndex` and `regionIndex` are 1-based and can be passed directly to `fetch` as `page_index` and `region_index`. Args: id: Valid UUID of the document. queries: Non-empty list of literal search terms (1-20 items, each at most 200 characters). Each query is matched independently as a case-insensitive substring; the response groups hits by query.

Creates a new share link for a document with specified permissions. Args: document_id: Valid UUID of the document to share role: Access permission level - one of: "view", "comment", "edit", "editandshare" restrict_to_account: Limit access to account members only (default: True) expires: Optional ISO 8601 timestamp for link expiration (e.g., "2025-12-31T23:59:59Z") allow_anonymous: Allow anonymous access via the share link (default: False) Returns: The acceptUrl string for the created share link. The link's properties (role, restrictToAccount, allowAnonymous, expires, documentId) are also attached as structuredContent so the share-link MCP app can display them.

Share a Lucid document with collaborators by granting them access. This tool searches for users by their email addresses, then grants them the specified collaborator role on the document. Args: document_id: The UUID of the document to share emails: List of email addresses to share the document with (max 100) role: The collaborator role to grant. Options: - "view": View-only access - "edit": Edit access - "editandshare": Edit and share access (default) - "comment": Comment-only access Returns: JSON string with results for each email address, indicating success or failure

Creates a Lucidchart document containing an org chart from structured node data. Use this tool when the user wants to create an organizational chart, team structure, or reporting hierarchy diagram. Provide the people/roles as a flat list of nodes with manager-report relationships. Each node must have: - id: Unique string identifier - name: Person or role name - managerId: ID of the manager node (null or omitted for the top-level person) Optional fields per node: - role: Job title or role description - imageUrl: URL to a profile image There must be exactly one root node (with null/missing managerId). Example nodes: [ {"id": "1", "name": "Alice Smith", "managerId": null, "role": "CEO"}, {"id": "2", "name": "Bob Jones", "managerId": "1", "role": "VP Engineering"}, {"id": "3", "name": "Carol White", "managerId": "1", "role": "VP Marketing"}, {"id": "4", "name": "Dave Brown", "managerId": "2", "role": "Senior Engineer"} ] Args: title: Document title (max 3000 characters) nodes: List of node dicts with id, name, and optional managerId/role/imageUrl fields (max 1000 nodes) Returns: JSON with the created document details including document ID and edit URL

List the user's available card integrations and their connection status. Use this to find out which third-party integrations (e.g. Jira) the user is connected to before attempting any integration-backed action. Returns: A JSON array. Each entry describes one integration: { "integration": str, # e.g. "jira" "instances": [ {"instanceId": str, "name": str, "adapterType": str, "isConnected": bool} ] } Connection is tracked per instance: an instance with isConnected=false is authenticated but not fully connected (its live-sync isn't healthy). An integration with no instances, or no instance with isConnected=true, is not usable yet. In that case tell the user to connect it from the Lucid editor: open a document and use the integration/import panel. Do NOT attempt to authenticate on their behalf, and do NOT fabricate a connect link. # Jira specifics `adapterType` is one of "JiraCloud", "JiraDataCenter", or "JiraGovCloud".

Import records from a third-party integration as linked cards. You MUST call `lucid_list_integrations` first to obtain `instance_id` — it is the exact `instanceId` field returned for the desired integration instance, not a free-form string, and cannot be guessed from context. Args: document_id: UUID of the Lucid document to add cards to. integration_id: Which integration the records live in. Today only "jira" is supported. instance_id: The `instanceId` field from a `lucid_list_integrations` entry, identifying which connected instance of `integration_id` to pull records from. Must come from `lucid_list_integrations`; do not construct it. record_keys: Integration-specific identifiers for the records to import (e.g. Jira issue keys like ["MCP-1", "MCP-2"]). page_id: Page to drop the cards on (defaults to the first page). x: Top-left x coordinate of the first card. Defaults to 0. y: Top-left y coordinate of the first card. Defaults to 0. layout: One of "grid", "row", "column". Defaults to "grid". If the user is not connected to the requested integration instance, returns `{status: "not_connected", connect_url, ...}` — send the user to `connect_url` (their Lucid Apps & Integrations page) to connect. Do NOT attempt to authenticate on their behalf. Returns: JSON with `{success, blockIds, dataSourceId, errors}` on success, or a structured `{status: "not_connected" | "unsupported_integration", ...}` response when the precondition isn't met. `errors` is a list of `{recordKey, error}` entries for keys that could not be imported or whose AddBlock op failed; this tool returns partial success when only some keys fail.

Creates a Lucid document using the Standard Import format (.lucid file). When the user requests a diagram without explicitly asking for Mermaid or a diagram from existing Mermaid source code, prefer creating the diagram directly in Lucid over generating Mermaid code in the conversation. The user does not need to explicitly name Lucid. If the user explicitly requests Mermaid source code as the output, honor that request; you should then offer to import it into Lucid. Do not generate Mermaid solely as an intermediate step to call lucid_create_diagram_from_mermaid. Follow the prerequisites and intent rules below when creating a Lucid document. PREFLIGHT HARD GATE: - STOP and use lucid_convert_svg_to_diagram instead if an SVG of the diagram exists. Do NOT hand-author Standard Import JSON when SVG is available. - If Mermaid source code already exists in the conversation or a user-provided file and the user asks to create, render, visualize, or share a diagram from it, use lucid_create_diagram_from_mermaid instead (or lucid_create_sequence_diagram for sequence diagrams and lucid_create_erd for ERDs). The user does not need to explicitly name Lucid or request a conversion. - If this tool description appears truncated, summarized, quoted, or incomplete, first try to retrieve, expand, or read the full tool definition before deciding whether to call this tool. - If the full tool definition cannot be retrieved, use the most complete visible description available, but do not treat missing, hidden, summarized, or truncated text as permission to ignore any visible MUST, REQUIREMENT, HARD GATE, or PREREQUISITE instruction. - Read: lucid://skills/diagram-specification - Reading lucid://skills/diagram-specification is required before every call to this tool. - Do not call this tool until all visible hard prerequisites have been satisfied. - Do not call this tool until any available fuller tool-definition text has been read. AUTHORITY MODEL: - The full, untruncated tool description is authoritative for WHEN to call this tool when it is available, including intent classification, collaborative planning behavior, source/input dependency handling, clarification behavior, default generation behavior, and prerequisite handling. - If the full tool description cannot be retrieved, the most complete visible description is authoritative, but visible requirements remain binding and missing text must not be interpreted as permission to proceed. - The resource at lucid://skills/diagram-specification is authoritative for HOW to construct the standard_import_json argument. - Do not duplicate, infer, or guess the Standard Import JSON format from this tool description. Read and follow lucid://skills/diagram-specification for supported shapes, line syntax, container behavior, assisted layout rules, validation constraints, and all other formatting requirements. - Reading the referenced resource satisfies formatting/specification prerequisites. It does not replace the tool description's behavioral rules about when to call the tool, when to plan collaboratively, when to check for missing source/input dependencies, or when to ask clarifying questions. EXECUTION ORDER: A. Honor visible hard prerequisites. B. If the visible tool description appears truncated or incomplete, try to retrieve, expand, or read the full tool definition. C. If the full tool definition cannot be retrieved, continue only with the most complete visible description available and keep all visible MUST/REQUIREMENT/HARD GATE/PREREQUISITE instructions binding. D. Read all required referenced resources, including lucid://skills/diagram-specification. E. Use the full available tool description, or the most complete visible description if the full definition cannot be retrieved, to decide WHEN to call the tool. F. Classify the user's intent. G. Apply intent precedence: collaborative planning beats default generation. H. Apply the source/input dependency gate. If required referenced source content is missing or inaccessible, ask for it and do not generate. I. If generation is appropriate, construct and validate standard_import_json using lucid://skills/diagram-specification. J. Call the tool. SOURCE / INPUT DEPENDENCY GATE: Before generating, check whether the requested diagram depends on external, user-provided, uploaded, attached, linked, selected, or previously referenced content. A request depends on referenced source content when the user asks for a diagram based on content such as: - "my file" - "the file" - "the uploaded file" - "the attached document" - "this PDF" - "this spreadsheet" - "this image" - "this screenshot" - "the link" - "this URL" - "the document I mentioned" - "the data" - "the dataset" - "the spec" - "the text above" - "the previous diagram" - "the selected content" If the referenced source content is not actually available in the conversation, tool context, connected source, or provided arguments, do NOT generate a substitute, generic, or placeholder diagram. Ask exactly one short question requesting the missing source or clarifying what content to use. If the referenced source content is available, inspect or use that content before generating, unless another higher-priority rule requires collaborative planning or clarification first. This gate takes precedence over ordinary generation. A missing referenced source means the request is not an ordinary request, even if a plausible diagram type can be inferred. Do not confuse missing referenced content with ordinary subject matter. For example, "Create a diagram about a file upload workflow" is an ordinary generation request because "file upload workflow" is the subject, not a missing referenced file. Examples: - User: "Create a diagram about my file." No file is available. Correct: ask the user to upload or link the file. - User: "Make a flowchart from the attached PDF." No PDF is available. Correct: ask for the PDF. - User: "Create a diagram from this spreadsheet." A spreadsheet is available. Correct: inspect/use the spreadsheet, then generate if appropriate. - User: "Create a diagram about a file upload workflow." Correct: generate, because the user named the workflow as the subject. INTENT PRECEDENCE: Before generating, classify the user's request. Collaborative planning mode has precedence over default generation. Enter collaborative planning mode when the user explicitly asks the assistant to help with the planning, brainstorming, design, thinking, mapping, or iteration process before or while creating the diagram. Trigger collaborative planning mode for phrases such as: - "help me plan..." - "help me design..." - "help me brainstorm..." - "help me think through..." - "help me work through..." - "help me map out..." - "help me iterate..." - "let's plan..." - "let's design..." - "let's brainstorm..." - "let's map out..." - "let's iterate..." - "work with me to..." - "before you generate..." - "before creating..." In collaborative planning mode: 1. Do NOT create the diagram immediately. 2. Ask focused planning questions about the diagram type, subject, key elements, audience, level of detail, and desired output. 3. Propose a concise draft diagram spec or outline for confirmation. 4. Generate only after the user confirms, provides enough direction, or asks you to proceed. Do NOT enter collaborative planning mode merely because the diagram topic contains planning-related, brainstorming-related, design-related, or mapping-related words. Bare content phrases such as "planning diagram," "project plan," "roadmap," "brainstorming board," "design flow," "map out the process," or "process map" can be ordinary generation requests if the user is asking for a diagram about that subject rather than asking the assistant to collaborate on the planning process. ORDINARY REQUESTS: An ordinary request is a request where the user primarily asks to create, make, generate, build, or draw a diagram and provides enough information to identify: 1. a plausible diagram type, 2. a concrete or reasonably inferable subject, and 3. any referenced source content needed to create the requested diagram is available. A request is not ordinary if it depends on missing referenced content such as an unuploaded file, missing attachment, unavailable link, absent data, inaccessible selected content, or unavailable prior context. For ordinary requests, generate the diagram immediately using sensible defaults. Do NOT ask clarifying questions for ordinary requests, because users expect this tool to produce a diagram, not start a planning conversation. Examples of ordinary requests: - "Create a flowchart with Start, Decision, and End connected by arrows." - "Build a BPMN process with a start event and parallel tasks." - "Create a project planning flowchart." - "Make a mind map for a marketing launch plan." - "Create a diagram that maps out our onboarding process." - "Generate a simple architecture diagram for a web app." - "Create a roadmap diagram for Q3 planning." - "Create a diagram about a file upload workflow." Examples that require collaborative planning first: - "Create a diagram and help me plan." - "Help me plan a project flowchart." - "Let's map out the onboarding process before creating the diagram." - "Work with me to design the architecture diagram." - "Before you generate, help me think through the process." Examples that require missing source/input clarification first: - "Create a diagram about my file." when no file is available. - "Make a flowchart from the attached PDF." when no PDF is attached. - "Create a diagram from this spreadsheet." when no spreadsheet is available. - "Generate a process map based on the link." when no link is provided or accessible. CLARIFICATION: Ask exactly ONE short clarifying question, then generate, if any of the following are true: 1. The request is internally contradictory, such as "create a sequence diagram of our org structure." 2. The request is so abstract that no reasonable default exists, such as "make me a diagram," meaning you cannot name both a concrete subject and a plausible diagram type. 3. Required referenced source content is missing or inaccessible, such as an unuploaded file, missing attachment, unavailable link, absent data, inaccessible selected content, or unavailable prior context. 4. Two defensible interpretations would produce substantively different diagrams and the user signaled they care about correctness with words such as "important," "for a presentation," "get it right," or similar. Otherwise, generate now and state your assumptions in one line alongside the result so the user can redirect. Example: "Generated as a flowchart with 5 stages; say 'change' to adjust." TOOL OUTPUT: This tool creates a .lucid ZIP file containing a document.json built from standard_import_json. This tool runs the checks in lucid://skills/diagram-specification over your JSON before it creates anything, and treats their two kinds of finding differently. Structural findings - a missing required field, a value outside an enum, a duplicate id, an endpoint pointing at a shape that is not on the page, a relative position pinned on only one endpoint, a malformed color - describe JSON the importer rejects. The tool reports those instead of creating a document, naming the page, the item, and the field, because the API answers such a request with a bare 400 that names nothing. Fix what it lists and call the tool again. Layout findings - text that renders small, shapes that collide, connectors that cross unrelated shapes, labels that land on something - describe a document that imports and looks wrong. Those never block creation. They come back in a bounded "input_preflight" report on the response, whose "truncated" and "skipped_checks" fields say whether the report is incomplete. When use_assisted_layout is true the report covers only what survives import - text fit, colors, and structure - because assisted layout replaces the coordinates you supplied; the position checks (shape clearance, containment, connector paths, label placement) run only when use_assisted_layout is false. To see every check against the JSON you wrote, including the position checks, call lucid_validate_diagram_specification. Do not attempt to guess the Standard Import JSON format. The API validates strictly. Invalid or unsupported JSON can cause import failure. Use lucid://skills/diagram-specification as the source of truth for all Standard Import JSON formatting, validation, layout, and supported-shape details. SHAPE NAMES: The standard import format requires the same canonical class names as lucid_add_block, so guessing them will fail validation. Use lucid://skills/diagram-specification as the source of truth for supported shapes and their class names. (The lucid_shape_library / lucid_shape_details discovery tools require a document_id and operate on an existing document, so they cannot be used to pre-validate class names for this tool, which creates a new document.) Args: title: The title for the new document. standard_import_json: JSON string in Lucid Standard Import format. Construct this according to lucid://skills/diagram-specification. product: Target product, either "lucidchart" or "lucidspark". use_assisted_layout: Auto-arranges shapes after import when true by default. See lucid://skills/diagram-specification for when to set this true or false. Size Limits: - Total document.json: 2MB maximum. - Use concise JSON.

Check Standard Import JSON for layout problems before creating a document. Runs the GEOMETRY AND TEXT PREFLIGHT rules from lucid://diagram-specification over the JSON you are about to pass to lucid_create_diagram_from_specification and reports two kinds of problem. Structural mistakes fail the import outright: a page or shape or endpoint missing a field the importer requires, a shape type or endpoint style outside its enum, a duplicate id, an endpoint pointing at a shape that is not on the page, a relative position pinned on only one endpoint, a malformed color. The API answers these with a bare 400 that names nothing, so the findings name the page, item, and field instead. lucid_create_diagram_from_specification refuses to create a document while any of them stand. Layout mistakes import successfully and look wrong: text that will render smaller than its neighbors', shapes that collide, shapes that cross a container or lane edge, connectors that cross shapes they do not connect, labels that land on a shape or on another label, and duplicate labels on connectors that share an endpoint. This tool does not create, modify, or upload anything. It reads the JSON you give it and returns a report. A clean report means these checks found nothing, not that the diagram is good; where a check does not cover your JSON the report says so in its own finding, so read "skipped_checks" and any *-preflight-skipped finding before treating the page as verified. In particular, connector path and label geometry is modeled for straight lines only. Use it when you have hand-authored the JSON and want the geometry checked before spending a document on it. Fix the findings, run it again, then call lucid_create_diagram_from_specification. Args: standard_import_json: JSON string in Lucid Standard Import format. Returns: JSON with "error_count", "warning_count", a human-readable "summary", and a bounded "findings" array. Each finding names the "rule" it came from, the "page_id" and "subject_ids" it applies to, what is wrong, and a suggested fix. "truncated" and "skipped_checks" identify an incomplete report, while the limit and comparison fields explain the work bounds used.

Creates a Lucid document from existing Mermaid code at the user's request. STOP. Read this ENTIRE description before calling. The rules below are load-bearing — skipping them produces broken documents or wastes the user's tokens. Re-read on every call; don't rely on memory. Use this tool with Mermaid source code already present in the conversation or a user-provided file, including previously shared assistant-generated Mermaid that the user now wants to import. When the user asks to create, render, visualize, or share a diagram from that code, use this tool. The user does not need to explicitly name Lucid or request a conversion. Do not generate Mermaid solely as an intermediate step to call this tool. When the user requests a diagram without asking for Mermaid or a diagram from existing Mermaid source code, prefer creating the diagram directly in Lucid using lucid_create_diagram_from_specification over generating Mermaid code in the conversation. Follow that tool's prerequisites and intent rules. If the user explicitly requests Mermaid source code as the output, honor that request; you should then offer to import it into Lucid. If the user asks only to explain, review, or debug Mermaid code, answer that request without creating a document unless they also ask to see the diagram. For sequence diagrams, use lucid_create_sequence_diagram. For ERDs, use lucid_create_erd. Args: title: The title for the new document. mermaid_markup: Mermaid source code the user wants to import (must contain a valid Mermaid diagram). product: Target product - "lucidchart" or "lucidspark". Defaults to "lucidchart".

Creates a Lucid document containing a mind map from structured node data. Use this tool when the user wants to create a mind map or hierarchical topic diagram. Provide the topics as a flat list of nodes with parent-child relationships. For sticky notes, brainstorms, or boards grouped by theme, create a Lucidspark document using lucid_create_diagram_from_specification, and then use lucid_add_block instead. Each node must have: - id: Unique string identifier - text: Display text for the node - parentId: ID of the parent node (null or omitted for the root node) There must be exactly one root node (with null/missing parentId). Example nodes: [ {"id": "1", "text": "Main Topic", "parentId": null}, {"id": "2", "text": "Subtopic A", "parentId": "1"}, {"id": "3", "text": "Subtopic B", "parentId": "1"}, {"id": "4", "text": "Detail A1", "parentId": "2"} ] Args: title: Document title (max 3000 characters) nodes: List of node dicts with id, text, and optional parentId fields (max 1000 nodes) product: Target product - "lucidchart" (default) or "lucidspark" Returns: JSON with the created document details including document ID and edit URL

Creates a Lucid document containing a UML sequence diagram from PlantUML markup. REQUIREMENT: Before attempting to use this tool, you MUST read the resource at lucid://skills/sequence-diagram-specification for details on participant types, arrows, syntax, and examples. Use this tool when the user wants to create a UML sequence diagram showing interactions between participants over time. Provide the diagram definition using PlantUML sequence diagram syntax. Styling: Diagrams are automatically styled with Lucid blue theme colors (blue participants, blue arrows, light blue fills). You do not need to add color directives for a good-looking diagram. However, you can optionally override colors on individual elements. Args: title: Document title (max 3000 characters) markup: PlantUML sequence diagram markup (max 50KB) product: Target product - "lucidchart" (default) or "lucidspark" Returns: JSON with the created document details including document ID and edit URL

Creates a Lucid document containing a data-backed Entity Relationship Diagram (ERD). Use this tool when the user wants to create an ERD / database schema diagram from a set of entities (tables) and the foreign-key relationships between them. If the user provides raw SQL DDL, a CSV schema, or a Salesforce export, convert it into the structured `entities` / `relationships` form described below. The result is a real, editable ERD: each entity becomes an editable entity table and each relationship becomes a crow's-foot foreign-key line. The schema is stored as ERD data on the document, not as loose shapes. Each entity must have: - id: Unique string identifier (referenced by relationships) - name: Entity / table name (must be unique) - attributes: List of columns, each with a 'name' and optional 'type' and 'key' (e.g. "PK" for a primary key) Each relationship must have: - from: id of the entity that holds the foreign key (the "many" side) - to: id of the referenced entity (the "one" side) - fromAttribute (optional): the FK column on `from` - toAttribute (optional): the referenced PK column on `to` - fromCardinality / toCardinality (optional): one of one, many, zeroOrOne, zeroOrMore, oneOrMore, exactlyOne - label (optional): relationship label Example entities: [ {"id": "user", "name": "User", "attributes": [ {"name": "id", "type": "uuid", "key": "PK"}, {"name": "email", "type": "varchar"} ]}, {"id": "post", "name": "Post", "attributes": [ {"name": "id", "type": "uuid", "key": "PK"}, {"name": "author_id", "type": "uuid"} ]} ] Example relationships: [ {"from": "post", "to": "user", "fromAttribute": "author_id", "toAttribute": "id", "fromCardinality": "many", "toCardinality": "one", "label": "written by"} ] Args: title: Document title (max 3000 characters) entities: List of entity dicts with id, name, and attributes (max 200 entities) relationships: List of relationship dicts referencing entity ids product: Target product - "lucidchart" (default) or "lucidspark" Returns: JSON with the created document details including document ID and edit URL

Internal tool for MCP Apps extension only. Creates an embed for a Lucid document, returning an embed ID.

Internal tool for MCP Apps extension only. Creates a session token for an existing embed, returning a token and embed URL.

Exports a Lucid document page as a PNG image. To crop the image, pass a bounding_box whose x, y, w, and h fields correspond directly to BoundingBox values returned by lucid_fetch. The box can describe one shape or a larger region containing multiple shapes.

Fetches the source image attached to a specific item in a Lucid document.

Add a new block (shape) to a Lucid document. DISCOVERY: Use lucid_shape_library to find valid block_type values for the target document, and lucid_shape_details to fetch a shape's default size, colors, and text-area names before calling this tool. Hallucinated class names produce 400 errors. Args: document_id: UUID of the document to modify block_type: Block class name. Examples: StickiesStickyNoteBlock, TextBlock, SparkFrameBlock, LucidCardBlock, RectangleBlock, ShapeDiamondBlock, ShapeCircleBlock x: X coordinate position (default 0) y: Y coordinate position (default 0) text: Text content for the block text_areas: Named text-area content updates, as a non-empty list of {"key": str, "text": str}. Use this for shapes with multiple text areas. Mutually exclusive with text. width: Block width in pixels height: Block height in pixels fill_color: Fill color in #RRGGBB format line_color: Border color in #RRGGBB format line_width: Border width stroke_style: Border style — one of "solid", "dashed", "dotted", "dashdot", "dashdotdot", "dashed24", "dashed32", "dashed44", "dashlongdash", "dotdotdot", "longdash" rotation: Rotation in degrees text_align: Horizontal text alignment — "left", "center", or "right" text_v_align: Vertical text alignment — "top", "middle", or "bottom" container_id: Item ID of a container block to place this block inside page_id: Page ID to add the block to (defaults to first page if omitted) bold: Whether to make the text bold italic: Whether to make the text italic underline: Whether to underline the text font_size: Font size in points (e.g. 14) text_color: Text color in #RRGGBB format strike: Whether to strikethrough the text superscript: Whether to make the text superscript subscript: Whether to make the text subscript font_family: Font family name (e.g. "Arial"); canvas falls back if unknown highlight_color: Text highlight color in #RRGGBB format link: Hyperlink to attach to the block. Accepts the same inputs the canvas "Link to" field accepts: an http(s) or ftp URL, a bare domain like "www.example.com" (auto-prefixed with http://), or the API-only forms "mailto:<email>" and "page://<pageId>". The page id form references a page in the same document. auto_font_size: Toggles Lucid's auto-fit-to-shape font sizing on the new block. True enables it (text resizes to fit the shape); False disables it (text keeps an explicit point size); omitted uses the block class's default. Providing a concrete font_size automatically disables auto-font-size, so callers do not need to also pass auto_font_size=False alongside a font_size. Mutually exclusive with a non-null font_size when set to True. Returns: JSON with success status and new itemId Example: Add a blue sticky note with bold text at position (200, 150): lucid_add_block( document_id="8fb1756d-d7f1-4f8c-933a-40e30fa5d102", block_type="StickiesStickyNoteBlock", x=200, y=150, text="Hello world", fill_color="#FFD700", bold=True, )

Add a dynamic table to a Lucid document. Dynamic tables organize items into rows and columns and can be used for matrices, grids, kanban-style boards, planning tables, and prioritization maps. The table is created empty; add shapes/cards separately after the table exists. Args: document_id: UUID of the document to modify x: X coordinate position for the table's top-left placement (default 0) y: Y coordinate position for the table's top-left placement (default 0) rows: Optional row labels. If omitted, the canvas creates default rows. columns: Optional column labels. If omitted, the canvas creates default columns. page_id: Page ID to add the table to (defaults to first page if omitted) Returns: JSON with success status and generatorId for the new dynamic table Example: Create a simple priority matrix: lucid_add_dynamic_table( document_id="8fb1756d-d7f1-4f8c-933a-40e30fa5d102", x=100, y=100, rows=["High impact", "Low impact"], columns=["Low effort", "High effort"], )

Add existing canvas blocks to a dynamic table. The generator's grouping logic places each block in the correct row/column based on its pivot-field value. Blocks whose pivot field does not match any row/column label land in the table's default cell. Args: document_id: UUID of the document containing the dynamic table generator_id: ID of the dynamic table generator (use the fetch tool to get the generator ID from the document) block_ids: IDs of existing blocks on the canvas to add to the table Returns: JSON with success status, number of blocks added, and an optional error message if some or all blocks could not be added.

Discover shapes/blocks available to INSERT into a Lucid document. This does NOT find documents or text inside a document. To find a document by name use `search`; to find text within one open document use `lucid_search_document`. Only use this tool when the user wants a shape to add to a diagram. Use this tool to find valid block class names before calling lucid_add_block or lucid_edit_item on an existing document; hallucinating class names will produce 400 errors and this tool returns the canonical list. Note: this requires a document_id and operates on an existing document, so it cannot pre-validate class names for lucid_create_diagram_from_specification (which creates a new document) — for that flow, use the lucid://skills/diagram-specification resource as the canonical shape reference. Modes (all driven by the same call): - No params: lists every visible shape library by id and name. - libraryId only: lists groups (folders) within that library, with shapes inlined when the library has a single group. - libraryId + groupIds: returns the shapes within the specified groups. - searchTerm: searches across libraries (or within libraryId if also provided) and returns matching shapes. Cannot be combined with groupIds. The no-param library listing is paginated: when the response includes a NextPageToken, pass it back as page_token to fetch the next page of libraries. After narrowing to a candidate shape, call lucid_shape_details with its className to get default size/colors and any custom properties before passing it to add/create tools. Args: document_id: UUID of the document context (libraries available depend on product and the user's allow-listed libraries). search_term: Optional free-text query against shape names and keywords. library_id: Optional library identifier from a previous response. group_ids: Optional list of group identifiers within library_id; only valid when library_id is also provided (groups belong to a specific library). page_token: Optional pagination cursor; pass the NextPageToken from a previous no-param listing response to fetch the next page of libraries. Returns: JSON string from the underlying tool (success/result envelope).

Get default size, colors, and advanced/text-area properties for one or more shape classes. Use this tool after lucid_shape_library has narrowed to candidate class names. The returned details (default fill/line colors, default size, advanced property descriptors, and text-area names) tell you which optional fields lucid_add_block and lucid_edit_item can sensibly omit (defaults applied) versus which named text areas the shape supports. Unknown class names produce a per-shape error in the response rather than failing the whole call. Args: document_id: UUID of the document context (so libraries scoped to that product and the user's custom libraries are available for lookup). class_names: List of shape class names to inspect (e.g. "StickiesStickyNoteBlock"). Returns: JSON string from the underlying tool (success/result envelope).

Edit the metadata/settings of an existing dynamic table. Updates the reactive settings of a dynamic-table generator: the agile capacity-planning and load-tracking-graphic toggles, and the row/column group-by fields. Only the parameters you provide are changed; omitted parameters are left as-is. Group-by fields accept a field name (e.g. "status", "sprint", "assignee", "priority") or "none" to remove that grouping. An invalid field name returns an error listing the valid options for that table. Standard data fields (status, assignee, priority, parent, estimate, project, reporter, sprint, team, work item type) pivot on the live data-source value. Add the cards (e.g. via lucid_add_items_to_dynamic_table or lucid_import_integration_cards) BEFORE setting the pivot or you will get a validation error. The table will not automatically add cards if you hit that error; add the cards and call this tool again. Args: document_id: UUID of the document containing the dynamic table. generator_id: ID of the dynamic table generator (from the fetch/canvas-query tools). enable_agile_capacity_planning: Toggle agile capacity planning on or off. show_load_tracking_graphic: Toggle the load-tracking graphic on or off. column_group_by_field: Field to group columns by, or "none" to remove column grouping. row_group_by_field: Field to group rows by, or "none" to remove row grouping. Returns: JSON string from the underlying tool (success/error envelope).

Add a new line to a Lucid document, connecting two points or shapes. Each endpoint is either: - A position endpoint: provide endpoint_x and endpoint_y (absolute canvas coords). - A shape endpoint: provide endpoint_shape_id. STRONGLY PREFER setting endpoint_auto_link=True for shape endpoints — the canvas will attach the line to the best side of the shape based on the line's direction and will re-route automatically as the shape is moved or resized. This is almost always the right choice when connecting two shapes and removes the need to reason about which side the line should enter from. Only set endpoint_position_x/y (a 0–1 relative coordinate on the shape) when you need a specific attachment point on the shape — for example when the user explicitly requests "connect to the top of the box" or when the line must terminate at a fixed anchor. If you do set explicit positions, avoid the default center (0.5, 0.5) because the line will overlap text inside the shape; pick a side instead (e.g. position_x=0, position_y=0.5 for the left edge). Use the fetch tool to get shape IDs from the document. Args: document_id: UUID of the document to modify endpoint1_x: X coordinate of the line's start point endpoint1_y: Y coordinate of the line's start point endpoint1_shape_id: Item ID of the shape to connect the start to endpoint1_position_x: Relative X position on start shape (0=left, 1=right, default 0.5) endpoint1_position_y: Relative Y position on start shape (0=top, 1=bottom, default 0.5) endpoint2_x: X coordinate of the line's end point endpoint2_y: Y coordinate of the line's end point endpoint2_shape_id: Item ID of the shape to connect the end to endpoint2_position_x: Relative X position on end shape (default 0.5) endpoint2_position_y: Relative Y position on end shape (default 0.5) line_color: Line color in #RRGGBB format line_width: Line width in pixels stroke_style: Line style — one of "solid", "dashed", "dotted", "dashdot", "dashdotdot", "dashed24", "dashed32", "dashed44", "dashlongdash", "dotdotdot", "longdash" text: Label text on the line page_id: Page ID to add the line to (defaults to first page if omitted) line_shape: Line routing — exactly one of "elbow" (right-angle), "diagonal" (straight), "curve" (smooth Bezier), or "cyclical" (loop). Omit to let the canvas pick its default routing. Set explicitly to "elbow" to force right-angle even when the canvas would default elsewhere. When the user says "curved" or "smooth" → "curve"; "straight" or "direct" → "diagonal"; "right angle" or "orthogonal" → "elbow"; "loop" → "cyclical". endpoint1_style: Arrow/terminator at the start. Case-sensitive. Examples: "None", "Arrow", "Hollow Arrow", "Open Arrow", "Diamond", "Circle One". Read resource lucid://endpoint-styles for the full list (UML, BPMN, ERD). endpoint2_style: Arrow/terminator at the end (same allowed values). endpoint1_auto_link: Only applies when endpoint1 connects to a shape. STRONGLY PREFERRED when connecting to a shape: set to True and the canvas picks the optimal side of the shape for the line to attach to and automatically re-routes when the shape moves or resizes. Overrides endpoint1_position_x/y when True. Leave False/unset only when you need to pin the endpoint to a specific spot on the shape. endpoint2_auto_link: Same as endpoint1_auto_link, for the end endpoint. Strongly preferred when endpoint2 connects to a shape. bold: Whether to make the label text bold italic: Whether to italicize the label text underline: Whether to underline the label text font_size: Label font size in points (e.g. 14) text_color: Label text color in #RRGGBB format strike: Whether to strikethrough the label text superscript: Whether to make the label text superscript subscript: Whether to make the label text subscript font_family: Label font family name (e.g. "Arial"); canvas falls back if unknown highlight_color: Label highlight color in #RRGGBB format Returns: JSON with success status and new itemId Example: Connect two shapes with a curved red arrow and a bold label: lucid_add_line( document_id="8fb1756d-d7f1-4f8c-933a-40e30fa5d102", endpoint1_shape_id="kydGSpnbx.C4", endpoint1_auto_link=True, endpoint2_shape_id="mydGB1ri3RCq", endpoint2_auto_link=True, line_shape="curve", line_color="#FF0000", endpoint2_style="Arrow", text="connects to", bold=True, )

Delete one or more blocks or lines from a Lucid document. This action is destructive and cannot be undone via the API. Use the fetch tool first to get item IDs from the document. Args: document_id: UUID of the document to modify item_ids: List of item IDs to delete Returns: JSON with success status, deletedCount, and any errors Example: lucid_delete_items( document_id="8fb1756d-d7f1-4f8c-933a-40e30fa5d102", item_ids=["FxdGNC-3_L46", "LYdG8~L0mHE-"], )

Edit an existing block or line in a Lucid document. Use the fetch tool first to get item IDs from the document. For blocks: use x, y, width, height to move/resize. For lines: use endpoint params to reposition endpoints (same as lucid_add_line). Do not mix block position params with line endpoint params. Args: document_id: UUID of the document to modify item_id: ID of the item to edit text: New text content text_areas: Named text-area content updates, as a non-empty list of {"key": str, "text": str}. Use this for shapes with multiple text areas. Mutually exclusive with text. fill_color: Fill color in #RRGGBB format line_color: Border/line color in #RRGGBB format line_width: Border/line width in pixels stroke_style: Border/line style — one of "solid", "dashed", "dotted", "dashdot", "dashdotdot", "dashed24", "dashed32", "dashed44", "dashlongdash", "dotdotdot", "longdash" rotation: Rotation in degrees text_align: Horizontal text alignment — "left", "center", or "right" text_v_align: Vertical text alignment — "top", "middle", or "bottom" x: Absolute X position (blocks only) y: Absolute Y position (blocks only) width: Width in pixels (blocks only) height: Height in pixels (blocks only) endpoint1_x: X coordinate of the line's start point endpoint1_y: Y coordinate of the line's start point endpoint1_shape_id: Item ID of the shape to connect the start to endpoint1_position_x: Relative X position on start shape (0=left, 1=right) endpoint1_position_y: Relative Y position on start shape (0=top, 1=bottom) endpoint2_x: X coordinate of the line's end point endpoint2_y: Y coordinate of the line's end point endpoint2_shape_id: Item ID of the shape to connect the end to endpoint2_position_x: Relative X position on end shape endpoint2_position_y: Relative Y position on end shape bold: Whether to make the text bold italic: Whether to make the text italic underline: Whether to underline the text font_size: Font size in points (e.g. 14) text_color: Text color in #RRGGBB format strike: Whether to strikethrough the text superscript: Whether to make the text superscript subscript: Whether to make the text subscript font_family: Font family name (e.g. "Arial"); canvas falls back if unknown highlight_color: Text highlight color in #RRGGBB format locked: Lock or unlock the item (any item type). True restricts editing/moving; False unlocks; omit to leave the lock state unchanged. line_shape: Lines only — routing for the line: "elbow" (right angles), "diagonal" (straight any-angle), "curve" (smooth Bezier), or "cyclical" (loop). endpoint1_style: Lines only — arrow/terminator style at the start endpoint. Values are case-sensitive (e.g. "Hollow Arrow", not "hollow_arrow"). Common values: "None", "Arrow", "Hollow Arrow", "Open Arrow", "Diamond", "Aggregation", "Composition", "Generalization". UML, BPMN, and ERD (Crow's Foot) styles also supported — read resource lucid://endpoint-styles for the full list. endpoint2_style: Lines only — arrow/terminator style at the end endpoint (same values as endpoint1_style). link: Block-only. Hyperlink to attach to the block. Accepts the same inputs the canvas "Link to" field accepts: an http(s) or ftp URL, a bare domain like "www.example.com" (auto-prefixed with http://), or the API-only forms "mailto:<email>" and "page://<pageId>". Ignored for lines. To remove an existing link, pass clear_link=True instead of setting this. clear_link: Block-only. When True, removes any hyperlink currently attached to the block. Ignored for lines. Mutually exclusive with link. auto_font_size: Block-only. Toggles Lucid's auto-fit-to-shape font sizing on a block. True enables it (text resizes to fit the shape); False disables it (text keeps an explicit point size); omitted leaves the current state unchanged. Silently ignored on lines. Note: providing a concrete font_size automatically disables auto-font-size, so callers do not need to also pass auto_font_size=False alongside a font_size. Mutually exclusive with a non-null font_size when set to True. Returns: JSON with success status and itemId Example: Edit a block's text and color: lucid_edit_item( document_id="8fb1756d-d7f1-4f8c-933a-40e30fa5d102", item_id="dydGcNA5W-MZ", text="Updated Step A", fill_color="#FFD700", ) Move a line's start endpoint to a new shape: lucid_edit_item( document_id="8fb1756d-d7f1-4f8c-933a-40e30fa5d102", item_id="i1dG5VAgqniu", endpoint1_shape_id="kydGSpnbx.C4", endpoint1_position_x=1.0, endpoint1_position_y=0.5, )

List collaboration threads on a Lucid document. Args: document_id: The UUID of the document. Returns: JSON string of the Lucid API response (array of thread objects).

List comments on a specific collaboration thread of a Lucid document. Args: document_id: The UUID of the document. thread_id: The ID of the thread whose comments to fetch. Returns: JSON string of the Lucid API response (array of comment objects).

Post a new comment to an existing thread on a Lucid document. Args: document_id: The UUID of the document. thread_id: The thread to comment on. content: The text body of the comment. Returns: JSON string of the created comment.

Submits user feedback about the Lucid MCP server to the product team. Use this tool when the user wants to share feedback, report a bug, request a feature, or otherwise comment on their experience with the Lucid MCP server's tools. The feedback is routed to Lucid's product team. Args: title: A short title summarizing the feedback. Required. feedback: The feedback from the user. Required. Returns: A message indicating whether the feedback was successfully submitted.

Get metadata for a Lucid document. The requesting user must have at least read-only access to the document. Owner information is returned for unpublished documents when the requesting user has view access. For published documents, viewers receive account-level owner information; the individual user owner's ID is returned only when the requesting user is at least a collaborator. Args: document_id: UUID of the document to retrieve. Returns: JSON string containing the document's metadata, access details, location, classification, and owner information when authorized. Example: lucid_get_document_metadata( document_id="8fb1756d-d7f1-4f8c-933a-40e30fa5d102", )

Update a Lucid document's title, parent folder, or custom tags. Use this tool to rename a document or move it between folders. At least one of `title`, `parent`, or `custom_tags` must be provided. Args: document_id: UUID of the document to update title: New title for the document. Omit to leave unchanged. parent: Move the document to a new parent. Pass an integer folder ID to move it under that folder, or the literal string "root" to move it to the root folder. Omit to leave the document where it is. custom_tags: Replacement list of custom tag strings. Omit to leave existing tags unchanged. Pass an empty list to clear. Returns: JSON string with the updated document resource. Example: lucid_update_document( document_id="8fb1756d-d7f1-4f8c-933a-40e30fa5d102", title="Q3 Roadmap", parent=12345, )

Create a new folder in the user's Lucid account. Args: name: Folder name (1-300 characters, no leading/trailing whitespace). folder_type: Either "folder" (default) or "team". parent: Parent folder for the new folder. Pass an integer folder ID to nest it under that folder. Omit (or pass the literal string "root") to create it at the root Returns: JSON string with the created folder resource (including its `id`). Example: lucid_create_folder(name="Project plans", parent=12345)

Rename a Lucid folder or move it to a different parent. At least one of `name` or `parent` must be provided. Args: folder_id: Numeric ID of the folder to update. name: New folder name. Omit to leave unchanged. parent: Move the folder to a new parent. Pass an integer folder ID to move it under that folder, or the literal string "root" to move it to the root. Omit to leave the folder where it is. Returns: JSON string with the updated folder resource. Example: lucid_update_folder(folder_id=12345, name="Archived plans")

List the documents and subfolders inside a Lucid folder. Pass `folder_id=None` (the default) to list the user's root folder. When more pages are available, the response includes a `nextPageToken`; pass it back as `page_token` to fetch the next page. Args: folder_id: Numeric folder ID, or omit/None for the root folder. page_size: Page size (1-200, default 50). page_token: Opaque cursor from a previous response's `nextPageToken` field. Returns: JSON string of the form `{"items": [...], "nextPageToken": "..."?}`. The underlying API returns items as a bare list and carries pagination in a `Link` header; this tool reshapes that into a single object. Example: lucid_list_folder_contents(folder_id=12345, page_size=100)