Which integrations are available for this server?

Produces .drawio files compatible with diagrams.net, enabling opening and editing of generated diagrams in the diagrams.net editor.

How do I use drawio-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@drawio-mcp Draw a class diagram for a library management system with Book, Member, and Librarian classes." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

drawio-mcp

by rifujin123

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Draw.io MCP — UML Diagram Generator

drawio-mcp là một MCP server (Model Context Protocol) cho phép bạn sinh UML diagrams chất lượng cao ngay trong quá trình chat với AI — không cần rời khỏi terminal, không cần công cụ vẽ tay.

🎯 Vấn đề & Giải pháp

Trước đây	Với drawio-mcp
Bạn phải tự vẽ diagram bằng tay trong draw.io, LucidChart, hay PlantUML	Bạn mô tả bằng ngôn ngữ tự nhiên, AI sinh file `.drawio` ngay lập tức
Mất 10–30 phút để kéo thả align từng box	Mất vài giây — AI tự layout chuẩn UML
Không tích hợp được vào AI tools	Là MCP server — kết nối trực tiếp với Claude, Cursor, Codex qua MCP protocol
File không chuẩn, khó chỉnh sửa lại	File `.drawio` chuẩn — mở bằng diagrams.net, kéo thả chỉnh sửa tiếp được

Kết quả: Bạn tập trung vào thiết kế, AI lo phần trình bày.

Related MCP server: PlantUML MCP Server

✨ Tính năng nổi bật

🎯 Tự động layout — không cần chỉ định tọa độ, AI tự sắp xếp theo chuẩn UML
🔄 Backward edges / loops — activity diagram hỗ trợ đường vòng (error → retry) với waypoints thông minh
🎨 Đúng ký hiệu UML — bullseye end node, filled sync arrows, activation bars, lifelines
🏊 Swimlanes — activity diagram có swimlane với topological ordering
🔁 Self-loops — sequence diagram hỗ trợ self-message (U-shape)
📁 Output chuẩn .drawio — mở được bằng diagrams.net, chỉnh sửa được bằng giao diện kéo thả

📊 Hỗ trợ 4 loại sơ đồ

Diagram	Ký hiệu đặc biệt
Class Diagram	Classes, attributes, methods, stereotypes (interface/abstract/enum), 6 loại relationships
Use Case Diagram	Stick figure actors, white ellipse use cases, system boundary, include/extend/generalization, actor generalization
Activity Diagram	Start/end (bullseye), action, decision, merge, fork/join, swimlanes, backward edges, labeled flows
Sequence Diagram	Participants (actor/boundary/control/entity), lifelines, activation bars, self-loops, 5 message types

🚀 Cài đặt

Yêu cầu

Node.js ≥ 18.0.0
npm

Clone & build

git clone <repo-url> drawio-mcp
cd drawio-mcp
npm install
npm run build

Kết quả: thư mục dist/ chứa file dist/index.js — đây là entry point của MCP server.

⚙️ Cấu hình trên các nền tảng

Claude Code (CLI)

Thêm vào file ~/.claude/settings.json (global) hoặc .claude/settings.local.json (project):

{
  "mcpServers": {
    "drawio-uml": {
      "command": "node",
      "args": ["D:\\path\\to\\drawio-mcp\\dist\\index.js"]
    }
  }
}

Lưu ý: Dùng path tuyệt đối đến thư mục dự án. Trên Windows dùng \\, trên Mac/Linux dùng /.

Claude Desktop

Mở Settings → Developer → MCP Servers → Add → Điền:

Field	Value
Name	`drawio-uml`
Command	`node`
Arguments	`["D:\\path\\to\\drawio-mcp\\dist\\index.js"]`

Hoặc sửa file cấu hình Claude Desktop tại:

Windows: %APPDATA%\Claude\claude_desktop_config.json
Mac: ~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "drawio-uml": {
      "command": "node",
      "args": ["D:\\path\\to\\drawio-mcp\\dist\\index.js"]
    }
  }
}

