LikeC4
About
LikeC4 MCP Server provides knowledge of your LikeC4 model to LLMs.
Details
- Author
- likec4
- Downloads
- 701
- Categories
- Other
Jump to
- Modeling language for software architecture as code
- Generates live diagrams from the model
- Customizable notation, element types, and nested levels
- CLI server for instant preview (npx likec4 start)
- VS Code extension for in-editor support
- Open source under MIT license
Setting up with Highlight
This MCP is not yet compatible with Highlight’s one-click setup. However, you can still use it with Highlight by following these steps:
- Download and install Highlight from highlightai.com/download
- Navigate to the plugins tab and select "Add Custom Plugin"
-
Configure the plugin with the settings below
Plugin Name
LikeC4Command (node, npx, python, etc.)Please refer to the README for specific instructions on how to obtain API keys or other required environment variables.
- Enable "Start Automatically" if you want the plugin to start when Highlight launches
From the repository
Write architecture models in LikeC4 source files (e.g., .c4). Use the CLI to preview diagrams by running npx likec4 start. A VS Code extension is available for syntax highlighting, validation, and live preview within the editor.
list-projects
List LikeC4 projects discoverable in the current workspace. Request: - No input parameters. Response (JSON object): - projects: Project[] Project (object) fields: - id: string — stable project identifier - title: string — human-readable project title - folder: string — absolute path to the project root - sources: string[] — absolute file paths of related documents Notes: - Read-only, idempotent, no side effects. - Safe to call repeatedly. Example response: { "projects": [ { "id": "docs", "title": "Documentation", "folder": "/abs/path/to/workspace/docs", "sources": [ "/abs/path/to/workspace/docs/model/contexts.likec4", "/abs/path/to/workspace/docs/model/relations.likec4" ] } ] }
read-project-summary
Request: - project: string (optional) — project id. Defaults to "default" if omitted. Response (JSON object): - title: string — human-readable project title - folder: string — absolute path to the project root - sources: string[] — absolute file paths of model documents - config: object — project configuration - name: string — project identifier - title?: string — human-readable title - contactPerson?: string — maintainer contact - metadata?: object — custom project metadata as key-value pairs - extends?: string | string[] — style inheritance paths - exclude?: string[] — file exclusion patterns - include?: object — include configuration (paths, maxDepth, fileThreshold) - manualLayouts?: object — manual layouts config (outDir) - styles?: object — simplified styles (hasTheme, hasDefaults, hasCustomCss) - specification: object - elementKinds: string[] — all element kinds - relationshipKinds: string[] — all relationship kinds - deploymentKinds: string[] — all deployment kinds - tags: string[] — all tags - metadataKeys: string[] — used metadata keys - elements: Element[] — list of elements - deployments: Deployment[] — list of deployment entities - views: View[] — list of views defined in the model Element (object) fields: - id: string — element id (FQN) - kind: string — element kind - title: string — element title - tags: string[] — element tags Deployment (object) fields: - type = "deployment-node": { id: string, kind: string, title: string, tags: string[] } - type = "deployed-instance": { id: string, title: string, tags: string[], referencedElementId: string } View (object) fields: - id: string — view identifier - title: string — view title - type: "element" | "deployment" | "dynamic" Notes: - Read-only, idempotent, no side effects. - Safe to call repeatedly. Example response: { "title": "Cloud Boutique", "folder": "/abs/path/to/workspace/examples/cloud-system", "sources": [ "/abs/path/to/workspace/examples/cloud-system/model.c4" ], "config": { "name": "cloud-boutique", "title": "Cloud Boutique", "contactPerson": "admin@example.com" }, "specification": { "elementKinds": ["system", "container", "component"], "relationshipKinds": ["uses", "depends-on"], "deploymentKinds": ["node", "cluster"], "tags": ["public", "internal"], "metadataKeys": ["owner", "tier"] }, "elements": [ { "id": "shop.frontend", "kind": "component", "title": "Frontend", "tags": ["public"] } ], "deployments": [ { "type": "deployment-node", "id": "k8s.shop.frontend", "kind": "cluster", "title": "Frontend", "tags": [] } ], "views": [ { "id": "system-overview", "title": "System Overview", "type": "element" } ] }
read-element
Read detailed information about a LikeC4 element. Request: - id: string — element id (FQN) - project: string (optional) — project id. Defaults to "default" if omitted. Response (JSON object): - id: string — element id (FQN) - name: string — element name - kind: string — element kind - title: string — human-readable title - description: string|null — optional description - technology: string|null — optional technology - tags: string[] — assigned tags - project: string — project id this element belongs to - metadata: Record<string, string> — element metadata - links: Array<{ title: string|null, url: string, relative: string|null }> — external links associated with this element - shape: string — rendered shape - color: string — rendered color - children: string[] — ids (FQNs) of direct child elements - defaultView: string|null — default view name if set - includedInViews: View[] — views that include this element - relationships: object — relationships of this element (direct and indirect) - incoming: Array<{ source: { id: string, title: string, kind: string }, kind: string|null, target: string, title: string|null, description: string|null, technology: string|null, tags: string[] }> - outgoing: Array<{ source: string, target: { id: string, title: string, kind: string }, kind: string|null, title: string|null, description: string|null, technology: string|null, tags: string[] }> - deployedInstances: string[] — deployed instance ids (Deployment FQNs) - sourceLocation: { path: string, range: { start: { line: number, character: number }, end: { line: number, character: number } } } | null — source location if available View (object) fields: - id: string — view identifier - title: string — view title - type: "element" | "deployment" | "dynamic" Notes: - Read-only, idempotent, no side effects. - Safe to call repeatedly. Example response: { "id": "shop.frontend", "name": "frontend", "kind": "container", "title": "Frontend", "description": "User-facing web app", "technology": "React", "tags": ["public"], "project": "default", "metadata": { "owner": "web" }, "links": [ { "title": "Documentation", "url": "https://docs.example.com/frontend", "relative": null } ], "shape": "rounded-rectangle", "color": "#2F80ED", "children": ["shop.frontend.auth"], "defaultView": "frontend-overview", "includedInViews": [ { "id": "frontend-overview", "title": "Frontend Overview", "type": "element" } ], "relationships": { "incoming": [ { "source": { "id": "shop.api", "title": "API", "kind": "container" }, "kind": "uses", "target": "shop.frontend", "title": "Calls", "description": null, "technology": "HTTPS", "tags": [] } ], "outgoing": [] }, "deployedInstances": ["k8s.cluster.frontend"], "sourceLocation": { "path": "/abs/path/project/model.c4", "range": { "start": { "line": 10, "character": 0 }, "end": { "line": 25, "character": 0 } } } }
read-deployment
Read details about a deployment node or a deployed instance in a LikeC4 project. What it does: - Returns metadata about a deployment entity (node or instance), including kind, tags, color/shape, children, which views include it, and its source location. Inputs: - id: string — Deployment id (FQN) - project: string (optional, defaults to "default") — Project id Output fields: - type: "deployment-node" | "deployed-instance" - id: string — Deployment id (FQN) - kind: string — Deployment node kind, or element kind for deployed instances - name: string — Name of the deployment entity - title: string — Title of the deployment entity - description: string|null — Description text - technology: string|null — Technology info, if any - tags: string[] — Tags assigned to this entity - project: string — Project id - metadata: Record<string, string> - links: Array<{ title: string|null, url: string, relative: string|null }> — external links associated with this deployment entity - shape: string — Rendered shape - color: string — Rendered color - children: string[] — Child deployment ids (empty for instances) - includedInViews: View[] — Views that include this entity - instanceof: { id: string, title: string, kind: string } | null — If type is "deployed-instance", the referenced element - sourceLocation: { path: string, range: { start: { line: number, character: number }, end: { line: number, character: number } } } | null View (object) fields: - id: string — view identifier - title: string — view title - type: "element" | "deployment" | "dynamic" Notes: - Read-only, idempotent; does not mutate the model. Example request: { "id": "k8s.cluster.frontend", "project": "default" } Example response (deployed instance): { "type": "deployed-instance", "id": "k8s.cluster.frontend", "kind": "k8s.pod", "name": "frontend", "title": "Frontend Pod", "description": null, "technology": "Kubernetes", "tags": ["prod"], "project": "default", "metadata": {}, "links": [], "shape": "rectangle", "color": "#2F80ED", "children": [], "includedInViews": [ { "id": "runtime-overview", "title": "Runtime Overview", "type": "deployment" } ], "instanceof": { "id": "shop.frontend", "title": "Frontend", "kind": "component" }, "sourceLocation": { "path": "/abs/path/project/model.c4", "range": { "start": { "line": 10, "character": 0 }, "end": { "line": 25, "character": 0 } } } }
read-view
Read detailed information about a LikeC4 view. Request: - viewId: string — view id (name) - project: string (optional) — project id. Defaults to "default" if omitted. Response (JSON object): - id: string — view id - type: "element" | "deployment" | "dynamic" — view type - title: string — view title (falls back to id if not set) - description: string|null — optional description - tags: string[] — view tags - project: string — project id this view belongs to - nodes: Node[] — nodes included in the view - edges: Edge[] — relationships between nodes - sourceLocation: { path: string, range: { start: { line: number, character: number }, end: { line: number, character: number } } } | null — source location if available Node (discriminated union by "type"): - type = "element": { id: string, elementId: string, kind: string, title: string, description: string|null, technology: string|null, children: string[], shape: string, color: string, tags: string[] } - type = "deployment-node": { id: string, deploymentId: string, kind: string, title: string, description: string|null, technology: string|null, children: string[], shape: string, color: string, tags: string[] } - type = "deployed-instance": { id: string, deploymentId: string, title: string, description: string|null, technology: string|null, referencedElement: { id: string, kind: string, title: string }, shape: string, color: string, tags: string[] } Edge object: - { source: string, target: string, label: string|null, description: string|null, technology: string|null, tags: string[] } Notes: - Read-only, idempotent, no side effects. Example response: { "id": "system-overview", "type": "element", "title": "System Overview", "description": null, "tags": [], "project": "default", "nodes": [ { "type": "logical", "id": "n1", "elementId": "shop.frontend", "kind": "container", "title": "Frontend", "description": null, "technology": "React", "children": [], "shape": "rounded-rectangle", "color": "#2F80ED", "tags": [] } ], "edges": [ { "source": "n1", "target": "n2", "label": "calls", "description": null, "technology": "HTTPS", "tags": [] } ], "sourceLocation": { "path": "/abs/path/project/model.c4", "range": { "start": { "line": 10, "character": 0 }, "end": { "line": 30, "character": 0 } } } }
search-element
Search LikeC4 elements and deployment nodes across all projects. Query syntax (case-insensitive): - kind:<value> filters by kind - shape:<value> filters by shape - meta:<key> filters by having metadata with the given key - #<value> matches assigned tags - <value> matches id (FQN) or title Request: - search: string — at least 2 characters Response (JSON object): - total: number - total number of results - found: Result[] - returns top 20 results Result (discriminated union by "type"): - type = "element": { id: string, name: string, kind: string, title: string, technology: string|null, shape: string, project: string, includedInViews: View[], tags: string[], metadata: Record<string, string> } - type = "deployment-node": { id: string, name: string, kind: string, title: string, technology: string|null, shape: string, project: string, includedInViews: View[], tags: string[], metadata: Record<string, string> } View (object) fields: - id: string — view identifier - title: string — view title - type: "element" | "deployment" | "dynamic" Notes: - Read-only, idempotent. - Use results as input to other tools (e.g., read-element, read-view). Example response: { "total": 1, "found": [ { "type": "logical", "project": "default", "id": "shop.frontend", "name": "frontend", "kind": "container", "title": "Frontend", "technology": "React", "shape": "rectangle", "includedInViews": [ { "id": "system-overview", "title": "System Overview", "type": "element" } ], "tags": ["public"], "metadata": {} } ] }
find-relationships
Find relationships between two LikeC4 elements within a project. What it does: - Finds both direct relationships (element1 ↔ element2) and indirect ones that arise via containment (e.g. via nested elements). - Returns rich metadata for each relationship and where it appears in views. Inputs: - element1: string — Element ID (FQN) - element2: string — Element ID (FQN) - project: string (optional, defaults to "default") — Project id Output: - found: Relationship[] Relationship (object) fields: - type: "direct" | "indirect" — direct is between the specified endpoints; indirect is via nested elements - source: Endpoint - target: Endpoint - kind: string|null — relationship kind from the model - title: string|null — relationship title if provided - description: string|null — relationship description text - technology: string|null — relationship technology - tags: string[] — relationship tags - includedInViews: View[] — views where this relationship appears - sourceLocation: { path: string, range: { start: { line: number, character: number }, end: { line: number, character: number } } } | null Endpoint (object) fields: - id: string — Element ID (FQN) - title: string — element title - kind: string — element kind View (object) fields: - id: string — view identifier - title: string — view title - type: "element" | "deployment" | "dynamic" Notes: - Read-only, idempotent; does not mutate the model. May trigger UI navigation in supporting clients. - The order of results is not guaranteed. Example: Request: { "element1": "shop.frontend", "element2": "shop.backend", "project": "default" } Response: { "found": [ { "type": "direct", "source": { "id": "shop.frontend", "title": "Frontend", "kind": "component" }, "target": { "id": "shop.backend", "title": "Backend", "kind": "component" }, "kind": "sync", "title": "Calls", "description": "Frontend calls Backend", "technology": "HTTP", "tags": ["public"], "includedInViews": [ { "id": "system-overview", "title": "System Overview", "type": "element" } ], "sourceLocation": { "path": "/abs/path/project/model.c4", "range": { "start": { "line": 12, "character": 0 }, "end": { "line": 14, "character": 0 } } } } ] }
find-relationship-paths
Discover all paths (chains of relationships) between two elements, supporting multi-hop traversal. Request: - sourceId: string — source element FQN - targetId: string — target element FQN - maxDepth: number (optional, default: 3, max: 5) — maximum path length (number of hops) - includeIndirect: boolean (optional, default: false) — include indirect (implied) relationships through nested elements - project: string (optional) — project id. Defaults to "default" if omitted. Algorithm: - Uses breadth-first search (BFS) to find all paths - Prevents cycles with visited set per path - Paths are sorted by length (shortest first) - Limited to 100 paths to avoid overwhelming responses Response (JSON object): - paths: Array of path objects, each with: - length: number — number of hops in the path - steps: Array<Step> — ordered sequence of relationships Step (object) fields: - source: string — source element FQN - target: string — target element FQN - relationship: object - kind: string|null — relationship kind - title: string|null — relationship title - description: string|null — relationship description - technology: string|null — relationship technology - tags: string[] — relationship tags Notes: - Read-only, idempotent, no side effects. - Safe to call repeatedly. - Returns empty paths array if no paths exist. - Rejects if source equals target. - includeIndirect=false (default): only follows direct relationships on each element. includeIndirect=true: also follows implied relationships through nested elements. - maxDepth is capped at 5 to prevent excessive computation. - Paths are discovered iteratively and sorted by length. Example response: { "paths": [ { "length": 1, "steps": [ { "source": "shop.frontend", "target": "shop.backend", "relationship": { "kind": "uses", "title": "Calls API", "description": null, "technology": "HTTPS", "tags": [] } } ] }, { "length": 2, "steps": [ { "source": "shop.frontend", "target": "shop.cache", "relationship": { "kind": "uses", "title": "Reads from", "description": null, "technology": "Redis", "tags": [] } }, { "source": "shop.cache", "target": "shop.backend", "relationship": { "kind": "syncs-with", "title": "Updates", "description": null, "technology": null, "tags": [] } } ] } ] }
query-graph
Query element hierarchy and relationships in the architecture graph. Request: - elementId: string — element id (FQN) to query - queryType: "ancestors" | "descendants" | "siblings" | "children" | "parent" | "incomers" | "outgoers" - includeIndirect: boolean (optional, default: true) — for incomers/outgoers, include indirect relationships (through nested elements) - project: string (optional) — project id. Defaults to "default" if omitted. Query Types: - ancestors: Returns all parent elements up to the root (hierarchical) Example: shop.frontend.auth.service returns [shop.frontend.auth, shop.frontend, shop] - descendants: Returns all child elements recursively (hierarchical) Example: shop.frontend returns all nested elements like shop.frontend.auth, shop.frontend.auth.service - siblings: Returns elements at the same hierarchy level with the same parent Example: shop.frontend returns [shop.backend, shop.database] if they're siblings - children: Returns direct child elements only (not recursive) Example: shop returns [shop.frontend, shop.backend] but not shop.frontend.auth - parent: Returns the direct parent element Example: shop.frontend.auth returns shop.frontend - incomers: Returns elements that have outgoing relationships to this element (single hop, not recursive). For recursive upstream traversal, use query-incomers-graph instead. includeIndirect=true: Includes relationships to nested children Example: Elements that depend on this element - outgoers: Returns elements that receive incoming relationships from this element (single hop, not recursive). For recursive downstream traversal, use query-outgoers-graph instead. includeIndirect=true: Includes relationships from nested children Example: Elements this element depends on Response (JSON object): - results: Array of elements (max 100), each with: - id: string — element id (FQN) - name: string — element name - kind: string — element kind - title: string — human-readable title - tags: string[] — assigned tags - metadata: Record<string, string> — element metadata - includedInViews: View[] — views that include this element - truncated: boolean — true if results were truncated due to exceeding maximum limit (100) View (object) fields: - id: string — view identifier - title: string — view title - type: "element" | "deployment" | "dynamic" Notes: - Read-only, idempotent, no side effects. - Safe to call repeatedly. - For parent query on root element, returns empty array. - For hierarchical queries (ancestors, descendants, siblings, children), includeIndirect is ignored. Example response: { "results": [ { "id": "shop.frontend", "name": "frontend", "kind": "container", "title": "Frontend", "tags": ["public"], "metadata": { "owner": "web-team" }, "includedInViews": [ { "id": "system-overview", "title": "System Overview", "type": "element" } ] } ], "truncated": false }
query-incomers-graph
Query the complete graph of all elements that provide input to the target element (recursive incomers/producers). This tool performs a breadth-first traversal to discover all upstream dependencies - elements that directly or indirectly provide input to the target element. It returns the complete subgraph in a single response, making it much more efficient than repeated individual queries. Request: - elementId: string — target element id (FQN) to start from - includeIndirect: boolean (optional, default: true) — include relationships through nested elements - maxDepth: number (optional, default: 10, max: 50) — maximum traversal depth to prevent infinite recursion - maxNodes: number (optional, default: 200, max: 2000) — maximum number of nodes to return - project: string (optional) — project id. Defaults to "default" if omitted. Response Structure: { "target": "element.id", "totalNodes": number, "maxDepth": number, "truncated": boolean, "nodes": { "element.id": { "id": "element.id", "name": "name", "kind": "kind", "title": "title", "tags": ["tag1", "tag2"], "metadata": {}, "includedInViews": [...], "incomers": [ { "elementId": "id1", "relationshipLabel": "uses", "technology": "REST" } ], "depth": number } } } Use Cases: - Find all producers/dependencies for an element - Trace data lineage upstream - Identify root causes and dependencies - Build complete dependency trees - Answer "what feeds into this?" questions Notes: - Read-only, idempotent, no side effects - Cycle detection prevents infinite loops - Result size limited to maxNodes to prevent huge responses - If truncated=true, increase maxNodes or reduce maxDepth to get more specific results Example: For a database element, this returns all services, APIs, and components that write to it, plus all their dependencies, recursively up to maxDepth levels.
query-outgoers-graph
Query the complete graph of all elements that receive output from the target element (recursive outgoers/consumers). This tool performs a breadth-first traversal to discover all downstream dependencies - elements that directly or indirectly consume output from the target element. It returns the complete subgraph in a single response, making it much more efficient than repeated individual queries. Request: - elementId: string — target element id (FQN) to start from - includeIndirect: boolean (optional, default: true) — include relationships through nested elements - maxDepth: number (optional, default: 10, max: 50) — maximum traversal depth to prevent infinite recursion - maxNodes: number (optional, default: 200, max: 2000) — maximum number of nodes to return - project: string (optional) — project id. Defaults to "default" if omitted. Response Structure: { "target": "element.id", "totalNodes": number, "maxDepth": number, "truncated": boolean, "nodes": { "element.id": { "id": "element.id", "name": "name", "kind": "kind", "title": "title", "tags": ["tag1", "tag2"], "metadata": {}, "includedInViews": [...], "outgoers": [ { "elementId": "id1", "relationshipLabel": "sends data to", "technology": "Kafka" } ], "depth": number } } } Use Cases: - Find all consumers/dependents of an element - Trace data lineage downstream - Assess impact of changes (blast radius) - Build complete consumer trees - Answer "what depends on this?" questions Notes: - Read-only, idempotent, no side effects - Cycle detection prevents infinite loops - Result size limited to maxNodes to prevent huge responses - If truncated=true, increase maxNodes or reduce maxDepth to get more specific results Example: For an API service, this returns all clients, services, and systems that consume its output, plus all their consumers, recursively up to maxDepth levels.
query-by-metadata
Search elements and deployment nodes by metadata key-value pairs with flexible matching modes. Request: - key: string — metadata key to filter by - value: string (optional) — metadata value to match (ignored for 'exists' mode) - matchMode: "exact" | "contains" | "exists" (optional, default: "exact") - project: string (optional) — project id. Defaults to "default" if omitted. Match Modes: - exact: Value must match exactly (case-sensitive) Example: key="owner", value="platform-team" matches only exact "platform-team" - contains: Value contains the search string (case-insensitive) Example: key="technology", value="aws" matches "AWS Lambda", "aws-s3", etc. - exists: Element has the key (value parameter is ignored) Example: key="owner" returns all elements with any "owner" metadata Response (JSON object): - results: Array of matching elements/deployment-nodes, each with: - id: string — element/node id (FQN) - name: string — element/node name - kind: string — element/node kind - title: string — human-readable title - tags: string[] — assigned tags - metadata: Record<string, string | string[]> — all element metadata - matchedValue: string — the metadata value that matched (for reference) - includedInViews: View[] — views that include this element View (object) fields: - id: string — view identifier - title: string — view title - type: "element" | "deployment" | "dynamic" Notes: - Read-only, idempotent, no side effects. - Safe to call repeatedly. - Handles both string and array metadata values. - For array values, matches if any element in the array matches. - Returns empty array if no matches found. - Limited to 50 results to avoid overwhelming responses. - Case-sensitive for exact mode, case-insensitive for contains mode. Example response: { "results": [ { "id": "shop.frontend", "name": "frontend", "kind": "container", "title": "Frontend", "tags": ["public"], "metadata": { "owner": "platform-team", "tier": "critical" }, "matchedValue": "platform-team", "includedInViews": [ { "id": "system-overview", "title": "System Overview", "type": "element" } ] } ] }
query-by-tags
Advanced tag filtering with boolean logic (AND, OR, NOT). Request: - allOf: string[] (optional) — element must have ALL these tags (AND logic) - anyOf: string[] (optional) — element must have ANY of these tags (OR logic) - noneOf: string[] (optional) — element must have NONE of these tags (NOT logic) - project: string (optional) — project id. Defaults to "default" if omitted. Boolean Logic: - All three conditions are combined with AND logic - At least one condition must be specified - Tags are case-sensitive Example Queries: - Public APIs: {"allOf": ["public", "api"]} - Deprecated or legacy: {"anyOf": ["deprecated", "legacy"]} - Public but not deprecated: {"allOf": ["public"], "noneOf": ["deprecated"]} - Critical services not in migration: {"allOf": ["critical", "service"], "noneOf": ["migration", "deprecated"]} Response (JSON object): - results: Array of matching elements/deployment-nodes, each with: - id: string — element/node id (FQN) - name: string — element/node name - kind: string — element/node kind - title: string — human-readable title - tags: string[] — assigned tags (for reference) - metadata: Record<string, string | string[]> — element metadata - includedInViews: View[] — views that include this element View (object) fields: - id: string — view identifier - title: string — view title - type: "element" | "deployment" | "dynamic" Notes: - Read-only, idempotent, no side effects. - Safe to call repeatedly. - Returns empty array if no matches found. - Limited to 50 results to avoid overwhelming responses. - Conflicting conditions (e.g., allOf and noneOf with same tag) will return no results. Example response: { "results": [ { "id": "shop.api", "name": "api", "kind": "container", "title": "API Gateway", "tags": ["public", "api", "critical"], "metadata": { "owner": "platform-team" }, "includedInViews": [ { "id": "system-overview", "title": "System Overview", "type": "element" } ] } ] }
query-by-tag-pattern
Search elements by tag patterns using prefix or substring matching. Useful for tag taxonomies with structured naming conventions (e.g., "schedule_*", "*_asil_*"). Request: - pattern: string — tag pattern to match - matchMode: "prefix" | "contains" | "suffix" (optional, default: "prefix") - prefix: matches tags starting with the pattern (e.g., "target_asil" matches "target_asil_qm", "target_asil_asil_b") - contains: matches tags containing the pattern anywhere (e.g., "asil" matches "target_asil_qm", "unit_asil_b") - suffix: matches tags ending with the pattern (e.g., "_tbc" matches "target_asil_qm__tbc") - project: string (optional) — project id. Defaults to "default" if omitted. Response (JSON object): - results: Array of matching elements, each with: - id: string — element id (FQN) - name: string — element name - kind: string — element kind - title: string — human-readable title - tags: string[] — all assigned tags - metadata: Record<string, string | string[]> — element metadata - matchedTags: string[] — the specific tags that matched the pattern - includedInViews: View[] — views that include this element - truncated: boolean — true if results were truncated due to exceeding the 50-result limit - matchedTagValues: string[] — all unique tag values that matched the pattern across all elements View (object) fields: - id: string — view identifier - title: string — view title - type: "element" | "deployment" | "dynamic" Notes: - Read-only, idempotent, no side effects. - Safe to call repeatedly. - Pattern matching is case-insensitive. - Returns empty array if no matches found. - Limited to 50 results. - matchedTagValues provides a summary of all distinct matching tag values found. Example response: { "results": [ { "id": "top.planner.behaviorNode", "name": "behaviorNode", "kind": "cgf-node", "title": "behaviorNode :dwBehaviorPlannerNode", "tags": ["is_in_dag", "target_asil_qm", "process_camera_master"], "metadata": {}, "matchedTags": ["target_asil_qm"], "includedInViews": [] } ], "truncated": false, "matchedTagValues": ["target_asil_qm", "target_asil_asil_b", "target_asil_qm__tbc"] }
batch-read-elements
Read details of multiple elements in a single call, reducing round-trips. Returns a compact summary for each element including metadata, description, technology, shape, children, and relationship counts. Request: - ids: string[] — array of element ids (FQNs) to read (max 50) - project: string (optional) — project id. Defaults to "default" if omitted. Response (JSON object): - elements: Array of element details, each with: - id: string — element id (FQN) - name: string — element name - kind: string — element kind - title: string — human-readable title - description: string|null — optional description - technology: string|null — optional technology - tags: string[] — assigned tags - metadata: Record<string, string | string[]> — element metadata - shape: string — rendered shape - color: string — rendered color - children: string[] — direct child element ids - incomingCount: number — number of incoming relationships - outgoingCount: number — number of outgoing relationships - includedInViews: View[] — views that include this element - notFound: string[] — ids that were not found in the project View (object) fields: - id: string — view identifier - title: string — view title - type: "element" | "deployment" | "dynamic" Notes: - Read-only, idempotent, no side effects. - Safe to call repeatedly. - Maximum 50 element ids per call. - Elements not found are listed in notFound array (not an error). - More efficient than multiple read-element calls when you need summary data for many elements. Example response: { "elements": [ { "id": "shop.frontend", "name": "frontend", "kind": "container", "title": "Frontend", "description": "User-facing web app", "technology": "React", "tags": ["public"], "metadata": { "owner": "web-team" }, "shape": "browser", "color": "#2F80ED", "children": ["shop.frontend.auth"], "incomingCount": 2, "outgoingCount": 3, "includedInViews": [ { "id": "system-overview", "title": "System Overview", "type": "element" } ] } ], "notFound": [] }
element-diff
Compare two elements side-by-side, showing differences in properties, tags, metadata, and relationships. Request: - element1Id: string — first element id (FQN) - element2Id: string — second element id (FQN) - project: string (optional) — project id. Defaults to "default" if omitted. Response (JSON object): - element1: object — snapshot of first element (id, kind, title, description, technology, shape, color) - element2: object — snapshot of second element - propertyDiffs: Array of { property, element1Value, element2Value } — properties that differ - tags: object - onlyInElement1: string[] — tags only in element1 - onlyInElement2: string[] — tags only in element2 - common: string[] — tags in both - metadata: object - onlyInElement1: Record — metadata keys only in element1 - onlyInElement2: Record — metadata keys only in element2 - different: Array of { key, element1Value, element2Value } — keys present in both but with different values - common: Record — metadata keys with identical values in both - relationships: object — relationship count comparison - incomingOnlyElement1/incomingOnlyElement2/incomingShared - outgoingOnlyElement1/outgoingOnlyElement2/outgoingShared Notes: - Read-only, idempotent, no side effects. - Safe to call repeatedly. - Both elements must exist in the same project. - Useful for comparing similar nodes to understand why they have different configurations. Example response: { "element1": { "id": "planner.nodeA", "kind": "cgf-node", "title": "nodeA", ... }, "element2": { "id": "planner.nodeB", "kind": "cgf-node", "title": "nodeB", ... }, "propertyDiffs": [ { "property": "title", "element1Value": "nodeA :dwNodeTypeA", "element2Value": "nodeB :dwNodeTypeB" } ], "tags": { "onlyInElement1": ["target_asil_qm"], "onlyInElement2": ["target_asil_asil_b"], "common": ["is_in_dag", "process_camera_master"] }, "metadata": { "onlyInElement1": {}, "onlyInElement2": {}, "different": [ { "key": "target_asil", "element1Value": "QM", "element2Value": "ASIL-B" } ], "common": { "host": "machine0" } }, "relationships": { "incomingOnlyElement1": 2, "incomingOnlyElement2": 1, "incomingShared": 3, "outgoingOnlyElement1": 0, "outgoingOnlyElement2": 1, "outgoingShared": 2 } }
subgraph-summary
Get a compact, table-friendly summary of all descendants of a parent element. Returns each descendant with its depth, metadata, tags, and relationship counts in a single call. Much more efficient than calling read-element for each descendant individually. Request: - elementId: string — parent element id (FQN) whose descendants to summarize - maxDepth: number (optional, default: 10, max: 20) — maximum depth of descendants to include - metadataKeys: string[] (optional) — if provided, only include these metadata keys in the response (reduces response size) - project: string (optional) — project id. Defaults to "default" if omitted. Response (JSON object): - root: object — the root element summary - id: string — element id - kind: string — element kind - title: string — element title - childCount: number — number of direct children - descendants: Array of descendant summaries, each with: - id: string — element id (FQN) - name: string — element name - kind: string — element kind - title: string — human-readable title - depth: number — depth relative to root (1 = direct child) - tags: string[] — assigned tags - metadata: Record<string, string | string[]> — element metadata (filtered by metadataKeys if provided) - childCount: number — number of direct children - incomingCount: number — number of incoming relationships - outgoingCount: number — number of outgoing relationships - totalDescendants: number — total number of descendants (may differ from array length if truncated) - truncated: boolean — true if results were truncated due to exceeding the 200-result limit - truncatedByDepth: boolean — true if deeper descendants exist beyond maxDepth Notes: - Read-only, idempotent, no side effects. - Safe to call repeatedly. - Limited to 200 descendants in the response. - Use metadataKeys to reduce response size when you only need specific metadata. - Descendants are returned in breadth-first order (closest to root first). - depth=1 means direct child, depth=2 means grandchild, etc. Example response: { "root": { "id": "top.planner", "kind": "subsystem", "title": "Planner Subsystem", "childCount": 5 }, "descendants": [ { "id": "top.planner.nodeA", "name": "nodeA", "kind": "cgf-node", "title": "nodeA :dwNodeTypeA", "depth": 1, "tags": ["is_in_dag", "target_asil_qm"], "metadata": { "target_asil": "QM", "safety_info_unit_asil": "QM" }, "childCount": 0, "incomingCount": 3, "outgoingCount": 2 } ], "totalDescendants": 5, "truncated": false, "truncatedByDepth": false }
apply-semantic-layout
Apply semantic layout to the likec4 view
Claude Desktop / Cursor
Paste into your MCP client config file to install this server.
{
"mcpServers": {
"likec4": {
"likec4": {
"command": "npx",
"args": [
"-y",
"@likec4/mcp"
],
"env": {
"LIKEC4_WORKSPACE": "${workspaceFolder}"
}
}
}
}
}McpServers
{
"likec4": {
"command": "npx",
"args": [
"-y",
"@likec4/mcp"
],
"env": {
"LIKEC4_WORKSPACE": "${workspaceFolder}"
}
}
}What is LikeC4? Why "like"?
LikeC4 is a modeling language for describing software architecture and tools to generate diagrams from the model.
LikeC4 is inspired by C4 Model and Structurizr DSL, but provides some flexibility.
You customize or define your own notation, element types, and any number of nested levels in architecture model.\
Perfectly tailored to your needs.
Sign in to leave a review
Use Google, GitHub, or an email account so ratings stay tied to real people.
No reviews posted yet.
