前言

2026年2月，draw.io的官方MCP（模型上下文協議）伺服器正式發佈。

隨著MCP伺服器的陸續推出，我也很高興看到draw.io這個被廣泛使用的繪圖工具推出了官方的MCP伺服器。過去在使用LLM進行繪圖時，我一般使用AWS Diagram MCP伺服器將輸出格式設為PNG，或是請LLM將輸出格式設為drawio。這次我決定在測試新推出的draw.io MCP伺服器的同時，也與現有的AWS Diagram MCP伺服器做個比較。

以下是本篇文章的進行流程：

1. draw.io與draw.io MCP伺服器介紹
2. Kiro CLI的設置
3. 讓LLM解析過去創建的AWS構成圖並生成文字
4. 利用draw.io MCP伺服器與AWS Diagram MCP伺服器繪製相同的構成圖並進行比較

1. draw.io是什麼

draw.io是一款免費的開源繪圖工具。它在瀏覽器上運行，並且提供桌面版。內建有AWS、Azure、GCP等雲端圖標，支持流程圖、網路圖、ER圖等多種圖表。由於以XML格式保存，與Git的管理相容性也很好。自幾年前得知以來，我幾乎都在手動作圖時使用draw.io。

draw.io MCP伺服器是什麼

draw.io的開發公司官方發布的MCP伺服器。可以直接從LLM創建和編輯draw.io的圖。

• npm包: @drawio/mcp
• GitHub: jgraph/drawio-mcp

提供的工具

目前內建有三個工具。

Mermaid格式的圖也可由open_drawio_mermaid處理。

原理

1. LLM生成圖的內容（XML / CSV / Mermaid）
   ※繪圖本身是LLM的處理，並非draw.io MCP伺服器的處理。
2. MCP伺服器將內容進行pako deflateRaw（zlib移植至JavaScript的高速壓縮庫）壓縮 → base64編碼
3. 生成帶有#create哈希參數的draw.io URL
4. 在瀏覽器中打開該URL，即可在draw.io編輯器上顯示及編輯圖形

生成的URL哈希片段（#create=...）只存在於瀏覽器中，不會被外部傳送，因此在安全性方面也可安心使用。

2. 使用Kiro CLI進行設置

現在我們開始使用Kiro CLI。

draw.io MCP伺服器的設置

在~/.kiro/settings/mcp.json中新增以下內容。

{
  "mcpServers": {
    "drawio": {
      "command": "npx",
      "args": [
        "@drawio/mcp"
      ],
      "disabled": false
    }
  }
}

設置前需要有Node.js（需要能夠使用npx）。設定完成後，重啟Kiro CLI即可準備就緒。

AWS Diagram MCP伺服器的設置

同時也設置作為比較對象的AWS Diagram MCP伺服器。

{
  "mcpServers": {
    "awslabs.aws-diagram-mcp-server": {
      "command": "uvx",
      "args": [
        "awslabs.aws-diagram-mcp-server"
      ],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "autoApprove": [],
      "disabled": false
    }
  }
}

AWS Diagram MCP伺服器的前提條件如下：

• Python 3.12及以上
• uv
• GraphViz

若尚未安裝GraphViz，macOS用戶可以使用以下命令進行安裝。

brew install graphviz

3. 事前準備：讓LLM解析過去創建的AWS構成圖並生成文字

首先，將過去用draw.io創建的AWS構成圖傳送給LLM進行解析，並請它將構成內容文字化。

解析的構成圖

以下是我在文章中使用的多AZ構成的AWS構成圖，AWS Fault Injection Service中嘗試ECS on Fargate的AZ故障！。

嘗試讓LLM解析

我使用Kiro CLI將圖片傳送並指示「請解釋這張構成圖的內容」。結果生成了如下內容。

僅通過提供圖片，LLM便準確讀取了構成的意圖。因為這是我自己創建的圖，能夠判斷其準確性，但我認為這對其他人創建的圖的理解也非常有幫助。

4. 使用draw.io MCP伺服器與AWS Diagram MCP伺服器繪製相同的構成圖並進行比較

使用draw.io MCP伺服器繪製構成圖

接下來，嘗試使用draw.io MCP伺服器重現剛才LLM解析的構成。為了確保被選擇的模型不會改變，將model固定為claude-opus-4.6。

提示

以下是使用之前生成的文字對LLM下的指示。

請使用draw.io MCP的open_drawio_xml，創建以下AWS構成圖。請使用AWS的官方圖標樣式。