Cursor

Thêm vào file .cursor/settings.json trong project:

{
  "mcpServers": {
    "drawio-uml": {
      "command": "node",
      "args": ["D:\\path\\to\\drawio-mcp\\dist\\index.js"]
    }
  }
}

Codex / Windsurf / Cline / Continue / Các IDE khác

Thêm MCP server với cấu hình tương tự:

{
  "mcpServers": {
    "drawio-uml": {
      "command": "node",
      "args": ["/absolute/path/to/drawio-mcp/dist/index.js"]
    }
  }
}

Sau khi cấu hình, restart IDE. Tools sẽ xuất hiện trong danh sách MCP tools.

🛠️ Các MCP Tools

Tool	Description
`draw_class_diagram`	Create UML class diagram
`draw_usecase_diagram`	Create use case diagram
`draw_activity_diagram`	Create activity diagram
`draw_sequence_diagram`	Create sequence diagram
`read_diagram_file`	Read & parse existing .drawio file — xem cấu trúc cells, positions, labels, connections
`update_diagram_file`	Modify existing .drawio file — move, resize, relabel, add/remove cells, thêm edges

Read + Update flow:

1. draw_activity_diagram(...)  → sinh file
2. read_diagram_file({ file_path: "activity-diagram-xxx.drawio" })  → xem cell IDs
3. update_diagram_file({
     file_path: "activity-diagram-xxx.drawio",
     operations: [
       { type: "move_by", cellId: "4", dx: 50, dy: 0 },
       { type: "relabel", cellId: "4", value: "New Label" },
     ]
   })  → sửa file, không cần tạo mới

Sau khi gọi tool tạo/sửa, file .drawio được ghi vào thư mục ./output/.

💡 Prompt templates chuẩn

Dưới đây là các prompt đã tối ưu để sinh từng loại diagram. Copy-paste nguyên mẫu và thay đổi thông tin của bạn.

1. Class Diagram

Vẽ class diagram cho hệ thống quản lý thư viện:

- class Book: attributes = [id, title, author, isbn], methods = [borrow(), return()]
- class Member: attributes = [id, name, email], methods = [borrowBook(), returnBook()]
- class Librarian extends Member: attributes = [employeeId]
- class BorrowRecord: attributes = [id, borrowDate, dueDate]
- class Library: attributes = [name, address]

Relationships:
- Librarian → Member (inheritance)
- BorrowRecord → Member (association, "borrowed by")
- BorrowRecord → Book (association, "contains")
- Library → Book (aggregation, "has")

Kết quả: File .drawio với đầy đủ class compartments, stereotypes, relationships đúng UML.

2. Use Case Diagram

Vẽ use case diagram cho hệ thống ATM:

System name: "ATM System"

Actors:
- Customer (mô tả: người dùng ATM)
- Bank Admin (mô tả: quản trị viên ngân hàng)

Use cases:
- "Withdraw Cash" (id: uc1)
- "Deposit Cash" (id: uc2)
- "Transfer Funds" (id: uc3)
- "Check Balance" (id: uc4)
- "Change PIN" (id: uc5)
- "Manage Users" (id: uc6)

Associations:
- Customer → uc1
- Customer → uc2
- Customer → uc3
- Customer → uc4
- Customer → uc5
- Bank Admin → uc6

Relationships:
- uc3 → uc2 (include)  — Transfer cần Deposit để có tiền
- uc5 → uc4 (extend)   — Change PIN có thể cần Check Balance

System boundary: "ATM System" bao gồm tất cả use cases

Kết quả: Stick figure actors bên trái, white ellipse use cases bên phải trong system boundary. Đúng ký hiệu UML chuẩn.

3. Activity Diagram

Vẽ activity diagram cho quy trình đặt hàng online:

