This server turns a ProcessOn account into an LLM-driven diagramming engine, letting you create, edit, manage, share, and export editable ProcessOn diagrams via MCP tools.
Auth & status: processon_whoami shows account/auth status; processon_cache_info and processon_cache_clear manage cached tokens/data.
AI diagram generation: processon_generate_chart creates editable online diagrams from natural-language prompts (flowcharts, sequence, architecture, ER, org charts, timelines, etc.).
LLM-led Mermaid workflow: processon_design_diagram drafts Mermaid code, then processon_render_mermaid renders it into an editable ProcessOn chart.
Native drawing: processon_draw_flowchart draws editable shapes/edges with auto-layout, themes, line styles, and group containers; processon_draw_mindmap and processon_make_mindmap create mindmaps with branches, summaries, boundaries, and links.
Markdown conversion: processon_md_to_mindmap turns Markdown headings/bullets into an editable mindmap.
File management: create folders, list files, create/rename charts, move files/folders, and delete charts to trash.
Sharing & export: processon_share_chart generates public share links; processon_get_chart_def reads chart JSON; processon_export_vsdx exports to Visio; processon_export_jpg exports a high-res JPG server-side.
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.
Turn your own ProcessOn account into an LLM-driven diagramming engine.
Draw flowcharts, mindmaps and outlines natively — no paid AI credits, no bitmaps, every shape is editable.
Most ProcessOn integrations just call the paid "AI generate" endpoint: you burn credits, get a flat image, and can't tweak it. This project goes deeper — it drives ProcessOn's native canvas editor the same way a human would, so the LLM itself assembles editable shapes, connectors, mindmap branches and annotations, and ProcessOn spends zero AI quota.
The output is always a live, editable online diagram — not a screenshot.
Related MCP server: @processon/mcp-server-processon
Zero-quota native drawing — LLM authors shapes/edges directly onto the canvas; no AI consumption, no bitmap.
Three editor protocols, reverse-engineered and working:
flowbase — flowcharts & architecture: rectangles, decision diamonds,
terminators, arrows with 4 line styles (solid/dashed/dot/dashdot) and
straight (normal) or elbow (broken) routing, auto-sized boxes (long
labels wrap inside the shape), layered auto-layout (Sugiyama-style:
hierarchy layers + barycenter ordering to cut crossings; every layer is
centred on the widest band so the spine reads symmetrically), no-crowding
guarantee (boxes are never closer than a hard floor — crowded or
overlapping inputs are pushed apart), dashed group containers (give
nodes a group and the tool wraps them in a dashed transparent frame for
architecture layers/subsystems, with a light tinted background that
contrasts the dark node fills), edges anchor on the frame edge (correct
ProcessOn anchor angles — no lines cutting through boxes), elbow routes bend
in the inter-layer gap, elbow horizontal segments are routed around unrelated
node/container boxes (cross-layer lines never slice through a box), remaining
crossing lines get distinct colors and dash styles automatically, 4 built-in themes, colored fills, hidden
grid.
outline — outliner / thinking notes, root-level tree writing.
mind_free — real mindmaps with auto-colored branches.
Mindmap annotations — summary (概要), boundary (外框), and
cross-node links (跨节点连线), all verified end-to-end.
Full file management — create folders (idempotent path), list files,
create/rename charts, move charts/folders, delete to trash. Building
blocks are idempotent: ensure_folder_path reuses same-named folders,
ensure_chart overwrites a same-named chart (delete + recreate), so rerunning
never spawns duplicates. Via account login (JWT, auto re-auth on 401/408).
Public share links — share_chart opens sharing and mints the
https://www.processon.com/view/link/{viewLinkId} URL (the link id is
server-assigned, permanent by default, idempotent on re-share). Hand-rolled
against the private web API — no official SDK.
Chart read-back + .vsdx export
Server-side high-res JPG export — processon_export_jpg triggers
ProcessOn's own export pipeline (/chart/export/get/user/power,
exportType=jpghd), then polls for the KS3 CDN URL and streams the bytes.
Gives a real 135KB+ PNG-quality JPG without a browser. — processon_get_chart_def reads a chart's
full element JSON back from ProcessOn (chartdefids → chart/def);
processon_export_vsdx renders it to a standalone .vsdx (Visio) file in
pure Python (no Visio install): rectangles / diamonds / terminators, linker
edges, group frames, px→inch conversion, y-flip, centered text. Designed for
Visio / drawio; containers render bottom-most so covered nodes aren't dropped.
Dual auth — sk-po-... token for the AI surface, account+password for
the personal file surface.
Standard MCP — tools over stdio (default) or Streamable HTTP, pluggable SQLite cache.
uv venv && uv pip install -e . # or: pip install -e .Copy .env.example → .env and fill in:
# Drawing (AI surface, Bearer token from https://smart.processon.com/user)
PROCESSON_API_KEY=sk-po-...
# Files / native canvas (your personal account)
PROCESSON_ACCOUNT=your_phone
PROCESSON_PASSWORD=your_password # MD5-hashed in transitprocesson-mcp # stdio — for Doubao / Claude / Cursor
processon-mcp --transport http --port 3100Tool | What it does |
| Show account + auth status |
| Organize "My Files" |
| Create an empty editable chart ( |
| Rename a chart |
| Move charts/folders, delete chart to trash |
| LLM draws native shapes + edges into a chart — auto-sized boxes, layered auto-layout, crossing auto-recoloring, per-edge color, line styles, straight/elbow links, theme |
| Outline-style mind notes |
| Real mindmap with colored branches + summary / boundary / links |
| Open public sharing → return |
| Mermaid draft → editable render |
| One-shot natural-language chart (AI surface) |
| Markdown → editable mindmap |
| Read a chart's full element JSON back (chartdefids + chart/def) |
| Read chart def → render to a local |
| Trigger server-side export → stream high-res |
# create_chart → draw_flowchart(nodes, edges, theme="techblue")
nodes=[{"id":"start","label":"开始","shape":"terminator"},
{"id":"auth","label":"登录","shape":"rectangle"},
{"id":"ok","label":"校验通过?","shape":"decision"}]
edges=[{"from":"start","to":"auth"},{"from":"auth","to":"ok"}]
# Boxes auto-size to labels; nodes auto-layout into hierarchy layers with
# reduced crossings (omit x/y, or pass auto_layout=True).
# optional per edge: "style": "solid"|"dashed"|"dot"|"dashdot",
# "type": "broken"|"normal" (elbow vs straight),
# "color": "#RRGGBB"|"r,g,b"
# Lines that still cross get distinct colors + dash styles automatically.Every shape is a native ProcessOn object — click it in the browser and edit text, color, geometry, exactly as if you had drawn it by hand.
nodes=[
{"text":"认证体系","summary":"两套认证","boundary":"基础",
"children":[{"text":"sk-po token"},{"text":"账号密码"}]},
{"text":"画图能力","children":[
{"text":"流程图"},
{"text":"思维导图","links":[{"to":"sk-po token","label":"共用"}]}]},
]
# summary = 概要条, boundary = 外框, links = 跨节点连线Native writing targets flowbase / outline / mind_free. markdown-type
files use a collaborative document format with no public write API.
Mindmap links use a fixed anchor template; extreme layouts may need manual nudging.
Rendering is async on ProcessOn's side (seconds), timeout 180s.
.vsdx export targets Visio / drawio (offline editing/archive). Round-tripping
the .vsdx back into ProcessOn may lose styling, since ProcessOn's own importer
simplifies shapes and folds groups — that is its importer's behaviour, not an export bug.
src/processon_mcp/
├── server.py # MCP tools/resources/prompts
├── processon_client.py # dual-auth HTTP client + all 3 editor protocols
└── cache/sqlite_cache.pyUnofficial integration against ProcessOn's private web + AI APIs. Not affiliated
with ProcessOn. Your token and password are secrets — 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.
Create workflow, sequence, architecture, and mind map diagrams via AI assistants.
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.
