使用 Claude、Cursor、Windsurf 以及其他 8 种兼容 MCP 的工具等 AI 助手创建工作流、序列和架构图。
FlowZap 是一款可视化工作流绘图工具，使用一种名为 FlowZap Code 的基于文本的 DSL。此 MCP 服务器允许 AI 助手为您创建图表。
FlowZap 使用 FlowZap Code DSL 将文本提示转换为三视图图表（工作流、序列和架构）。它不是 Mermaid，也不是 PlantUML——它是一种专为简洁性和 AI 生成而设计的独特领域特定语言。
关键事实：
仅有 4 种形状：circle、rectangle、diamond、taskbox
节点属性使用冒号：label:"Text"
边标签使用等号：[label="Text"]
处理句柄：n1.handle(right) -> n2.handle(left)
通道（Lane）显示标签必须与左大括号在同一行：laneName { # Label
序列图质量：每个跨通道请求在下一个主要请求之前都需要一个匹配的响应边；按时间顺序定义边；保持严格的“请求 → 响应 → 下一个请求”节奏；没有孤立节点
Related MCP server: Flowchart MCP
FlowZap MCP 服务器适用于任何支持模型上下文协议 (MCP) 的工具：
工具 | 如何配置 |
Claude Desktop | 添加到 |
Claude Code | 运行： |
Cursor | 打开设置 → 功能 → MCP 服务器 → 添加服务器。使用相同的 JSON 配置。 |
Windsurf IDE | 添加到 |
OpenAI Codex | 添加到 |
Warp Terminal | 设置 → MCP 服务器 → 点击“+ 添加” → 粘贴 JSON 配置。 |
Zed Editor | 添加到 |
Cline (VS Code) | 打开 Cline 侧边栏 → MCP 服务器图标 → 编辑 |
Roo Code (VS Code) | 添加到项目或全局设置的 |
Continue.dev | 创建 |
Sourcegraph Cody | 通过 |
不兼容： Replit 和 Lovable.dev 仅支持通过 URL 的远程 MCP 服务器。请改用 公共 API。
所有工具使用相同的 JSON 配置格式：
{
"mcpServers": {
"flowzap": {
"command": "npx",
"args": ["-y", "flowzap-mcp"]
}
}
}Windows 用户： 如果工具未显示，请使用绝对路径：
"command": "C:\\Program Files\\nodejs\\npx.cmd"使用以下命令查找您的 npx 路径：
where.exe npx
工具 | 描述 |
| 验证 FlowZap Code 语法 |
| 创建可共享的图表 URL |
| 获取 FlowZap Code 语法文档 |
工具 | 描述 |
| 将 FlowZap Code 导出为结构化 JSON 图（通道、节点、边）以供推理 |
| 将 HTTP 日志、OpenAPI 规范或代码解析为 FlowZap 图表 |
| 比较两个版本的 FlowZap Code 并获取结构化差异 |
| 应用结构化补丁操作（插入/移除/更新节点/边） |
询问您的 AI 助手：
“生成此应用程序中当前登录流程的序列图”
“为订单处理系统创建一个工作流图”
“为微服务 API 网关创建一个架构图”
“制作一个显示用户注册流程的流程图”
“绘制一个包含构建、测试和部署阶段的 CI/CD 流水线图”
将 HTTP 日志解析为图表：
"Here are my nginx access logs. Create a sequence diagram showing the request flow."代理使用 flowzap_artifact_to_diagram 并设置 artifactType: "http_logs"。
分析图表结构：
"Which steps in this workflow touch the database?"代理使用 flowzap_export_graph 获取 JSON 图，然后对其进行查询。
显示更改内容：
"I updated the workflow. What's different from the previous version?"代理使用 flowzap_diff 来比较新旧代码。
安全的增量更新：
"Add a logging step after the API call in this diagram."代理使用 flowzap_apply_change 和结构化补丁，而不是重新生成。
助手将：
根据您的描述生成 FlowZap Code
验证代码
创建一个带有适当视图（工作流、序列或架构）的操场 URL，以便查看和共享
sales { # Sales Team
n1: circle label:"Order Received"
n2: rectangle label:"Submit Order"
n5: rectangle label:"Receive decision"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> fulfillment.n3.handle(top) [label="Submit"]
}
fulfillment { # Fulfillment
n3: rectangle label:"Review Order"
n4: rectangle label:"Return decision"
n3.handle(right) -> n4.handle(left)
n4.handle(top) -> sales.n5.handle(bottom) [label="Approved"]
}无需身份验证 - 仅使用公共 FlowZap API
无用户数据访问 - 无法读取您的图表或帐户
本地运行 - MCP 服务器在您的机器上运行
SSRF 保护 - 仅连接到 flowzap.xyz
速率限制 - 客户端每分钟 30 个请求
输入验证 - 最大代码大小 50KB
通过 skills.sh 为 40 多种兼容的编码代理安装 FlowZap 技能：
npx skills add flowzap-xyz/flowzap-mcpskills.sh 列表： https://skills.sh/flowzap-xyz/flowzap-mcp/flowzap-diagrams
技能源码： skills/flowzap-diagrams/
兼容：Claude Code, Cursor, Windsurf, Codex, Gemini CLI, GitHub Copilot, Cline, Roo Code, Augment, OpenCode 等。
MIT
Apply a structured change to FlowZap Code (insert/remove/update nodes or edges). Safer than regenerating entire diagrams - preserves existing structure.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Current FlowZap Code to modify | |
| operations | Yes | Array of patch operations to apply |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that the tool performs mutations ('apply a change') and is safer than full regeneration, but lacks details on error handling, atomicity of operations, permission requirements, or what the return value contains. It adds some context but leaves significant behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and key advantage. Every word earns its place, with no redundancy or unnecessary elaboration, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description provides adequate purpose and usage context but lacks details on behavioral outcomes, error conditions, or return values. It compensates somewhat by highlighting safety and preservation, but doesn't fully address the complexity implied by the detailed input schema for patch operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('code' and 'operations') and their nested structures comprehensively. The description doesn't add any parameter-specific semantics beyond what's in the schema, such as explaining operation sequencing or validation rules, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('apply a structured change') and resource ('FlowZap Code'), specifying it involves insert/remove/update operations on nodes or edges. It distinguishes from potential siblings by contrasting with 'regenerating entire diagrams' and emphasizing preservation of existing structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('safer than regenerating entire diagrams - preserves existing structure'), which implicitly suggests it's preferable for incremental modifications. However, it doesn't explicitly name alternatives or specify when not to use it, such as when starting from scratch or needing complete overhauls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse real artifacts (HTTP logs, OpenAPI specs, code snippets) into FlowZap Code diagrams. Use this to convert raw technical data into visual workflows that can be explained and refined.
| Name | Required | Description | Default |
|---|---|---|---|
| artifactType | Yes | Type of artifact: http_logs (request/response sequences), openapi (API specs), code (function call traces) | |
| content | Yes | Raw artifact content to parse | |
| view | No | Preferred diagram view (default: sequence for logs, workflow for openapi) |
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 disclosure. While it mentions parsing artifacts and converting them to diagrams, it lacks details on permissions, rate limits, error handling, or what the output looks like (e.g., diagram format, success/failure states). For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that are front-loaded and efficient. The first sentence states the core purpose with specific examples, and the second explains the outcome without redundancy. Every sentence earns its place by adding value, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (parsing artifacts into diagrams), lack of annotations, and no output schema, the description is moderately complete. It covers the purpose and input types but misses behavioral details and output information. For a tool with 3 parameters and no structured safety or output guidance, it should do more to compensate, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters (artifactType, content, view) with descriptions and enums. The description adds minimal value by listing artifact types (matching the enum) and mentioning 'raw artifact content', but doesn't provide additional syntax, format details, or constraints beyond what the schema specifies. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Parse real artifacts... into FlowZap Code diagrams' and 'convert raw technical data into visual workflows'. It specifies the verb (parse/convert) and resource (artifacts/technical data) with concrete examples (HTTP logs, OpenAPI specs, code snippets). However, it doesn't explicitly differentiate from sibling tools like flowzap_export_graph or flowzap_get_syntax, which might also handle diagrams or syntax.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by listing specific artifact types (HTTP logs, OpenAPI specs, code snippets) and stating the outcome ('visual workflows that can be explained and refined'). However, it doesn't provide explicit guidance on when to use this tool versus alternatives like flowzap_apply_change or flowzap_validate, nor does it mention any exclusions or prerequisites for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a FlowZap playground session with the given code and return a shareable URL. Use this after generating FlowZap Code to give the user a visual diagram. Set view to 'architecture' when user requests an architecture diagram.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | FlowZap Code to load in the playground | |
| view | No | View mode for the diagram. Use 'architecture' for architecture diagrams, 'sequence' for sequence diagrams, 'workflow' (default) for workflow diagrams. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool creates a session and returns a URL, but lacks details on permissions, rate limits, error handling, or what happens to existing sessions. It adds some context about view modes but doesn't fully describe behavioral traits beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by two concise usage guidelines. Every sentence earns its place by providing specific, actionable information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (creation operation with 2 parameters) and no annotations or output schema, the description is fairly complete. It covers purpose, usage, and some parameter guidance, but could improve by addressing behavioral aspects like error cases or session management to fully compensate for the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value by mentioning the 'view' parameter's use for architecture diagrams, but doesn't provide additional semantic context beyond what the schema's enum and descriptions already cover.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a FlowZap playground session'), the resource ('with the given code'), and the outcome ('return a shareable URL'). It distinguishes from siblings by focusing on playground creation rather than validation, export, or other operations listed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this after generating FlowZap Code to give the user a visual diagram' and 'Set view to 'architecture' when user requests an architecture diagram.' This clearly indicates when to use this tool versus alternatives and includes specific conditional instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two versions of FlowZap Code and get a structured diff showing what changed (nodes/edges added, removed, updated). Use this to explain changes to users.
| Name | Required | Description | Default |
|---|---|---|---|
| oldCode | Yes | Original FlowZap Code | |
| newCode | Yes | Updated FlowZap Code |
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 disclosure. It mentions the tool returns a 'structured diff' but doesn't specify the format, size limits, error conditions, or performance characteristics. For a comparison tool with no annotation coverage, this lacks critical details about how it behaves beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and efficiently structured in two sentences: the first states the core functionality, and the second provides usage context. Every sentence earns its place with no wasted words, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (comparing code versions) and lack of annotations or output schema, the description is adequate but incomplete. It covers the purpose and usage context but misses behavioral details like output format or error handling. For a diff tool without structured output documentation, this leaves gaps in understanding what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain what constitutes valid FlowZap Code or how versions should be formatted). Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('compare', 'get a structured diff') and resources ('two versions of FlowZap Code'), distinguishing it from siblings like flowzap_validate or flowzap_export_graph. It explicitly mentions what the diff shows ('nodes/edges added, removed, updated'), making the purpose highly specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to explain changes to users'), which implies it's for analyzing differences between code versions. However, it doesn't explicitly state when not to use it or name alternatives among siblings (e.g., flowzap_validate for checking code correctness instead of comparing changes), leaving some guidance gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export FlowZap Code as a structured JSON graph (lanes, nodes, edges). Use this to inspect diagrams structurally, query relationships, or analyze workflow patterns without re-parsing DSL.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | FlowZap Code to parse into a graph structure |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the tool's function as an export operation that outputs a structured JSON graph, implying it is read-only and non-destructive, but does not specify details like error handling, performance characteristics, or whether it requires specific permissions. While it adds useful context about use cases, it lacks comprehensive behavioral traits beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and efficiently adds use cases in the second, with zero wasted words. Every sentence earns its place by clarifying the tool's function and applications, making it appropriately sized and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (exporting structured data), no annotations, and no output schema, the description is adequate but incomplete. It covers the purpose and usage context well, but lacks details on output format specifics, error conditions, or behavioral nuances. For a tool with no structured output documentation, more information on the JSON structure or limitations would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'code' documented as 'FlowZap Code to parse into a graph structure'. The description adds marginal value by reinforcing that the tool parses 'FlowZap Code' into a graph, but does not provide additional semantics beyond what the schema already states, such as format examples or constraints. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Export FlowZap Code as a structured JSON graph') and resource ('FlowZap Code'), distinguishing it from siblings like 'flowzap_validate' or 'flowzap_diff' by focusing on structural export rather than validation or comparison. It explicitly mentions the output format ('lanes, nodes, edges') and use cases ('inspect diagrams structurally, query relationships, or analyze workflow patterns'), making the purpose highly specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool ('to inspect diagrams structurally, query relationships, or analyze workflow patterns without re-parsing DSL'), implying it is for analysis rather than modification. However, it does not explicitly state when not to use it or name alternatives among siblings, such as 'flowzap_artifact_to_diagram' for visualization or 'flowzap_validate' for syntax checking, leaving some ambiguity in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get FlowZap Code syntax documentation and examples. Use this to learn how to write FlowZap Code for workflow diagrams.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 disclosure. It describes the tool as a 'Get' operation for documentation, which suggests a read-only, non-destructive behavior, but does not specify details like authentication needs, rate limits, or the format of the returned documentation. This leaves gaps in understanding how the tool behaves in practice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of two clear sentences that directly state the tool's function and its intended use. Every sentence adds value without unnecessary elaboration, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but not fully complete. It explains what the tool does but lacks details on behavioral aspects (e.g., response format, error handling) that would be helpful for an agent, especially since no annotations or output schema are provided to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 params), and schema description coverage is 100%, so the schema fully documents the lack of inputs. The description does not need to add parameter details, and it appropriately focuses on the tool's purpose without redundant information, meeting the baseline for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('FlowZap Code syntax documentation and examples'), and explains the intended use ('to learn how to write FlowZap Code for workflow diagrams'). However, it does not explicitly differentiate this from its siblings (e.g., flowzap_validate or flowzap_artifact_to_diagram), which might also involve FlowZap Code, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool ('to learn how to write FlowZap Code'), providing some context for its application. However, it lacks explicit guidance on when not to use it or alternatives among the sibling tools (e.g., when to use flowzap_validate instead), leaving usage somewhat open to interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate FlowZap Code syntax. Use this to check if FlowZap Code is valid before creating a playground.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | FlowZap Code to validate |
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 disclosure. It indicates this is a validation tool (implying read-only, non-destructive behavior), but doesn't specify what happens on validation failure (e.g., error messages, detailed feedback) or success (e.g., returns boolean, structured validation report). It adds some context about the pre-playground use case, but lacks details on rate limits, authentication needs, or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that are front-loaded with the core purpose and usage guidance. Every word earns its place—no redundancy or unnecessary elaboration. It efficiently communicates what the tool does and when to use it without wasting space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (validation with one parameter) and no annotations or output schema, the description is reasonably complete. It covers purpose and usage well, but lacks details on behavioral outcomes (e.g., what validation returns) and doesn't fully compensate for the absence of annotations. However, it's sufficient for basic agent understanding in context with siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'code' parameter clearly documented as 'FlowZap Code to validate'. The description doesn't add any additional parameter semantics beyond what the schema provides (e.g., no examples, format constraints, or validation criteria), so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('validate') and resource ('FlowZap Code syntax'), and distinguishes it from siblings by mentioning its use 'before creating a playground' (differentiating from flowzap_create_playground). It provides a clear, actionable purpose beyond just restating the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('to check if FlowZap Code is valid before creating a playground'), providing clear context and distinguishing it from alternatives like flowzap_create_playground (which would presumably be used after validation) and flowzap_get_syntax (which might retrieve syntax rules rather than validate code).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.3.4flowzap_apply_changeflowzap_artifact_to_diagramflowzap_create_playgroundflowzap_diffflowzap_export_graphflowzap_get_syntaxflowzap_validateScored across 7 tools
Each tool has a clearly distinct purpose with no overlap: apply_change modifies diagrams, artifact_to_diagram parses data, create_playground generates URLs, diff compares versions, export_graph outputs JSON, get_syntax provides documentation, and validate checks syntax. The descriptions reinforce unique functions, eliminating confusion.
All tools follow a consistent 'flowzap_' prefix with snake_case naming and clear verb_noun patterns (e.g., apply_change, artifact_to_diagram). This uniformity makes the set predictable and easy to navigate, with no deviations in style or structure.
With 7 tools, the server is well-scoped for its diagramming and workflow domain. Each tool earns its place by covering essential operations like creation, validation, comparison, export, and parsing, without being overly sparse or bloated.
The toolset provides complete coverage for the FlowZap diagramming lifecycle: from learning syntax (get_syntax) and validating code (validate) to creating diagrams (artifact_to_diagram), applying changes (apply_change), comparing versions (diff), exporting data (export_graph), and sharing results (create_playground). No obvious gaps exist for the stated purpose.
Generate, inspect, and manage Flowstep UI designs directly from your AI assistant.
Generate dynamic Mermaid diagrams and charts with AI assistance. Customize styles and export diagr…
Generate cloud architecture diagrams, flowcharts, and sequence diagrams.
Create diagrams in chat, rendered as live interactive draw.io diagrams. 10,000+ searchable shapes.