Start node: s1
Action nodes:
- login (label: "Log in")
- browse (label: "Browse products")
- cart (label: "Add to cart")
- checkout (label: "Proceed to checkout")
- payment (label: "Process payment")
- confirm (label: "Send confirmation")
- cancel (label: "Cancel order")
- redirect (label: "Redirect to payment gateway")
- verify (label: "Verify payment")

End nodes: e1, e2

Decision nodes:
- d1 (label: "Continue shopping?")
- d2 (label: "Payment successful?")

Flows:
- s1 → login
- login → browse
- browse → cart
- cart → d1
- d1 → checkout (label: "Yes")
- d1 → browse (label: "No")             # backward edge (loop)
- checkout → redirect
- redirect → payment
- payment → d2
- d2 → verify (label: "Yes")
- d2 → payment (label: "No")            # backward edge (loop)
- verify → confirm
- confirm → e1
- checkout → cancel (label: "Cancel")
- cancel → e2

Swimlanes: (tùy chọn — bỏ nếu không cần)
- "Customer" gồm: [s1, login, browse, cart, d1, checkout, cancel]
- "System" gồm: [redirect, payment, d2, verify]
- "Email Service" gồm: [confirm]

Kết quả: Layout theo topological levels, backward edges có waypoints, decision branches có nhãn Yes/No.

Mẹo: Bỏ phần swimlanes nếu muốn layout đơn giản, chỉ giữ lại nodes + flows.

4. Sequence Diagram

Vẽ sequence diagram cho quy trình rút tiền ATM:

Title: "ATM Transaction"

Participants:
- "User" (type: actor)
- "Cây ATM" (type: boundary)
- "Server Ngân Hàng" (type: entity)

Messages:
# ── Authentication ──
- User → Cây ATM: Nhập thẻ (asynchronous, order: 1)
- Cây ATM → User: Yêu cầu mã PIN (asynchronous, order: 2)
- User → Cây ATM: Nhập mã PIN (asynchronous, order: 3)
- Cây ATM → Server Ngân Hàng: Kiểm tra mã PIN (synchronous, order: 4)
- Server Ngân Hàng → Cây ATM: Xác nhận mã PIN (return, order: 5)

# ── Menu ──
- Cây ATM → User: Hiển thị danh sách lựa chọn (asynchronous, order: 6)
- User → Cây ATM: Nhập lựa chọn (asynchronous, order: 7)

# ── Alt: Kiểm tra số dư / Rút tiền / Huỷ ──
# (gán fragment cho mọi message trong block)
- Cây ATM → Server Ngân Hàng: Lấy số dư (synchronous, order: 8)         # fragment: alt, condition: "Kiểm tra số dư / Rút tiền / Huỷ", fromOrder: 8, toOrder: 20
- Server Ngân Hàng → Cây ATM: Trả về số dư (return, order: 9)
- Cây ATM → User: Hiển thị số dư (asynchronous, order: 10)
- Cây ATM → User: Yêu cầu nhập số tiền (asynchronous, order: 11)
- User → Cây ATM: Nhập số tiền (asynchronous, order: 12)
- Cây ATM → Server Ngân Hàng: Kiểm tra số dư (synchronous, order: 13)
- Server Ngân Hàng → Cây ATM: Trả về số dư (return, order: 14)

# ── Nested Alt: Số dư > Số tiền / Số dư < Số tiền ──
- Cây ATM → Server Ngân Hàng: Cập nhật số dư (synchronous, order: 15)   # fragment: alt, condition: "Đủ tiền / Không đủ", fromOrder: 15, toOrder: 19
- Server Ngân Hàng → Cây ATM: Số dư đã được cập nhật (return, order: 16)
- Cây ATM → User: Thông báo "Hãy nhận tiền" (asynchronous, order: 17)
- User → Cây ATM: Nhận tiền (asynchronous, order: 18)
- Cây ATM → User: Thông báo "Số dư không đủ" (asynchronous, order: 19)

