Skip to main content
Glama

Cloudwright

Design a cloud architecture or plan a migration. Get costs, controls, code, and checked evidence.

PyPI CI License: MIT Python 3.12+ xmpuspus/cloudwright MCP server

pip install 'cloudwright-ai[cli]'
export ANTHROPIC_API_KEY=sk-ant-...
cloudwright design "HIPAA healthcare API on AWS with Postgres and Redis"

Cloudwright turns one line of English into a typed spec, a cost breakdown, a control-mapped compliance report, and infrastructure code. A source estate and target become ordered migration waves, explicit costs, and evidence gates. It covers AWS, GCP, Azure and Databricks across 114 service keys. Only design, modify, chat and adr call a model. Every other command runs offline and needs no API key.

Quickstart · Migrations · Compliance · Agents · Docs · Changelog

A prompt produces a spec, a cost, a control-mapped report, and Terraform

  • Spec. Typed YAML you commit, diff and review. Everything below reads from it.

  • Cost. Per component and region-aware, with a confidence flag on every line.

  • Compliance. HIPAA, SOC 2, PCI-DSS, FedRAMP, GDPR, ISO 27001 and NIST 800-53 control IDs.

  • Infrastructure code. Terraform, OpenTofu, Pulumi (TypeScript or Python) and CloudFormation.

  • Diagrams. ASCII, Mermaid, D2, and a web canvas you can edit by hand.

  • An MCP server, so any coding agent runs the same checks inside its own loop.

Exports carry safe defaults. S3 gets a public-access block, SSE and versioning. RDS gets encryption, multi-AZ and deletion protection. EC2 gets IMDSv2. A compliance framework overrides the workload profile, and always forces encryption and high availability.

Related MCP server: Synlake MCP Server

Quickstart

cloudwright design "HIPAA healthcare API on AWS with Postgres and Redis"
cloudwright cost spec.yaml --workload-profile medium
cloudwright compliance spec.yaml --frameworks hipaa,soc2
cloudwright export spec.yaml --format terraform -o ./infra
cloudwright plan spec.yaml --target terraform          # proves it deploys, never applies
cloudwright migrate demo                               # packaged migration proof, fully offline
cloudwright chat --web                                 # canvas at http://localhost:8765

Add --json before any subcommand for machine-readable output, or --stream to watch tokens arrive. Set ANTHROPIC_API_KEY or OPENAI_API_KEY for the four commands that need a model.

Migration plans stop when evidence is missing

The migration model covers infrastructure, applications, data, platforms, networks, facilities, and business services in one dependency graph. It works for on-premises, cloud, cross-cloud, hybrid, data-center, and application moves. It plans and checks work. It never copies data, applies infrastructure, switches traffic, or runs a cutover.

cloudwright migrate plan examples/migrations/ph-telco-project.yaml -o assessment.yaml
cloudwright migrate verify examples/migrations/ph-telco-project.yaml examples/migrations/ph-telco-evidence.yaml

The core has no telco fields. The first proof project selects an external ph_telco pack for subscriber, billing, usage-record, number-porting, privacy, recovery, and source-shutdown gates. A manufacturing ERP fixture proves the same planner works without that pack. Missing blocking evidence changes the result to closed: false and makes migrate verify exit with code 2. Each evidence file carries the deterministic assessment ID, so observations from an older target or cutover plan cannot close a revised assessment.

MCP clients use the same engine through plan_migration and verify_migration in the migration tool group.

See Migration planning and evidence for the file contract, Python API, HTTP routes, domain-pack format, limits, and recording commands.

Every finding carries the control ID it violates

Other tools scan infrastructure after you deploy it. Cloudwright maps each finding to its control before any resource exists. The fix then costs a spec edit instead of a change ticket. HIPAA 164.312(a)(2)(iv), SOC 2 CC6.1 and FedRAMP SC-28 come from the built-in scanner, with no extra tooling. Checkov folds into the same report when it sits on your PATH.

  • --oscal writes an OSCAL 1.1.2 component-definition with deterministic UUIDs.

  • --traceability prints the chain from component to resource to control to status.

  • cloudwright plan runs terraform validate against the export, and never applies.

