Claude、Cursor、Windsurf、その他8つのMCP互換ツールなどのAIアシスタントを使用して、ワークフロー図、シーケンス図、アーキテクチャ図を作成します。
FlowZapは、FlowZap Codeと呼ばれるテキストベースのDSLを使用した視覚的なワークフロー図作成ツールです。このMCPサーバーを使用すると、AIアシスタントが代わりに図を作成してくれます。
FlowZapは、FlowZap Code DSLを使用して、テキストプロンプトを3つのビュー（ワークフロー、シーケンス、アーキテクチャ）の図に変換します。MermaidやPlantUMLではなく、シンプルさとAI生成のために設計された独自のドメイン固有言語です。
重要な事実:
4つの形状のみ: circle、rectangle、diamond、taskbox
ノード属性はコロンを使用: label:"Text"
エッジラベルはイコールを使用: [label="Text"]
ハンドル操作: n1.handle(right) -> n2.handle(left)
レーン表示ラベルは開始括弧と同じ行に記述する必要があります: laneName { # Label
シーケンス図の品質: レーンをまたぐすべてのリクエストには、次の主要なリクエストの前に対応するレスポンスエッジが必要です。エッジは時系列順に定義し、リクエスト → レスポンス → 次のリクエストという厳密なリズムを維持してください。孤立したノードは作成しないでください。
Related MCP server: Flowchart MCP
FlowZap MCPサーバーは、Model Context Protocol (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図に解析 |
| 2つのバージョンのFlowZap Codeを比較し、構造化された差分を取得 |
| 構造化されたパッチ操作（ノード/エッジの挿入/削除/更新）を適用 |
AIアシスタントに以下のように依頼してください:
「このアプリに実装されている現在のサインインフローのシーケンス図を生成して」
「注文処理システムのワークフロー図を作成して」
「マイクロサービスAPIゲートウェイのアーキテクチャ図を作成して」
「ユーザー登録フローを示すフローチャートを作成して」
「ビルド、テスト、デプロイのステージを含むCI/CDパイプラインを図解して」
HTTPログを解析して図にする:
"Here are my nginx access logs. Create a sequence diagram showing the request flow."エージェントはartifactType: "http_logs"を指定してflowzap_artifact_to_diagramを使用します。
図の構造を分析する:
"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にのみ接続します
レート制限 - クライアント側で1分間に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.