## 整體構成

在AWS Cloud內有一個單獨的VPC（虛擬私有雲），以多AZ（可用區）構成實現高可用性架構。

## 網路構成

- 公共子網：與Internet Gateway連接的外部子網，配置了ALB（應用負載均衡器）。
- 私有子網（應用層）：Fargate任務運行的子網，無法直接從外部訪問。
- 私有子網（資料庫層）：配置了Amazon Aurora的子網。

各子網在2個可用區中進行冗餘配置。

## 請求流程

1. Internet Gateway → 外部流量進入VPC的入口
2. ALB（第一個）→ 用於前端的負載均衡器。流量分散至兩個AZ
3. Fargate - 前端任務（×2）→ 在每個AZ中各配置一個前端容器
4. ALB（第二個）→ 用於後端的內部負載均衡器。將前端的請求分散至後端
5. Fargate - 後端任務（×2）→ 在每個AZ中各配置一個後端容器
6. Amazon Aurora → 擁有寫入（Writer）和讀取（Reader）端點的數據庫集群

## 設計要點

- 高可用性：所有層級分散在兩個AZ中，即使一個AZ發生故障，服務仍能繼續運作
- 安全性：公共子網中僅配置ALB，應用和DB被隔離在私有子網中。每個子網設置了安全組（鎖的圖示）
- 無伺服器容器：使用ECS on Fargate，無需管理EC2實例
- 數據庫的讀寫分離：通過將Aurora的Writer和Reader端點分開，分散讀取負荷

## 使用的AWS服務總結

| 服務 | 角色 |
|---|---|
| VPC | 網路隔離 |
| Internet Gateway | 互聯網連接 |
| ALB (×2) | 流量分散 |
| ECS on Fargate | 容器執行基礎 |
| Amazon Aurora | 關聯數據庫 |

這是一個典型的生產環境強健構成，設計上兼顧擴展性、可用性和安全性。

結果

執行結果如下。

生成的圖如上。雖然是憑藉LLM的力量，但整體看起來不錯。唯一希望是Backend Task的訪問點能指向AZ1的Aurora（雖然指示不夠明確，自然無法做到）。

生成的文件通過draw.io MCP伺服器的功能自動在瀏覽器中啟動，繪圖在draw.io編輯器中顯示。生成的圖可以直接進行編輯，若文字重疊或佈局有問題，可手動微調。當然，亦可導出為PNG、SVG、PDF等格式。

使用AWS Diagram MCP伺服器繪製相同構成圖

接下來，我們將使用AWS提供的AWS Diagram MCP伺服器來繪製相同的構成。

AWS Diagram MCP伺服器是什麼

AWS Labs提供的官方MCP伺服器。它使用Python的diagrams包來生成圖形，能夠支持AWS構成圖、序列圖、流程圖、類圖的生成。

提示

由於AWS Diagram MCP伺服器沒有以drawio格式輸出的工具，因此在執行時需在mcp.json中將draw.io MCP伺服器設置為"disabled": true。

請使用AWS Diagram MCP伺服器創建以下AWS構成圖。請使用AWS的官方圖標樣式。
生成的內容需以drawio格式輸出。

## 整體構成

在AWS Cloud內有一個單獨的VPC（虛擬私有雲），以多AZ（可用區）構成實現高可用性架構。

## 網路構成

- 公共子網：與Internet Gateway連接的外部子網，配置了ALB（應用負載均衡器）。
- 私有子網（應用層）：Fargate任務運行的子網，無法直接從外部訪問。
- 私有子網（資料庫層）：配置了Amazon Aurora的子網。

各子網在2個可用區中進行冗餘配置。

## 請求流程

1. Internet Gateway → 外部流量進入VPC的入口
2. ALB（第一個）→ 用於前端的負載均衡器。流量分散至兩個AZ
3. Fargate - 前端任務（×2）→ 在每個AZ中各配置一個前端容器
4. ALB（第二個）→ 用於後端的內部負載均衡器。將前端的請求分散至後端
5. Fargate - 後端任務（×2）→ 在每個AZ中各配置一個後端容器
6. Amazon Aurora → 擁有寫入（Writer）和讀取（Reader）端點的數據庫集群

## 設計要點

