Lucid

Reads a resource from this MCP server by URI. When a tool description says to read a resource (e.g. "read lucid://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. Args: resource_uri: The URI of the resource to read (e.g. "lucid://diagram-specification"). Leave empty to list available resources.

Searches for documents in Lucid based on keywords and optional filters. 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

Creates a Lucid document using the Standard Import format (.lucid file). 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 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://diagram-specification - Reading lucid://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://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://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://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://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. Do not attempt to guess the Standard Import JSON format. The API validates strictly. Invalid or unsupported JSON can cause import failure. Use lucid://diagram-specification as the source of truth for all Standard Import JSON formatting, validation, layout, and supported-shape details. Args: title: The title for the new document. standard_import_json: JSON string in Lucid Standard Import format. Construct this according to lucid://diagram-specification. product: Target product, either "lucidchart" or "lucidspark". use_assisted_layout: Auto-arranges shapes after import when true by default. See lucid://diagram-specification for when to set this true or false. Size Limits: - Total document.json: 2MB maximum. - Use concise JSON.

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. 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://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.