# ── Huỷ ──
- Cây ATM → User: Thông báo "Huỷ giao dịch" (asynchronous, order: 20)

# ── Final ──
- Cây ATM → User: In hóa đơn (asynchronous, order: 21)
- Cây ATM → User: Trả thẻ (asynchronous, order: 22)
- User → Cây ATM: Nhận lại thẻ (asynchronous, order: 23)
- Cây ATM → User: Hiển thị cảm ơn (asynchronous, order: 24)

Kết quả: Participants header ngang trên cùng, lifelines dọc, activation bars rỗng viền đen, self-loops vẽ U-shape bên phải.

Mẹo:

type: "actor" → không có activation bar (đúng UML)
type: "boundary" / "control" / "entity" → có màu khác nhau
type: "synchronous" → mũi tên đặc, đường thẳng (sender chờ)
type: "asynchronous" → mũi tên mở (hói), đường thẳng
type: "return" → dashed line, gray, open arrow
Fragment gán vào message đầu tiên của block với fromOrder=order đầu, toOrder=order cuối
Fragment lồng nhau — tạo fragment thứ 2 với fromOrder/toOrder bên trong fragment ngoài

📂 Output

File sinh ra ở ./output/ với tên dạng <prefix>-<timestamp>.drawio.

Mở bằng:

app.diagrams.net → File → Open → chọn file
Hoặc VS Code extension "Draw.io Integration"

🧪 Development

npm run dev        # Chạy MCP server với tsx (hot reload)
npm run test       # Chạy unit tests
npm run build      # Build TypeScript → dist/
npm run inspect    # Test với MCP Inspector

🏗️ Kiến trúc dự án

src/
├── index.ts                    # Entry point MCP server (stdio)
├── types/                      # Zod schemas + TypeScript interfaces
│   ├── class-diagram.ts
│   ├── usecase-diagram.ts
│   ├── activity-diagram.ts
│   └── sequence-diagram.ts
├── builders/                   # Sinh mxGraph XML cells
│   ├── base-builder.ts         # Abstract class (ID, addVertex, addEdge, serialize)
│   ├── class-builder.ts
│   ├── usecase-builder.ts
│   ├── activity-builder.ts
│   └── sequence-builder.ts
├── tools/                      # MCP tool definitions
│   ├── class-diagram.ts
│   ├── usecase-diagram.ts
│   ├── activity-diagram.ts
│   └── sequence-diagram.ts
└── utils/
    ├── diagram-writer.ts       # Ghi file .drawio
    ├── compression.ts          # Deflate + base64
    ├── layout.ts               # Grid layout helpers
    └── styles.ts               # draw.io mxGraph styles

📝 License

MIT

Available Tools

7 tools

draw_activity_diagramA

Create a UML activity diagram as a .drawio file. Accepts action nodes, decisions, forks/joins, start/end nodes, flows, and swimlanes. Output is a .drawio file that opens in draw.io (diagrams.net).

ParametersJSON Schema

Name	Required	Default
`flows`	Yes
`nodes`	Yes
`title`	No	Activity Diagram
`endNodeId`	No
`swimlanes`	No
`startNodeId`	No

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses the output format and that it opens in draw.io, but does not mention side effects, authentication needs, rate limits, or behavior on invalid input.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loads the main purpose, and contains no redundant or unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of activity diagrams and the absence of an output schema, the description is too brief. It does not explain constraints (e.g., one start/end node), valid flow connections, or error scenarios, which may lead to incorrect tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It mentions nodes, flows, and swimlanes but does not explain parameters like startNodeId, endNodeId, or individual property semantics. This is insufficient for a 6-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a UML activity diagram as a .drawio file, specifying the resource (activity diagram) and verb (create). It distinguishes from sibling tools that draw class, sequence, or usecase diagrams.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly indicates usage for activity diagrams via the name and mention of node types, but it lacks explicit guidance on when to use this tool over alternatives or any when-not conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