The review needs no API key and no network

cloudwright review runs the scorer, the linter and the validator over a spec, and returns one severity-ranked report. The same three critics run inside cloudwright design. When blocking findings survive generation, the architect repairs the spec once and records the change in spec.metadata.critique. Pass Architect(repair=False) to turn that off.

Canvas edits never call the model, so they are instant and free

Add, drag, connect, edit and delete are deterministic frontend mutations. The Catalog drawer serves the resource list per provider and five approved multi-resource modules. Its standards check flags orphan connections, partial modules and missing tags. An intact module exports as a single Terraform module block, with the catalog's pinned source and version.

One MCP server reaches 11 coding agents

cloudwright integrate --harness claude-code       # exact wiring, in that client's format
cloudwright integrate --harness cursor --write    # merge it into the right file
cloudwright integrate --rules --agent-file claude # a gate block for CLAUDE.md

Do not hand-write the config. cloudwright integrate emits it for Claude Code, Cursor, Cline, Windsurf, GitHub Copilot, Zed, Codex CLI, Junie, Kiro and Antigravity. Aider gets a CLI-pipe recipe instead, because it speaks no MCP. Every client wants a different shape: Zed wants context_servers, Copilot wants servers, and Codex wants a TOML table.

The server exposes 24 tools in 10 groups: design, cost, validate, analyze, export, session, review, compliance, plan and migration. Full matrix in docs/integrations.md.

Offline commands grade, scan, compare, and plan

lint runs 10 anti-pattern checks. score grades 5 dimensions. analyze reports blast radius and single points of failure. policy enforces policy-as-code with 9 built-in rules. security scans the spec and the exported HCL. drift compares a design against a tfstate, and --remediate turns the gap into a cost, compliance and plan preview.

review, compliance and plan are above. See docs/cli-reference.md.

Python API

from cloudwright import ArchSpec
from cloudwright.cost import CostEngine
from cloudwright.validator import Validator
from cloudwright.exporter import export_spec

spec = ArchSpec.from_file("spec.yaml")
priced = CostEngine().estimate(spec, workload_profile="medium")
findings = Validator().validate(spec, compliance=["hipaa", "pci-dss"])
hcl = export_spec(spec, "terraform", output_dir="./infra")

v1.10.0 adds migration planning with evidence-based closure

  • One model covers the full estate. Infrastructure, data, applications, platforms, networks, facilities, and business services share one dependency graph.

  • Dependencies determine the waves. The planner schedules prerequisites first, rejects cycles, checks rollback paths, and reports unresolved mappings.

  • Closure needs evidence. Missing or failed blocking observations prevent closure and make migrate verify return exit code 2.

  • Industry rules stay outside the engine. Optional YAML packs add acceptance gates without adding industry fields to the core.

  • PH telco is the first proof. The product remains industry-neutral. A manufacturing ERP fixture runs through the same planner with no domain pack.

Earlier releases added control-ID mapping and plan (v1.5.0), the self-correcting architect and OSCAL (v1.6.0), cloudwright integrate (v1.7.0), the responsive dark-theme canvas (v1.8.0), and measured canvas interaction fixes (v1.9.0). Full history in CHANGELOG.md.

Compatibility

  • Python 3.12+

  • Models: Anthropic (Claude Sonnet, Haiku) and OpenAI (GPT-5+ family), auto-detected from env.

  • Clouds: AWS, GCP, Azure, Databricks. 114 service keys total.

  • Install variants: cloudwright-ai[cli], cloudwright-ai[web], cloudwright-ai-mcp.

Contributing, license, changelog

Available Tools

19 tools
analyze_blast_radiusA

Analyze blast radius and dependency structure of an architecture.

For each component (or just one, if component_id is set): returns direct dependents, transitive dependents, blast-radius size, SPOF status, and tier position. Use this to reason about failure modes — 'if component X dies, what else breaks?'

