Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@processon-mcp Create a flowchart for user login and registration"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
ProcessOn MCP Server — turn your own ProcessOn permanent account into a Model Context Protocol tool that generates editable online diagrams for AI hosts (Doubao, Claude, Cursor, ...).
It wraps ProcessOn AI so an AI can draw flowcharts, architecture diagrams, mindmaps, UML, timelines and more on demand, and hand back both a preview image and an editable online link.
Architecture follows the same pattern as mcp-mubu: a thin MCP Python SDK layer on top of an HTTP API client, with a pluggable SQLite cache.
Natural language → diagram: describe an idea, get a professional editable chart
Markdown → mindmap: turn notes/outlines into an editable mindmap
30+ diagram types: flowcharts, swimlanes, sequence, architecture, ER, org, timeline, infographic …
Editable output, not dead images: every chart returns a ProcessOn editor link
Your own account: uses your ProcessOn permanent account via a personal API token
MCP standard: tools + resources + prompts over stdio (default) or HTTP
Zero-config cache: SQLite at ~/.processon-mcp/cache.db
Related MCP server: @processon/mcp-server-processon
# With uv (recommended)
uv venv
uv pip install -e .
# Or plain pip
pip install -e .Create an access token (looks like sk-po-...) and copy it.
Copy .env.example to .env in the project root and fill it in (loaded
automatically), or export the variable:
PROCESSON_API_KEY=sk-po-your-tokenprocesson-mcp # stdio (default — for Doubao/Claude)
processon-mcp --transport http --port 3100 # Streamable HTTP
processon-mcp -v # debug loggingTool | Description |
| Show current ProcessOn auth status |
| Turn an idea into a Mermaid diagram definition (first draft / planning) |
| Render a Mermaid you authored into an editable ProcessOn diagram |
| One-shot: natural-language prompt -> editable diagram |
| Convert Markdown into an editable mindmap |
| Show cache backend info |
| Clear cached data |
ProcessOn has no low-level "add node / add edge" editing API, so the LLM owns the diagram through Mermaid source and ProcessOn only renders it:
processon_design_diagram — get a Mermaid skeleton for an idea.
The LLM edits the Mermaid directly (add/remove nodes, edges, labels).
processon_render_mermaid — render the edited Mermaid into a professional
editable online chart; get preview image + editable link.
Repeat 2–3 to iterate toward the final diagram.
One Mermaid grammar covers flowcharts, architecture / network-deployment, mindmaps, sequence, ER, class, timeline and C4 diagrams.
Resource | Description |
| Auth and cache status |
Prompt | Description |
| Step-by-step configuration guide |
See processon-mcp-连接器配置指南.md
for how to register this server as a Doubao custom connector.
processon-mcp/
├── pyproject.toml
├── README.md
└── src/
└── processon_mcp/
├── __init__.py
├── __main__.py # CLI entrypoint
├── server.py # MCP server (tools, resources, prompts)
├── processon_client.py # ProcessOn HTTP / JSON-RPC client
├── processon_config.py # Config, constants, error types
└── cache/
├── __init__.py # Cache factory
├── base.py # CacheBackend ABC
└── sqlite_cache.py # Built-in SQLite backendThis is an unofficial integration built on ProcessOn's hosted AI API.
Diagram generation is async on ProcessOn's side; the server waits for the result (default timeout 180s).
The personal API token is equivalent to a password — keep it secret, never
commit .env.
MIT
Clear cached data. Optionally clear only keys with a given prefix.
Args: prefix: Key prefix to clear (empty = clear everything).
| Name | Required | Description | Default |
|---|---|---|---|
| prefix | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 does state that it clears cached data, which implies deletion, and explains the prefix behavior. However, it does not explicitly warn about permanence, auth requirements, or side effects beyond the action itself.
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 concise paragraph with a clear heading and a simple Args list. Every sentence adds value; there is no redundancy or filler.
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 simple tool with one optional parameter and an output schema, the description covers the essential behavior. It could note that the action is permanent, but the word 'clear' and the context of a cache make that implicit. Overall, it is adequate for an agent to invoke correctly.
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 0%, but the description fully explains the single parameter 'prefix' with its meaning ('Key prefix to clear') and special value ('empty = clear everything'). This adds essential semantic detail beyond the schema's bare type.
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 states a clear verb ('clear') and resource ('cached data'), and the optional prefix behavior adds precision. It is immediately distinguishable from siblings like cache_info (which reads) and generation tools.
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 explains the primary use (clearing cache) and the condition for using a prefix, which is clear context. However, it does not explicitly mention when not to use it or point to alternatives like cache_info, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show cache backend info and whether a token is stored.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It uses 'Show' which implies a read-only operation, but it does not explicitly state that it has no side effects or mention any permissions or limitations. Given the simplicity, this is adequate but not fully transparent.
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, front-loaded sentence that clearly communicates the tool's purpose without any fluff. It earns its place and is appropriately concise.
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?
The tool is simple with no parameters and an output schema, so the description covers the essential purpose. It could optionally mention that it is read-only, but 'Show' sufficiently implies this. Minor gap in explicit usage context, but overall complete.
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 tool has zero parameters, so the description adds no parameter details. Per rubric, a baseline of 4 is appropriate for zero-parameter tools; the schema already trivially covers everything.
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 a specific action (show) and resource (cache backend info and token storage status). It distinguishes itself from siblings like processon_cache_clear (clearing vs. info) and chart-generation tools, so an agent can select it appropriately.
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 its use (for inspecting cache state) but does not explicitly contrast with alternatives or state when not to use it. The sibling name processon_cache_clear offers indirect contrast, but no explicit guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn an idea into a Mermaid diagram definition (DSL) — the planning / first-draft step of LLM-led diagramming.
Use this FIRST when you want to design a diagram from scratch: it returns
editable Mermaid source code (not a rendered image). You — the LLM — then
read it, refine it, add/remove nodes and edges, and finally hand the edited
Mermaid to processon_render_mermaid to get a real editable ProcessOn chart.
Supported diagrams map to Mermaid types: flowchart/architecture/network deployment (graph TD/LR), mind map (mindmap), sequence (sequenceDiagram), ER model (erDiagram), class diagram (classDiagram), timeline, C4, etc.
This is the recommended workflow for "from 0 to 1 to 100":
design_diagram -> get a Mermaid skeleton
edit the Mermaid yourself (iterate nodes/edges/labels)
render_mermaid -> get preview image + editable link
repeat 2-3 until the diagram is right.
Args: prompt: What the diagram should describe (goal, entities, steps, decisions, relationships). Write in the user's language. diagram_type: Hint for the target shape, e.g. "flowchart", "mindmap", "sequence", "er", "architecture", "network-deployment", "timeline". Leave empty to infer.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| diagram_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job. It discloses that the tool returns editable Mermaid source, not a rendered image, that the LLM is expected to refine the output, and that the final rendering is delegated to a sibling. It also enumerates supported diagram types, giving the agent a precise mental model of what the tool produces and what its role is in the pipeline.
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 and then structured into clear sections (workflow, args). It is longer than minimal, but every part contributes value: the workflow explains the full lifecycle, the args section is essential given the sparse schema, and the supported types list is useful. Slight redundancy exists (e.g., 'editable' appears twice), but it remains efficient overall.
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?
The tool has an output schema (not shown here), so the description correctly avoids detailing return structure. It covers the input parameters, the workflow integration with siblings, the supported diagram types, and the expected usage pattern. For a design/planning tool, nothing essential is missing—an agent can confidently call it correctly based on this description alone.
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 coverage is 0% and the schema itself provides only types and titles with no descriptions. The description compensates fully with an 'Args' section that explains the prompt parameter as 'What the diagram should describe' and diagram_type with concrete examples ('flowchart', 'mindmap', 'sequence', 'er', etc.). This adds meaning far beyond the bare schema and gives the agent everything needed to craft valid inputs.
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 opens with a clear, specific verb-resource pair: 'Turn an idea into a Mermaid diagram definition (DSL)' and immediately frames it as the planning/first-draft step. It distinguishes itself from the render sibling by stating it returns editable source code, not a rendered image, and even names the alternative tool. This fully disambiguates it from processon_render_mermaid and other siblings.
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 says 'Use this FIRST when you want to design a diagram from scratch' and provides a step-by-step recommended workflow (1-4) that tells the agent exactly when to call design_diagram and when to move to render_mermaid. It also clarifies the diagram_type parameter as a hint and says to leave it empty to infer. This gives clear, actionable usage context with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an editable online diagram from a natural-language description.
Turn an idea, process, or structure into a professional ProcessOn diagram. Supports flowcharts / swimlane diagrams, sequence diagrams, software & cloud architecture diagrams, ER diagrams, org charts, timelines, infographics and more. Returns a preview image and an editable link.
Use this whenever the user wants to "画个图 / 流程图 / 架构图 / 思维导图 / visualization / create a diagram". If the chart type is ambiguous, ask first.
Args: prompt: A clear description of the diagram. Include the goal, the key nodes/steps/entities, decision points, and any required labels. Write in the user's language; professional layout will be applied. chart_type: Optional hint, e.g. "flowchart", "sequence", "architecture", "er", "org", "timeline", "infographic". Helps the model pick the right style. Leave empty to let the model decide.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| chart_type | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the outcome ('Returns a preview image and an editable link'), the automatic layout behavior, and the model-decides behavior when chart_type is empty. It does not address side effects like account persistence or permissions, but for a diagram-generation tool the core behavior is well covered.
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 structure is front-loaded with the primary purpose, followed by supported types, output, usage trigger, and parameter explanations. There is minor redundancy between the first two sentences, and the 'Args' block is slightly verbose, but each section earns its place.
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?
The description is complete for invoking the tool: it explains both parameters, when to use the tool, what output to expect, and how to handle ambiguity. It relies on the output schema for return details, which is acceptable. The main gap is the lack of comparative guidance against sibling diagram-generation tools, which could affect tool selection in ambiguous cases.
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 0%, so the description must fully explain the parameters. It does: 'prompt' is detailed with content, language, and layout guidance, and 'chart_type' is explained with examples and the default behavior of leaving it empty. This adds substantial meaning far beyond the bare schema.
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 primary action ('Generate an editable online diagram') and the input ('natural-language description'), and enumerates many supported diagram types. It does not explicitly differentiate itself from siblings like processon_design_diagram or processon_render_mermaid, so it misses the sibling-distinguishing bar for a 5.
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 gives explicit 'Use this whenever...' guidance with concrete trigger phrases in both Chinese and English, and instructs the agent to ask when the chart type is ambiguous. It does not mention when not to use this tool or how to choose between it and potentially overlapping siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert Markdown text into an editable ProcessOn mindmap.
Parses headings and bullet lists in the Markdown and renders them as an editable online mindmap. Great for turning meeting notes, an outline, or a document summary into a visual mindmap.
Args: markdown: The Markdown content (headings + bullet lists). title: Mindmap title. Auto-generated as "po-mcp-" when empty. structure: Layout style. One of: mind_free (自由), mind_right (向右), mind_org (组织), mind_ishikawa_left (鱼骨), mind_timeline_h (时间轴), mind_tree_free (树), mind_treeTable_left_title (树表).
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| markdown | Yes | ||
| structure | No | mind_free |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It does disclose that only headings and bullet lists are parsed, and that an empty title is auto-generated. However, it does not state that this likely creates a persistent mindmap resource, nor does it mention authentication, rate limits, or side effects. This is a notable gap for a tool that presumably performs a write 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 one-sentence purpose is front-loaded, followed by a brief elaboration and a well-organized 'Args' section. The structure list is somewhat long but necessary given the empty schema descriptions. Each sentence earns its place; no filler or repetition.
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 conversion tool with an output schema, the description covers the essential inputs and behaviors: Markdown format, title default, and layout options. The main missing piece is side-effect and authentication context, which would matter without annotations. Overall, it is adequate but not exhaustive.
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 0%, so the description fully compensates. Each parameter is explained: markdown's expected content, title's auto-generation behavior, and structure's allowed values with both English and Chinese labels. This goes well beyond the schema, which only provides types and defaults.
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 opens with a specific verb and resource: 'Convert Markdown text into an editable ProcessOn mindmap.' It then specifies the input format (headings and bullet lists) and the output (editable online mindmap), making its role distinct from siblings like processon_render_mermaid, which targets Mermaid rendering. The purpose is unambiguous.
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 gives clear context: 'Great for turning meeting notes, an outline, or a document summary into a visual mindmap.' This tells an agent when this tool is appropriate. It does not explicitly name alternatives or exclusions, but the use case is concrete enough that an agent can choose it over the other processon tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a Mermaid definition YOU wrote into an editable ProcessOn diagram.
This is the "edit → render" step of LLM-led diagramming. Give it the full Mermaid source code (your own, or refined from processon_design_diagram). ProcessOn renders it verbatim into a professional, editable online diagram and returns a preview image + an editable link.
The LLM fully owns the diagram content here — iterate the Mermaid text and call this again to get the next version. Supports the same shapes as Mermaid: flowcharts, architecture / network deployment, mindmaps, sequence, ER, class, timeline, C4, etc.
Args:
mermaid_code: The complete Mermaid source (e.g. starts with
graph TD, mindmap, sequenceDiagram, erDiagram).
title: Optional diagram title.
diagram_type: Optional shape hint, e.g. "flowchart", "mindmap",
"sequence", "er", "architecture", "network-deployment".
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| diagram_type | No | ||
| mermaid_code | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that rendering is verbatim, that the tool returns a preview image and an editable link, that the LLM fully owns content, and that repeated calls produce successive versions. This is substantial behavioral context beyond a simple action statement.
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 well organized and front-loaded: a crisp purpose sentence, then workflow context, then a clear argument list. Every sentence carries relevant information; none are redundant or filler. Length is justified by the need to explain supported Mermaid types and parameter usage.
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 three-parameter tool with no annotations and zero schema description coverage, this description is complete. It covers what the tool does, when to use it, how it relates to processon_design_diagram, what input to provide, what output to expect, and the iterative workflow. The existing output schema reduces the need to document return values further.
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 0%, so the description must compensate, and it does. Each parameter is explained with meaningful detail: mermaid_code is the complete source with example starting tokens, title is optional, and diagram_type is an optional shape hint with concrete examples. This fully adds value beyond the bare schema.
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 opening sentence states a specific verb and resource: 'Render a Mermaid definition YOU wrote into an editable ProcessOn diagram.' The description further distinguishes this from siblings by framing it as the 'edit → render' step and emphasizing that the LLM owns the diagram content, in contrast to design-oriented or generation-oriented tools.
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?
It gives clear workflow context: this is the 'edit → render' step, and you should provide the full Mermaid source, either your own or refined from processon_design_diagram. It also says to iterate by editing the Mermaid and calling again. It does not explicitly state when not to use it or name an alternative tool to use instead, but the positioning is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show current ProcessOn authentication status.
Reads PROCESSON_API_KEY (or cached OAuth token). Does not make a network call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It clearly discloses the data source (PROCESSON_API_KEY or cached OAuth token) and the key behavior that it does not make a network call. It does not describe failure modes when credentials are missing, but the output schema likely covers the return shape.
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 extremely compact: two short sentences plus a clear first line. Every sentence adds useful information—what it shows, where it reads from, and that it avoids network calls. No filler or redundancy.
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 zero-parameter tool with an output schema, this description is complete. The agent knows what the tool does, what credentials it uses, and that it has no network side effects. No additional information is needed to invoke or interpret the tool correctly.
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 tool has zero parameters, and the schema coverage is 100%, so there is nothing missing. The description adds no parameter-specific detail because none is needed; the baseline for zero parameters is 4.
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 states a specific verb and resource: 'Show current ProcessOn authentication status.' It clearly distinguishes this tool from sibling tools that generate charts or manage cache. The name 'whoami' reinforces the purpose without ambiguity.
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 gives clear context: it reads local credentials and does not make a network call, so an agent knows it can check auth status offline. It does not explicitly name alternatives or state when not to use it, but the usage context is sufficiently clear.
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.0.0processon_cache_clearprocesson_cache_infoprocesson_design_diagramprocesson_generate_chartprocesson_md_to_mindmapprocesson_render_mermaidprocesson_whoamiScored across 7 tools
processon_generate_chart and processon_design_diagram both take a natural-language prompt and diagram type, with one producing a rendered chart and the other producing Mermaid DSL; an agent could easily pick the wrong one. The descriptions help clarify the intended workflow, but the overlapping input/output shapes make selection ambiguous.
All tools share the processon_ prefix and use consistent lowercase snake_case. Most follow a verb_noun pattern like generate_chart, render_mermaid, and cache_clear, and the few exceptions like cache_info are still predictable and readable.
7 tools is well within the ideal range for a focused diagramming server. Each tool serves a distinct step or utility: auth, generation, design, rendering, markdown conversion, and cache management, so none feel superfluous.
The creation workflow is well covered: natural language to diagram, Mermaid design, rendering, and Mindmap conversion. However, there are no tools to list, fetch, update, or delete existing ProcessOn diagrams, so the surface lacks management lifecycle operations and relies on the user working through editable links externally.
Generate dynamic Mermaid diagrams and charts with AI assistance. Customize styles and export diagr…
Create and manage Mermaid.js flowcharts and diagrams with AI agents via MCP.
Generate cloud architecture diagrams, flowcharts, and sequence diagrams.
Create and edit architecture diagrams from your AI agent; get an SVG and a live editable canvas.