draw_class_diagramA

Create a UML class diagram as a .drawio file. Accepts class elements with attributes, methods, stereotypes (interface, abstract, enum), and relationships (inheritance, association, aggregation, composition, dependency, realization). Output is a .drawio file that opens in draw.io (diagrams.net).

ParametersJSON Schema

Name	Required	Default
`title`	No	Class Diagram
`classes`	Yes
`relationships`	No

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses output format (.drawio file) and compatibility (opens in draw.io). However, it does not mention any behavioral traits like file creation behavior, permissions, or side effects, leaving gaps for a creation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. First sentence states purpose and output. Second sentence lists capabilities. Front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (3 parameters, nested objects, no output schema, no annotations), the description is incomplete. Missing details on relationship types, stereotype definitions, attribute syntax, error handling, and file behavior (overwrite, etc.). Schema coverage is 0%, so description carries the burden but falls short.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, so the description must explain parameters. It only provides a high-level list of accepted elements (classes, attributes, methods, relationships) without explaining structure, defaults, or constraints. Nested objects (e.g., methods with params, visibility) are undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a UML class diagram as a .drawio file, using specific verbs and resources. It lists accepted elements (attributes, methods, stereotypes, relationships) and distinguishes it from sibling tools for other diagram types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for class diagram creation but does not explicitly state when to use vs alternatives (e.g., other diagram types). Context from sibling names provides differentiation, but the description itself lacks explicit usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

draw_sequence_diagramA

Create a UML sequence diagram as a .drawio file. Accepts participants (actor, boundary, control, entity, lifeline) and messages (synchronous, asynchronous, return, create, destroy) ordered chronologically. Output is a .drawio file that opens in draw.io (diagrams.net).

ParametersJSON Schema

Name	Required	Default
`title`	No	Sequence Diagram
`messages`	Yes
`participants`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It explains the input and output format but omits details about side effects, idempotency, or permission requirements, which leaves some behavioral aspects unclear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loading the main purpose and immediately detailing accepted types, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of creating a diagram, the description covers the core inputs and output format well. However, it lacks information on where the .drawio file is saved or returned, and does not mention error conditions or constraints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, yet the description lists participant and message types and their ordering, adding significant meaning beyond the raw schema. It explains the structure of participants and messages, but misses the 'title' parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a UML sequence diagram as a .drawio file, listing specific participant types and message types, which distinguishes it from sibling tools like draw_class_diagram or draw_activity_diagram.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for creating sequence diagrams but does not explicitly guide when to prefer this tool over alternatives like draw_class_diagram or provide exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

draw_usecase_diagramA

Create a UML use case diagram as a .drawio file. Uses proper UML notation: stick figure actors, white ellipses for use cases, dashed rectangle for system boundary. Accepts actors, use cases, system boundaries, and relationships (association, include, extend, generalization). Also supports actor generalization (actor inheritance). Output is a .drawio file that opens in draw.io (diagrams.net).

ParametersJSON Schema

Name	Required	Default
`title`	No	Use Case Diagram
`actors`	Yes
`useCases`	Yes
`systemName`	No	System
`associations`	No
`relationships`	No
`systemBoundary`	No
`actorRelationships`	No

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral transparency. It adequately explains the output format (.drawio), notations used, and supported relationships, but does not mention any side effects, permissions, or limitations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the main purpose. It lists key features in a bullet-like style without excessive words. However, it could be slightly more structured to group related information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (8 parameters, nested objects, no output schema), the description provides a good overview but lacks details on parameter usage (e.g., what 'id' is for, how 'systemBoundary.include' works). It is somewhat complete but leaves gaps for an agent to figure out.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning the schema provides no descriptions. The description lists some parameters (actors, use cases, system boundaries, relationships) but does not explain all 8 parameters in detail. For example, 'title' and 'systemBoundary.include' are not mentioned. The description adds some context but is insufficient to compensate for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a UML use case diagram as a .drawio file, specifies proper UML notation, and distinguishes from sibling tools (other draw_* diagram tools and generate_usecase_specification) by focusing on use case diagrams and their elements.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (to create a use case diagram) but does not explicitly state when not to use it or provide alternatives among siblings. The context from sibling tool names helps but the description itself lacks clear usage guidelines.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_usecase_specificationA

