diag-weaver

by wldxiaobai

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes: read, replace, patch, snapshot, restore, export, and ensure editor. The only mild ambiguity is editor_ensure versus diagram_read, both related to canvas state, but their descriptions make the separation clear.
Naming Consistency4/5
Six of seven tools follow the diagram_verb pattern (diagram_read, diagram_replace, diagram_patch, etc.). editor_ensure breaks the pattern with a different prefix and verb style, but the inconsistency is minor and the names remain readable.
Tool Count5/5
Seven tools is a well-scoped set for a diagram editing server. Each tool covers a distinct operation without unnecessary bloat, and the count feels appropriate for the domain.
Completeness4/5
The toolset covers the core diagram lifecycle: read, modify, replace, snapshot, restore, and export. Minor gaps exist, such as no explicit snapshot deletion or fine-grained style/position editing, but agents can accomplish the main workflows without dead ends.
Average 3.8/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It usefully discloses that relative paths resolve against the process cwd and that no write occurs without a path, but it does not mention overwrite behavior, return values, or error conditions for 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, front-loaded sentences with no filler. Each sentence adds relevant information: the core write action, path resolution behavior, and the no-write guard.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter export tool, the description covers the destination, format, and path resolution. It is missing explicit overwrite semantics and return behavior, which would be useful for a write operation with no annotations and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single path parameter with 100% coverage, including an example. The description adds minor context about cwd-relative resolution, but the schema carries most of the parameter meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (write), the resource (current diagram), and the output format (.drawio) to an explicit filesystem path. It is distinct from the sibling tools by nature, but it does not explicitly name a sibling or state what it is not, so it falls short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: export the current diagram to a file. However, there is no explicit guidance about when to prefer this over diagram_snapshot, diagram_restore, or other siblings, and no when-not-to-use conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the behavioral burden. It does well by revealing a non-obvious behavior: 'Do not supply x/y; draw.io layout places new cells' and 'Coordinates belong to the editor, not the model.' It does not disclose broader mutation consequences like idempotence or validation behavior, which keeps it from being a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded, and wastes little space: it opens with purpose and immediately gives the actionable coordinate warning. The final sentence, 'Coordinates belong to the editor, not the model,' is conceptually useful but somewhat redundant with the preceding sentence, preventing a full 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is reasonably complete for a small patch tool: it names the supported edit types and warns against a common invalid input class. Missing context includes how the 'layout' parameter behaves, how references between operations are resolved, and what kind of response or effect to expect for a nuanced nested operations array.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It partially compensates by enumerating the operation types and explaining that coordinates should not be user-supplied. However, it never mentions the 'layout' parameter, which is one of only two parameters, omitting meaningful guidance about what layouts do or when to choose them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Apply a few structured edits (add_node, add_edge, set_label)'. It clearly identifies what the tool does at a glance. It does not explicitly contrast itself with sibling tools like diagram_replace, so it falls short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Apply a few structured edits' implies this tool is for incremental changes rather than wholesale replacement, giving some contextual usage signal. However, it does not explicitly state when to prefer diagram_patch over diagram_replace or any other sibling tool, and it provides no exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose a destructive side effect ('Replace the whole diagram'), a live-canvas load, and layout application. It does not mention reversibility, whether existing unsaved edits are destroyed, or whether the operation can be undone — for a destructive whole-replacement tool this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the primary action is front-loaded, then a behavioral note, then a usage preference. Every sentence contributes distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations, no output schema, and no mention of return values, failure modes, or the destructive consequence of wiping the existing diagram before a snapshot is taken. For a whole-diagram replacement tool, important operational context is missing — an agent could destroy work without being warned to snapshot first.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, and the schema already describes layout and content; format is defined via enum. The description adds context that format maps to Mermaid vs draw.io XML and that layout is applied by draw.io, but does not meaningfully enrich individual parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Replace'), resource ('whole diagram'), and accepted formats ('Mermaid or draw.io XML'). The phrase 'whole diagram' clearly distinguishes it from the sibling diagram_patch, which implies partial edits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit guidance to prefer this over many tiny geometry edits, implicitly routing agents away from diagram_patch. However, it does not explicitly name the alternative tool nor state conditions like when to use diagram_patch or when a snapshot/restore workflow is advisable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden of behavioral disclosure. It usefully states that snapshots live under the user data directory and not the agent cwd, but it does not disclose whether reusing the same label overwrites an existing snapshot or creates a duplicate, nor what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tightly worded sentence that front-loads the action and immediately states the critical location constraint. Every element earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-like snapshot operation, the description is largely complete for correct invocation: action, destination, and labeling are covered. The only substantive gap is duplicate-label behavior, which would strengthen the description further but is not essential for a first call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter 'label' with a helpful example, so the schema covers the semantics. The tool description adds no additional meaning beyond the schema, keeping this at the baseline score for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('Copy'), the resource ('current diagram'), and the destination ('a labeled snapshot under the user data directory'). The explicit parenthetical 'not the agent cwd' prevents a common mistake and helps distinguish this from file-exporting siblings like diagram_export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The snapshot concept implies a checkpointing use case, but the description does not explicitly say when to prefer this over diagram_restore, diagram_export, or diagram_patch. It provides useful context about where the snapshot is stored, but no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to fall back on, the description discloses meaningful behavior: it may open a browser, it blocks/waits for a connection, and it does not create store directories. However, it omits details such as timeout behavior, side effects of launching a browser, or what 'connected' means, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with an active verb, immediately states the action and wait condition, plus a useful explicit non-effect. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter setup tool, the description covers what the tool does, the environment it affects, and an explicit non-effect. It lacks timeout/failure details, but the schema and parameter surface are minimal, so this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is complete, so the baseline of 4 applies. The description does not need to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Open the local draw.io canvas') and an outcome ('wait until it is connected'), which is distinct from all sibling diagram_* tools that perform modifications or reads on diagrams. The negative claim 'does not create store directories' also helps disambiguate scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While 'if needed' implies this is a setup or prerequisite step, the description provides no explicit guidance about when to call this tool versus alternatives, nor any conditions under which it should be skipped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure, and it does state that restore copies a snapshot to current and loads it, and that there is no separate checkout/rollback. That covers key semantics, but it does not explicitly warn that existing canvas content is overwritten or whether the operation is destructive/reversible, so the disclosure is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, and the core action is front-loaded before the behavior qualifier. Every sentence adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-optional-parameter restore tool, the description covers the main invocation modes and the copy/load semantics. The main gap is no explicit statement about overwriting/destroying current canvas state, which matters for a mutation tool with no annotations or output schema to fall back on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by explaining that label identifies the snapshot to restore and that omitting it lists snapshots. It defines the parameter's role and optionality, which is sufficient for a single string parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Restore') and a specific resource ('labeled snapshot onto the canvas'), making the tool's core function immediately identifiable. It also distinguishes restore from list mode and clarifies the copy/load semantics, which separates it from generic canvas-editing siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It offers one useful usage signal: omitting label switches to listing snapshots. However, it does not say when to choose this tool over siblings like diagram_snapshot, diagram_replace, or editor_ensure, nor does it state the conditions under which restore is the appropriate operation (e.g., rollback vs. editing).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It discloses the default summary format, the XML option, the live/saved canvas fallback, and the explicit side-effect note that it does not create directories. It could additionally state that it never modifies the diagram, but 'Read' already implies that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences, front-loaded with the core purpose, then parameter behavior, then source selection and side-effect note. No filler, no repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one optional parameter, and the description covers the parameter, source fallback, and non-mutating behavior. Since there is no output schema, a bit more detail on what the compact summary actually contains would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully explains the only parameter: 'summary' maps to 'compact cell summary for the agent' and 'xml' maps to 'full draw.io XML'. This adds substantial meaning beyond the raw enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Begins with a specific verb and resource: 'Read the current diagram'. It clearly states the two output modes and source selection, but it does not explicitly differentiate itself from the diagram_export sibling, which could also be a read-like operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear guidance on when to use each format ('Default is a compact cell summary', 'Pass format=xml for the full draw.io XML') and on the live vs. saved canvas fallback. It does not explicitly name alternatives or exclusions, but the context is strong enough for an agent to choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

diag-weaver MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![diag-weaver MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/wldxiaobai/diag-weaver/badges/card.svg)](https://glama.ai/mcp/servers/wldxiaobai/diag-weaver)

Score Badge

Copy to your README.md:

[![diag-weaver MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/wldxiaobai/diag-weaver/badges/score.svg)](https://glama.ai/mcp/servers/wldxiaobai/diag-weaver)