- 高可用性：所有層級分散在兩個AZ中，即使一個AZ發生故障，服務仍能繼續運作
- 安全性：公共子網中僅配置ALB，應用和DB被隔離在私有子網中。每個子網設置了安全組（鎖的圖示）
- 無伺服器容器：使用ECS on Fargate，無需管理EC2實例
- 數據庫的讀寫分離：通過將Aurora的Writer和Reader端點分開，分散讀取負荷

## 使用的AWS服務總結

| 服務 | 角色 |
|---|---|
| VPC | 網路隔離 |
| Internet Gateway | 互聯網連接 |
| ALB (×2) | 流量分散 |
| ECS on Fargate | 容器執行基礎 |
| Amazon Aurora | 關聯數據庫 |

這是一個典型的生產環境強健構成，設計上兼顧擴展性、可用性和安全性。

結果

得到的回答如下。

接著，生成的圖如下。
唔～根據之前的精度，看起來有些不足。

為了得到輸出所使用的程式碼如下

with Diagram("AWS Multi-AZ Architecture", show=False, direction="TB", filename="aws_multi_az_architecture"):
    igw = IGW("Internet Gateway")

    with Cluster("AWS Cloud"):
        with Cluster("VPC"):
            # 公共子網 - ALB（前端）
            with Cluster("Public Subnet"):
                alb_front = ALB("ALB\n(Frontend)")

            # 內部ALB
            with Cluster("Private Subnet (App)"):
                with Cluster("AZ-1"):
                    front1 = Fargate("Front End\nTask")
                    back1 = Fargate("Back End\nTask")
                with Cluster("AZ-2"):
                    front2 = Fargate("Front End\nTask")
                    back2 = Fargate("Back End\nTask")
                alb_back = ALB("ALB\n(Backend)")

        with Cluster("Private Subnet (DB)"):
            with Cluster("Aurora Cluster"):
                writer = Aurora("Writer")
                reader = Aurora("Reader")

    igw >> alb_front
    alb_front >> front1
    alb_front >> front2
    front1 >> alb_back
    front2 >> alb_back
    alb_back >> back1
    alb_back >> back2
    back1 >> writer
    back2 >> writer
    back1 >> reader
    back2 >> reader
    writer - reader

此外，利用LLM的力量，將其輸出為XML格式的內容如下。
真讓人印象深刻，如何將上面的PNG狀態轉換至drawio格式。
雖然是以drawio格式進行作圖，但實際上只是將文件輸出至本地，並未在draw.io中自動打開。
至於繪製的內容，與原圖作了縱向的排列，ECS到Aurora的連結則略有遺憾。

比較

基於相同的上下文，將各自構成圖繪製的結果進行比較。

我個人感受如下：

draw.io MCP伺服器

• 生成後瀏覽器自動啟動，方便快速調整GUI

AWS Diagram MCP伺服器

• 只要生成PNG，輸出過程十分簡單
• 透過Python代碼管控環境的構成圖是它的優勢

總結

draw.io MCP伺服器的發布讓我感覺到，使用LLM進行繪圖的工作流程變得非常便利。

這次體驗讓我有三個感受。

首先，透過圖片解析並生成文字，僅需將現有構成圖交給LLM，即可生成精確的文件。這可用於構成圖的文件編寫，或是對其他人創建的構成圖（相當於負遺產）的理解。此外，不僅在開發階段，這也可以幫助新加入的成員在運維階段更深刻理解現有環境。

接著談到draw.io MCP伺服器，生成後直接在draw.io上編輯的便利性非常吸引人。只需npx即可運行，因此我認為它的導入門檻也較低。未來在繪圖時，draw.io MCP伺服器將確定成為我的首選。

最後談到AWS Diagram MCP伺服器，使用AWS官方圖標並能以Python代碼管理是它的優勢。因為是用Python編碼，所以在CI/CD管道上繪圖也是可行的。

我個人認為未來我會頻繁使用draw.io MCP伺服器。因為我並不對LLM的繪圖完成度提出100%的要求，並且它還能自動打開瀏覽器，這在啟動線上大大前進，因此我覺得沒有理由不使用它。隨著MCP伺服器的相繼推出，我開始感受到在繪圖領域與AI的結合正在加強。

另外，Github上有提到，不使用MCP伺服器，只需在Claude的專案設置中添加指示文檔便能達成同樣效果。我想在某個時候也試試這一點。

希望本文內容能成為有意嘗試draw.io MCP伺服器或AWS Diagram MCP伺服器的讀者的參考。

原文出處：https://qiita.com/sh_fukatsu/items/582dc769379e2c32ae30