Create a new Excalidraw diagram of any supported type.

Two input modes:

1. Graph types (architecture, flowchart) - pass nodes and connections. The tool handles layout, styling, and rendering; no coordinates needed.

2. Typed diagrams (every other type) - pass diagram_type and a spec object shaped for that type. Call list_diagram_types to choose a type and get_diagram_schema to see its spec shape.

Convert Mermaid flowchart syntax into an Excalidraw diagram.

Supports the mermaid flowchart subset that AI agents commonly generate:

• Directions: graph TD, LR, BT, RL

• Node shapes: [text], {text}, ((text)), ([text])

• Edge types: -->, ---, -.-> ==> with |label|

• Subgraphs: subgraph Title ... end

Component types are auto-detected from node labels (e.g., a node labeled "PostgreSQL DB" automatically gets database styling).

Modify an existing Excalidraw diagram created by this tool.

Supports iterative editing: add components, remove nodes, update labels, and rewire connections - without recreating the entire diagram.

IMPORTANT: Call get_diagram_info first to understand the current diagram state before making modifications.

For typed diagrams (sequence, pyramid, bar, swimlane, ...) there is a single operation:

{"op": "update_spec", "patch": {"tiers": [...], "title": "New title"}}

The patch is deep-merged into the stored spec and the diagram re-rendered. Lists are replaced wholesale, so send the complete list to change one entry. The node/connection operations below apply to architecture and flowchart diagrams only.

Get a structured summary of an existing Excalidraw diagram.

Call this BEFORE modify_diagram to understand what nodes and connections currently exist. The summary includes node ids, labels, component types, and the full connection topology.

Export an .excalidraw file to SVG or PNG image.

Converts an existing .excalidraw diagram into a portable image file without requiring a browser or the Excalidraw application.

List every supported diagram type with guidance on when to use it.

Call this BEFORE create_diagram when the right diagram type isn't obvious. Picking the wrong type is the most common way a diagram fails - a swimlane drawn as a flowchart loses the handoffs that were the point.

Two rules worth applying whatever you pick:

• Target density ~4/10. Above 9 nodes it is probably two diagrams.

• Mark only 1-2 elements "focal": true. The accent color is a signal, and using it everywhere destroys it.

Returns: A table of type -> family, when to use it, and when not to.

Get the JSON schema and selection guidance for one diagram type.

Call this before passing a spec to create_diagram for a type you have not used yet, so the payload matches on the first attempt.

Create a new architecture knowledge graph file (markdown).

The knowledge graph is the persistent source of truth for your system's services and dependencies. Diagrams are rendered from it.

Add or update a service in the knowledge graph.

Remove a service and all dependencies touching it.

Add a directed dependency: from_id depends on / calls to_id.

Both services must already exist (add them with kg_add_service first). style is one of solid/dashed/dotted/thick.

Remove the dependency from_id -> to_id.

Assign a service to a domain (optionally set the domain's display label).

Summarize the whole knowledge graph: services, domains, and topology.

Call this before mutating the graph to reason about current state.

Render the entire architecture to an .excalidraw file.

Render a focused diagram of just the given services (induced subgraph).

Render a service plus everything within depth hops of it.

direction: "downstream" (its dependencies), "upstream" (its dependents), or "both".

Render only the services belonging to one domain.

Import an existing .excalidraw diagram's services into the knowledge graph.

Bootstraps the graph from diagrams you already created with this tool.

Impact analysis: what breaks if service_id fails?

Reports direct dependents, the full transitive upstream blast radius, and what the service itself depends on.

Trace the shortest dependency path between two services.

Architecture health check: cycles, single points of failure, orphans, dangling references, and (optionally) unowned services.

Export the knowledge graph to another format.

Show how the architecture changed since a git ref (default HEAD).

Compares the current knowledge file against its version at ref.

Generate a human onboarding guide (entry points, hubs, domains) from the graph.

Detect drift between the declared architecture and Python imports under code_root.

Best-effort: treats each top-level package as a service and infers edges from imports. Reports undocumented and possibly-stale dependencies.