When to use: You have a spec and want to understand coupling and failure domains before production. Complementary to score_architecture (which gives a summary grade) and lint_architecture (which flags specific anti-patterns).

Behavior: Pure graph computation — no LLM, no network. Read-only. Does not touch cloud resources.

Inputs: spec_json (required), component_id.

chat_create_sessionA

Create a new stateful architecture-design conversation session.

Returns {'session_id': <12-char hex>}. The session_id is the handle for subsequent chat_send / chat_delete_session calls.

When to use: Multi-turn architecture design where each turn depends on the prior one (e.g. 'design it', 'now add a cache', 'now move to GCP'). For single-shot design use design_architecture; for one-shot edits of an existing spec use modify_architecture.

Behavior: Writes a new session file to the session store (persisted on disk). Does not call the LLM — the first LLM call happens on the first chat_send. Constraints are frozen at session creation and apply to every turn.

Inputs: provider, budget_monthly, compliance.

chat_delete_sessionA

Delete a conversation session.

Returns {'deleted': True} on success or {'error': ...} if the session did not exist. Destructive: the session's conversation history and any uncommitted spec are lost. There is no undo.

When to use: Clean-up after a completed design, or abandoning a dead-end conversation. Does not affect any deployed infrastructure — cloudwright never deploys anything.

Behavior: Removes the session file from the session store. No LLM, no network.

Inputs: session_id (required).

chat_list_sessionsA

List all saved conversation sessions.

Returns a list of session metadata: session_id, creation timestamp, last-activity timestamp, cumulative token usage, and whether the session currently owns a spec.

When to use: Resuming prior work, cleaning up abandoned sessions, or auditing session token spend.

Behavior: Pure disk read — no LLM, no network. Read-only.

Inputs: no named parameters. Returns: result

chat_sendA

Send a message to an existing conversation session and get a response.

Returns {'response': str, 'spec': dict|None, 'usage': dict, 'cumulative_usage': dict}. spec is populated when the turn produced or modified an ArchSpec. usage reports LLM token counts for this turn; cumulative_usage totals across the whole session.

When to use: Every turn after chat_create_session. For zero-state single-shot calls use design_architecture / modify_architecture instead.

Behavior: Calls an LLM — incurs API costs proportional to the conversation history length (history grows each turn). Persists updated session state back to the session store.

Inputs: session_id (required), message (required).

compare_provider_costsA

Compare the monthly cost totals of an architecture across cloud providers.

Returns one numeric cost summary per provider (monthly total, per-component breakdown, currency). Use this for cost-focused provider selection.

When to use vs compare_providers: This tool returns only cost numbers. compare_providers returns full alternative architectures (components, connections, tiers). If you want both the re-drawn architecture and its bill, call compare_providers first, then estimate_cost on each returned spec — or call both in parallel.

Behavior: Pure computation — no LLM, no network, no API costs. Uses the same offline catalog as estimate_cost. Does not deploy.

Inputs: spec_json (required), providers (required). Returns: result

compare_providersA

Compare an architecture's service mapping across cloud providers.

Returns one translated ArchSpec per target provider, showing which services the original would become on each. Use this to understand architectural portability and equivalent services.

When to use vs compare_provider_costs: This tool returns full alternative architectures (with components, connections, tiers). compare_provider_costs returns only numeric cost totals per provider — use that when you only care about the bill, not the shape.

Behavior: Calls an LLM to resolve ambiguous service mappings where the static equivalence table is insufficient. Does not deploy.

Inputs: spec_json (required), providers (required). Returns: result

design_architectureA

Design a cloud architecture from a natural-language description.

Primary entry point for greenfield architecture design. Returns a complete ArchSpec (YAML-serializable dict) with components, connections, tier assignments, and a cost estimate.

When to use: You have a requirement (prose) and need a concrete architecture with services, wiring, and cost. Use modify_architecture to iterate on an existing spec, or chat_create_session + chat_send for multi-turn refinement.