Generate a detailed use case specification (đặc tả use case) in Vietnamese format. Produces a structured document with use case name, actors, pre/post conditions, main flow, alternative flows, and exception flows — rendered as a markdown table with Actor/System columns. Optionally saves to a .md file.

ParametersJSON Schema

Name	Required	Description	Default
`trigger`	No	Điều kiện kích hoạt use case
`mainFlow`	Yes	Luồng sự kiện chính (happy case)
`priority`	No	Mức độ ưu tiên (e.g., "Must Have", "Should Have")
`useCaseId`	No	Mã định danh use case (e.g., "UC-01")
`outputPath`	No	Đường dẫn file để lưu (optional)
`description`	Yes	Mô tả sơ lược về use case
`useCaseName`	Yes	Tên use case (e.g., "Đăng ký học phần")
`outputFormat`	No	Định dạng output	markdown
`primaryActor`	Yes	Actor chính
`businessRules`	No	Các quy tắc business (nếu có)
`preConditions`	Yes	Danh sách tiền điều kiện
`exceptionFlows`	No	Các luồng sự kiện ngoại lệ
`postConditions`	Yes	Danh sách hậu điều kiện
`secondaryActor`	No	Actor phụ (nếu có)
`alternativeFlows`	No	Các luồng sự kiện thay thế
`nonFunctionalRequirements`	No	Yêu cầu phi chức năng (nếu có)

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses optional file saving and output format, but lacks details on file overwrite behavior, permissions needed, or other side effects. Basic transparency but incomplete for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with purpose, then output format, then optional saving. No wasted words, efficient communication.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 16 parameters and no output schema. The description explains the output structure but does not specify what the tool returns (e.g., markdown string) if no outputPath is given. Missing return behavior for a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema documents all parameters. The description adds context by summarizing the document structure, but does not add meaning beyond the schema for individual parameters. Adequate but not exceptional.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates a detailed use case specification in Vietnamese format, specifying the output as a structured markdown table. It distinguishes from sibling diagram tools by focusing on specification documents rather than visual diagrams.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for generating use case specs, but it does not explicitly state when to use it versus alternatives (e.g., diagram tools) or provide exclusions. Context from sibling tool names helps, but no direct guidance is offered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_diagram_fileA

Read and parse an existing .drawio diagram file. Returns all cells with their IDs, positions, labels, styles, and connections. Useful for inspecting a generated diagram to understand its structure before making changes.

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes	Path to .drawio file (absolute, or relative to ./output/)

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, but description clearly indicates read-only operation ('Read and parse') and lists returned data. No side effects mentioned, but reasonable for a simple read.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: purpose, details, use case. No fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, output, and usage context. Lacks error handling info, but for a simple read tool with good sibling context, sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a good description. Tool description adds little beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it reads and parses .drawio files, returns cell details. Distinct from sibling tools that create or update diagrams.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly notes it is useful for inspecting before making changes, implying when to use. Could be more explicit about not using for creation, but context with siblings clarifies.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_diagram_fileA

