Crea diagramas de flujo, de secuencia y de arquitectura utilizando asistentes de IA como Claude, Cursor, Windsurf y otras 8 herramientas compatibles con MCP.
FlowZap es una herramienta de diagramación visual de flujos con un DSL basado en texto llamado FlowZap Code. Este servidor MCP permite que los asistentes de IA creen diagramas por ti.
FlowZap convierte prompts de texto en diagramas de triple vista (Flujo, Secuencia y Arquitectura) utilizando el DSL FlowZap Code. NO es Mermaid, NO es PlantUML; es un lenguaje de dominio específico único diseñado para la simplicidad y la generación mediante IA.
Datos clave:
Solo 4 formas: circle, rectangle, diamond, taskbox
Los atributos de nodo usan dos puntos: label:"Texto"
Las etiquetas de borde usan el signo igual: [label="Texto"]
Maneja los conectores: n1.handle(right) -> n2.handle(left)
La etiqueta de visualización de carril (lane) debe estar en la misma línea que la llave de apertura: laneName { # Etiqueta
Calidad del diagrama de secuencia: cada solicitud entre carriles necesita un borde de respuesta coincidente antes de la siguiente solicitud importante; define los bordes en orden cronológico; mantén un ritmo estricto de solicitud → respuesta → siguiente solicitud; sin nodos huérfanos.
Related MCP server: Flowchart MCP
El servidor MCP de FlowZap funciona con cualquier herramienta que admita el Protocolo de Contexto de Modelo (MCP):
Herramienta | Cómo configurar |
Claude Desktop | Añadir a |
Claude Code | Ejecutar: |
Cursor | Abrir Configuración → Características → Servidores MCP → Añadir servidor. Usa la misma configuración JSON. |
Windsurf IDE | Añadir a |
OpenAI Codex | Añadir a |
Warp Terminal | Configuración → Servidores MCP → Clic en "+ Add" → Pegar la configuración JSON. |
Zed Editor | Añadir a |
Cline (VS Code) | Abrir barra lateral de Cline → Icono de Servidores MCP → Editar |
Roo Code (VS Code) | Añadir a |
Continue.dev | Crear |
Sourcegraph Cody | Añadir a |
No compatible: Replit y Lovable.dev solo admiten servidores MCP remotos mediante URL. Usa la API pública en su lugar.
Todas las herramientas utilizan el mismo formato de configuración JSON:
{
"mcpServers": {
"flowzap": {
"command": "npx",
"args": ["-y", "flowzap-mcp"]
}
}
}Usuarios de Windows: Si las herramientas no aparecen, usa la ruta absoluta:
"command": "C:\\Program Files\\nodejs\\npx.cmd"Encuentra tu ruta de npx con:
where.exe npx
Herramienta | Descripción |
| Validar la sintaxis de FlowZap Code |
| Crear una URL de diagrama compartible |
| Obtener la documentación de sintaxis de FlowZap Code |
Herramienta | Descripción |
| Exportar FlowZap Code como grafo JSON estructurado (carriles, nodos, bordes) para razonamiento |
| Analizar registros HTTP, especificaciones OpenAPI o código en diagramas de FlowZap |
| Comparar dos versiones de FlowZap Code y obtener una diferencia estructurada |
| Aplicar operaciones de parche estructuradas (insertar/eliminar/actualizar nodos/bordes) |
Pide a tu asistente de IA:
"Genera un diagrama de secuencia del flujo de inicio de sesión actual implementado en esta aplicación"
"Crea un diagrama de flujo para un sistema de procesamiento de pedidos"
"Crea un diagrama de arquitectura para una puerta de enlace de API de microservicios"
"Haz un diagrama de flujo que muestre el proceso de registro de usuario"
"Diagrama un pipeline de CI/CD con etapas de compilación, prueba y despliegue"
Analizar registros HTTP en diagramas:
"Here are my nginx access logs. Create a sequence diagram showing the request flow."El agente utiliza flowzap_artifact_to_diagram con artifactType: "http_logs".
Analizar la estructura del diagrama:
"Which steps in this workflow touch the database?"El agente utiliza flowzap_export_graph para obtener un grafo JSON y luego lo consulta.
Mostrar qué cambió:
"I updated the workflow. What's different from the previous version?"El agente utiliza flowzap_diff para comparar el código antiguo y el nuevo.
Actualizaciones incrementales seguras:
"Add a logging step after the API call in this diagram."El agente utiliza flowzap_apply_change con un parche estructurado en lugar de regenerar.
El asistente hará lo siguiente:
Generar FlowZap Code basado en tu descripción
Validar el código
Crear una URL de playground con la vista adecuada (flujo, secuencia o arquitectura) para ver y compartir
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"]
}No requiere autenticación - Utiliza solo APIs públicas de FlowZap
Sin acceso a datos de usuario - No puede leer tus diagramas o cuenta
Se ejecuta localmente - El servidor MCP se ejecuta en tu máquina
Protegido contra SSRF - Solo se conecta a flowzap.xyz
Límite de tasa - 30 solicitudes/minuto del lado del cliente
Validación de entrada - Tamaño máximo de código de 50KB
Instala la habilidad de FlowZap para más de 40 agentes de codificación compatibles a través de skills.sh:
npx skills add flowzap-xyz/flowzap-mcpListado en skills.sh: https://skills.sh/flowzap-xyz/flowzap-mcp/flowzap-diagrams
Fuente de la habilidad: skills/flowzap-diagrams/
Compatible con: Claude Code, Cursor, Windsurf, Codex, Gemini CLI, GitHub Copilot, Cline, Roo Code, Augment, OpenCode y más.
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.