Behavior: Calls an LLM provider (Anthropic or OpenAI depending on configured keys) — incurs API costs per invocation. Deterministic post-processing layers (cost engine, catalog lookup) apply safe defaults like encryption-at-rest, multi-AZ on databases, and auto-scaling. Does not deploy or modify any cloud resources.

Inputs: description (required), provider, region, budget_monthly, +1 more.

diff_architecturesA

Diff two architecture specs and return a structured change report.

Returns a structured delta: components added / removed / modified, connections added / removed / modified, cost delta (USD/month), compliance-impact flags (e.g. WAF removal, encryption-at-rest turned off), and a human-readable summary.

When to use: You have two versions of a spec (before / after a proposed change) and need a reviewable diff for approval or ADR writing.

Behavior: Pure computation — no LLM, no network. Read-only. Does not modify either spec.

Inputs: old_spec_json (required), new_spec_json (required).

estimate_costA

Estimate the monthly cloud bill for an architecture spec.

Returns a structured estimate with per-component breakdown, total monthly cost, data-transfer costs, and currency. Deterministic: same spec + tier yields same result.

When to use: You need the numeric bill for one architecture on one provider+tier combination. For multi-provider comparison of just the costs, use compare_provider_costs. For side-by-side architecture + cost comparison across providers, use compare_providers + this tool.

Behavior: Pure computation — no LLM, no network, no API costs. Works offline. Does not deploy or touch cloud resources.

Inputs: spec_json (required), pricing_tier.

export_architectureA

Export an architecture spec to Terraform, CloudFormation, Mermaid, D2, or other formats.

Returns {'format': str, 'content': str} where content is the ready-to-write payload. Terraform/CFN outputs use variables for sensitive values (no hardcoded credentials), include provider blocks with region configuration, and generate data sources for VPC/subnet discovery.

When to use: You have a finalized ArchSpec and need IaC code, a diagram, or an audit artifact. For multi-format export, call once per format.

Behavior: Pure computation — no LLM, no network. Does not write files or deploy; the caller is responsible for persisting or applying the returned content.

Inputs: spec_json (required), format.

lint_architectureA

Lint an architecture for anti-patterns and best-practice violations.

Returns a list of warnings with rule name, severity (error / warning), component IDs involved, and a human-readable message.

Errors (production-blocking): unencrypted data stores, single-AZ databases, missing load balancer on public compute, public databases, single point of failure. Warnings (review-worthy): oversized instances (16xlarge+), missing WAF, missing monitoring, missing backups, missing auth.

When to use vs security_scan: lint is about architectural hygiene (is this a sane shape?). security_scan is about threat exposure (can an attacker reach X?). Use both for comprehensive review.

Behavior: Pure computation — no LLM, no network. Does not touch cloud.

Inputs: spec_json (required). Returns: result

list_servicesA

List all cloud services supported for a given provider.

Returns one entry per service with its slug, human-readable name, category (compute / database / storage / networking / etc.), and supported tiers. Use this to discover valid service: keys when hand-authoring ArchSpecs or mapping requirements to services.

Behavior: Pure lookup from the bundled service registry — no LLM, no network, no cloud access.

Inputs: provider. Returns: result

modify_architectureA

Modify an existing architecture with a natural-language instruction.

When to use: You already have an ArchSpec and want to evolve it (add a cache, swap a service, change a region). Returns the updated ArchSpec. For from-scratch design, use design_architecture. For iterative multi-turn editing with conversation memory, use chat_create_session.

Behavior: Calls an LLM provider — incurs API costs. Pure function: returns a new spec without mutating the input. Does not deploy.

Inputs: spec_json (required), instruction (required).

scan_terraformA

Scan Terraform HCL source for security misconfigurations.

Returns findings (severity-graded) tied to specific resource blocks — e.g. aws_s3_bucket with acl = public-read, aws_security_group with cidr_blocks = 0.0.0.0/0 on sensitive ports, aws_rds_instance with storage_encrypted = false.

When to use: You have existing Terraform code (not an ArchSpec) and want an immediate security audit. For ArchSpec-level audit, use security_scan.