Modify an existing .drawio diagram file. Supports operations: move (absolute), move_by (relative offset), resize, relabel, restyle, add_vertex, add_edge, remove. Use read_diagram_file first to inspect cell IDs, then call update_diagram_file with the target operations.

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes	Path to .drawio file to update
`operations`	Yes	List of operations to apply

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, but the description discloses the modification nature and lists all operation types. It doesn't detail failure modes or atomicity, but the key behaviors are transparent given the tool's straightforward mutation purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with zero fluff. Front-loaded with purpose, then operations, then workflow. Every sentence is essential and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (multiple operation types) and no output schema, the description covers purpose, operations, and workflow adequately. It could be improved by hinting at return values or error handling, but overall it provides sufficient context for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description adds minimal new meaning. It summarizes operation types (e.g., move vs move_by) but the schema already captures these via const values. The description does not significantly enhance parameter understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool modifies an existing .drawio file and lists supported operations. It distinguishes itself from sibling tools that create diagrams (draw_*) or read files (read_diagram_file).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to use read_diagram_file first to inspect cell IDs, then call update_diagram_file with target operations. Provides clear context on prerequisites and proper workflow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv1.0.0Jul 8, 2026
- First observeddraw_activity_diagram
- First observeddraw_class_diagram
- First observeddraw_sequence_diagram
- First observeddraw_usecase_diagram
- First observedgenerate_usecase_specification
- First observedread_diagram_file
- First observedupdate_diagram_file

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool focuses on a unique task: creating specific UML diagram types (activity, class, sequence, use case), generating a specification, or reading/updating existing diagrams. No overlap in purpose.

Naming Consistency5/5

All tools follow a clear verb_noun pattern with underscores (e.g., draw_class_diagram, read_diagram_file, generate_usecase_specification), ensuring predictability.

Tool Count5/5

With 7 tools, the server covers the core UML diagram creation, specification generation, and file management without being overly sparse or bloated.

Completeness4/5

The set covers four common UML diagram types and includes read/update capabilities, but lacks creation for other diagram types (e.g., state, component) that might be expected from a draw.io-focused server.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

hustcc-mcp-mermaid
ai.smithery
Generate dynamic Mermaid diagrams and charts with AI assistance. Customize styles and export diagr…
Software Architecture Developer Tools App Automation
2627
Diagrams MCP A
io.github.mskry
Generate cloud architecture diagrams, flowcharts, and sequence diagrams.
Software Architecture Design Tools Cloud Platforms
923
draw.io A
io.draw
Create diagrams in chat, rendered as live interactive draw.io diagrams. 10,000+ searchable shapes.
Data Visualization Software Architecture Design Tools
215,351
mcp A
io.datadef
Generate, edit, and export data-architecture diagrams from your AI. Column lineage, PNG in chat.
Customer Data Platforms Design Tools Developer Tools
361

Related MCP Servers

UMLmcp
Developer Tools Code Analysis
Cool-Coder174
A
license
Not graded
quality
D
maintenance
Enables users to generate PlantUML code for UML Class and Sequence diagrams using Google Gemini AI. Supports both domain JSON input and free text descriptions to create structured UML diagrams.
Updated a year ago (2025-09-29 07:02 UTC)
MIT
PlantUML MCP Server
Software Architecture Developer Tools Documentation Access
junqing258
A
license
Not graded
quality
D
maintenance
Enables AI assistants to generate UML diagrams from text descriptions using PlantUML, supporting multiple output formats (PNG, SVG, PDF), syntax validation, and diagram source extraction.
Updated 9 months ago (2025-12-17 10:54 UTC)
7
MIT
Draw.io MCP Server
Design Tools Software Architecture Data Visualization
yohasacura
A
license
Not graded
quality
C
maintenance
Enables AI assistants to create and edit draw.io diagrams programmatically, supporting a wide range of diagram types and styles.
Updated 7 months ago (2026-02-09 17:50 UTC)
5
MIT
draw-io-mcp
Design Tools Software Architecture
eason-pan-ep
A
license
Not graded
quality
C
maintenance
Enables creating and editing Draw.io diagrams via natural language, supporting shapes, connectors, and multi-line text.
Updated 7 months ago (2026-02-23 06:22 UTC)
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rifujin123/drawio-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server