Free tools Windows power users keep installed
One-click scans. No signup required.
In Ryota Sago’s September 2026 comparison, spelling out the desired layout, icons, labels, and connector behavior improved AWS architecture diagrams more than switching among the five tested Claude Code setups. After refining the prompt, Sago found three options he would use, but no clear overall winner. That is a useful result for anyone generating diagrams with Claude Code—though it comes from three runs of one two-AZ example, not a broad benchmark.
What Sago compared
Sago tested five ways to produce a diagram of a two-availability-zone (AZ) web application, using Claude Code 2.1.278 with Claude Opus 5. The example included CloudFront in front of an Application Load Balancer (ALB), an ECS Fargate service, Aurora MySQL with a writer and reader in different AZs, S3 static files, CloudWatch logs and metrics, public and private subnets, and one NAT Gateway per AZ.
| Setup | Requested or reported output | Author-reported average time per run | Author-reported average output tokens | Observed repeatability |
|---|---|---|---|---|
| AWS Diagram MCP Server 1.0.23 | PNG only | 5.5 minutes | 23,393 | Results changed a lot between runs |
AWS aws-architecture-diagram skill |
draw.io XML | 5.4 minutes | 33,510 | Small changes between runs |
| draw.io MCP Tool Server | draw.io XML | 4.1 minutes | 25,439 | Nearly identical, but the NAT Gateway icon differed each run |
| draw.io Claude Code plugin | draw.io XML | 5.8 minutes | 34,544 | Nearly identical, but S3 moved around |
| Plain Claude Code, without an MCP server or skill | draw.io XML | 5.4 minutes | 32,805 | Nearly identical |
The time and token figures are Sago’s averages across three runs per setup in 2026; they are not independently reproduced measurements. He assessed repeatability by rough visual comparison, not a formal metric. His evaluation also considered cost, faithfulness to requirements, readability, visual style, and editability.
Why the prompt mattered
The initial request described components and placement, but Sago found none of the five first outputs usable without edits. Reported problems included labels crossed by lines, extra panels and notes, generic boxes instead of AWS service icons, inconsistent service labels, and distracting shapes. He then revised the prompt to specify the visual result, not just the inventory of services.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problems#1 Best Overall
Specify layout and hierarchy
In the final prompt, Sago spelled out the AZ names, put users at the top, and placed public subnets above private subnets. Those are his preferences for this example, not universal AWS diagram rules. The general lesson is to state the hierarchy and grouping you want rather than expecting the model to infer them from a service list.
Specify icons, labels, and connectors
He asked for official, service-level AWS icons; labels below icons; and lines that do not run across icon or label text. He also asked for connectors to start near the middle of icon edges where possible, with crossings allowed only when lines do not overlap. These rules make visual expectations testable: you can inspect whether a line obscures text or whether a service has the intended icon.
Say what belongs—and what does not
Sago asked the diagram to omit an external title, legend, or explanation panel, while allowing line labels and short notes attached to relevant components. Explicit exclusions matter: otherwise a model may add explanatory material that makes a diagram less useful for its intended context.
A practical prompt pattern for your own diagram
Separate architecture facts from presentation instructions. First list components, relationships, and boundaries; then describe how they should be drawn. For example, adapt this checklist to your system rather than treating its layout choices as mandatory:
- Architecture: name each service, network boundary, subnet, region or AZ, and the direction or nature of each connection.
- Layout: state the intended reading order, grouping, and relative placement of major components.
- Visuals: request current official AWS service icons and specify where labels should sit.
- Connections: say where lines should attach, whether they may cross, and what they must not obscure.
- Content boundaries: list required line labels or short notes, and explicitly forbid unwanted panels or decoration.
- Deliverable: request an editable format such as draw.io XML if you expect to revise the result.
Then iterate against visible defects: name the problem and the correction, such as “move the label below its icon” or “route the connector without crossing text.” A prompt can improve the rendered layout, but it cannot substitute for checking whether every required service and relationship is present.
Visual polish is not architectural correctness
Review semantics separately from appearance. In Sago’s run, the AWS skill omitted CloudWatch and Aurora replication lines; the AWS skill and draw.io MCP output also used the VPC icon for NAT Gateways. These examples show why a neat diagram is not proof that the architecture is faithfully represented.
- Check that every requested service appears and uses the intended service-level icon.
- Trace each required relationship, including replication and observability connections, from its source to its destination.
- Confirm that network boundaries and AZ placement match the design, not merely the preferred visual layout.
- Inspect label placement and connector paths after validating the architecture.
AWS provides official architecture icon resources and says customers and partners may use its toolkits and assets in diagrams. AWS also advises checking third-party icon libraries for legacy sets. Its published release schedule describes updates in Q1 (end of January), Q2 (end of April), and Q3 (end of July), with no Q4 release. For an operational diagram, use the current official assets rather than assuming a third-party library is up to date.
Which setup should you choose?
For the tested example and refined prompt, Sago judged the draw.io MCP Tool Server, draw.io Claude Code plugin, and plain Claude Code to be at a level he would use. He did not identify a clear winner. The results support choosing based on what you need to do with the output and how you want to work—not assuming that an integration alone fixes an underspecified request.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →| If your priority is… | What the comparison supports |
|---|---|
| Editing the diagram afterward | Four setups were asked for draw.io XML; the AWS Diagram MCP Server produced PNG only in this comparison. |
| A tested option Sago considered usable | He named the draw.io MCP Tool Server, draw.io Claude Code plugin, and plain Claude Code after refining the prompt. |
| Picking the fastest measured setup | The draw.io MCP Tool Server had the lowest reported average, 4.1 minutes per run across Sago’s three 2026 runs. This small test does not establish that it will be fastest for other diagrams. |
| Choosing by output-token use | The AWS Diagram MCP Server had the lowest reported average, 23,393 tokens per run; the draw.io plugin had the highest, 34,544. These author-reported figures do not by themselves measure diagram quality or cost. |
Tool availability and alternatives
Tool status can change independently of the diagram-prompt findings. In a June 2026 update, AWS said the original awslabs.aws-diagram-mcp-server was deprecated and all versions had been taken down from PyPI. AWS said the diagram agent skill in its deploy-on-aws plugin superseded it, and recommended diagrams-mcp for its Kiro CLI tutorial. Treat that as the status reported in the June 2026 update, not a guarantee of availability on a later date.
Mermaid Chart describes an MCP server that generates, validates, and renders diagrams from Claude, and presents text-based diagrams as suitable for keeping alongside code. That may fit a text-first, version-controlled workflow, but it was not one of Sago’s five tested setups, so the comparison provides no evidence about its relative performance. AWS’s icon resource page also lists tools such as draw.io and Figma as diagramming options.
What this comparison can—and cannot—tell you
The experiment is narrowly scoped: one standard two-AZ architecture, one Claude Code and model version combination, and three runs for each setup. The original prompts were in Japanese, with English translations in Sago’s article. The findings do not establish how these options compare for multi-account, hybrid, or very large diagrams, nor do they establish that the same prompt rules or winner apply to another architecture or model.
Within those limits, the useful finding is practical: describe the diagram you want in addition to the architecture you need represented. Request an editable file when revision matters, and check both the visual result and the underlying service relationships. Sago’s results suggest the refined instructions made a substantial difference; they do not show that tool choice never matters.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