Behavior: Pure computation — no LLM, no network. Does not run Terraform or touch cloud. Safe for scanning untrusted HCL.

Inputs: hcl_content (required).

score_architectureA

Score an architecture across reliability, security, cost, compliance, and complexity.

Returns the dimension scores, overall weighted score (0-100), letter grade, and per-dimension notes. Weights: Reliability 30% (load balancing, multi-AZ, auto-scaling, CDN, caching), Security 25% (WAF, auth, encryption, HTTPS, DNS), Cost Efficiency 20% (budget compliance, free- tier usage), Compliance 15% (framework validation), Complexity 10% (component count, connection density, tier separation).

When to use: You want a quick quality summary before a design review. For specific findings, use lint_architecture, security_scan, or validate_compliance.

Behavior: Pure computation — no LLM, no network. Read-only.

Inputs: spec_json (required).

security_scanA

Scan an architecture for security anti-patterns and misconfigurations.

Returns a structured report with severity-graded findings (critical / high / medium / low / info), each tied to specific component IDs. Framework- agnostic — use validate_compliance for specific regulatory frameworks.

Checks include: unencrypted data stores, public-facing databases, missing WAF on public HTTP endpoints, weak auth on APIs, SPOFs, overly permissive connection protocols.

Behavior: Pure computation — no LLM, no network. Does not touch cloud.

Inputs: spec_json (required).

validate_complianceA

Validate an architecture against compliance frameworks.

Returns one result object per framework with pass/fail status per check, evidence (which components triggered the rule), and remediation hints.

When to use: You have a proposed architecture and need to know whether it satisfies HIPAA / PCI-DSS / SOC 2 / FedRAMP / GDPR before proceeding. Use security_scan for anti-pattern detection (weak auth, public buckets, etc.) which is framework-agnostic.

Behavior: Pure computation — no LLM, no network. Evaluates the spec statically against 30+ rules. Does not access or modify any cloud resources.

Inputs: spec_json (required), frameworks (required), well_architected. Returns: result

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.7/5.0

    Scored across 19 tools

    Disambiguation4/5

    Most tools have distinct purposes with clear 'when to use' cross-references, but there is slight overlap between security_scan and lint_architecture (both catch similar issues), and between scan_terraform and security_scan (both scan for security misconfigurations). The descriptions help distinguish them, so confusion is unlikely.

    Naming Consistency5/5

    All tools follow a consistent verb_noun pattern: design_architecture, modify_architecture, compare_providers, estimate_cost, scan_terraform, chat_create_session, etc. The 'chat_' prefix for session tools clearly groups them, and each verb is meaningful and non-redundant.

    Tool Count5/5

    19 tools is slightly above the typical 3-15 range but well-justified given the server's broad scope: architecture design, cost estimation, compliance, security, IaC export, session management, and catalog lookup. Each tool has a clear role, and the count is reasonable for the domain.

    Completeness5/5

    The tool surface covers the full architecture lifecycle: design, modify, compare, cost, validate, security, lint, blast radius, diff, export, and session management. Missing deployment/apply is intentional (server does not deploy), and the catalog lookup tools support hand-authoring. No obvious gaps for the stated purpose.

    Maintenance

    ActivityStale
    ResponsivenessLimited data

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      A
      quality
      C
      maintenance
      AI infrastructure design agent. Describe your app in plain English; Riley designs, prices, and deploys AWS or GCP infrastructure with generated Terraform.
      24
      Apache 2.0
    • A
      license
      A
      quality
      D
      maintenance
      Enables AI agents to discover, evaluate, and provision cloud infrastructure across AWS, GCP, and Azure with cross-cloud normalization, cost comparisons, and deployable execution kits.
      5
      12 npm
      MIT
    • A
      license
      A
      quality
      C
      maintenance
      Cloud infrastructure provisioning via natural language. Enables deploying production-ready infrastructure on AWS, GCP, Azure, or Oracle with a single prompt.
      12
      13 npm
      MIT