cloudwright-mcp
The Cloudwright MCP server lets you design, cost, validate, and export cloud architectures using natural language across AWS, GCP, Azure, and Databricks.
Design & Modification
design_architecture— Generate a complete architecture spec from a plain-English descriptionmodify_architecture— Evolve an existing spec with natural-language instructions (e.g. "add a Redis cache")compare_providers— Translate an architecture across cloud providers to see equivalent service mappings
Cost Estimation
estimate_cost— Per-component monthly cost breakdown (offline)compare_provider_costs— Compare costs for the same architecture across providers (offline)
Compliance & Security
validate_compliance— Check against HIPAA, PCI-DSS, SOC 2, FedRAMP, GDPR, and AWS Well-Architectedsecurity_scan— Detect anti-patterns (unencrypted stores, public databases, missing WAF, etc.)scan_terraform— Audit existing Terraform HCL for security misconfigurationslint_architecture— Check for hygiene issues, anti-patterns, and best-practice violations
Analysis
analyze_blast_radius— Identify failure domains, SPOFs, and transitive component impactscore_architecture— Overall quality score (0–100) across reliability, security, cost, compliance, and complexitydiff_architectures— Compare two architecture versions with cost delta and compliance impact
Export
export_architecture— Export to Terraform, CloudFormation, Mermaid, D2, SBOM (CycloneDX), AI BOM, or compliance audit report
Discovery
list_services— List supported cloud services by providercatalog_search— Search instance catalog by vCPU, memory, price, or free-text for right-sizing
Multi-turn Chat Sessions
chat_create_session/chat_send— Stateful, context-aware architecture design conversations with optional provider, compliance, and budget constraintschat_list_sessions/chat_delete_session— Manage saved sessions
Provides Terraform exporter module for Databricks infrastructure as part of the multi-cloud infrastructure code generation capabilities.
Supports containerized deployment of the web server with Dockerfile and docker-compose.yml for production-ready containerization.
Supports Kubernetes service normalization across cloud providers (AWS EKS, GCP GKE, Azure AKS) in architecture specifications.
Supports MongoDB service normalization across cloud providers (AWS DocumentDB, GCP Cloud Datastore, Azure Cosmos DB) in architecture specifications.
Provides LLM capabilities for architecture design, modification, chat interactions, and ADR generation through OpenAI models like GPT-5, with provider-aware routing and API key configuration.
Supports PostgreSQL service normalization across cloud providers (AWS RDS, GCP Cloud SQL, Azure Database for PostgreSQL) in architecture specifications.
Supports Redis service normalization across cloud providers (AWS ElastiCache, GCP Memorystore, Azure Cache for Redis) in architecture specifications.
Generates Terraform infrastructure as code from architecture specifications, with provider-specific modules for AWS, GCP, Azure, and Databricks.
Cloudwright
Design a cloud architecture or plan a migration. Get costs, controls, code, and checked evidence.
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:8765Add --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.yamlThe 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.
--oscalwrites an OSCAL 1.1.2 component-definition with deterministic UUIDs.--traceabilityprints the chain from component to resource to control to status.cloudwright planrunsterraform validateagainst 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.mdDo 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 verifyreturn 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
Contributing guide: CONTRIBUTING.md
License: MIT, see LICENSE
Full release history: CHANGELOG.md
Available Tools
19 toolsanalyze_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.
catalog_searchA
Search the cloud instance catalog by provider, specs, or text query.
Returns matching instance types with instance family, vCPU / memory / storage, hourly on-demand price, region availability, and architecture (x86 / arm). All filters combine with AND semantics.
When to use: Right-sizing workloads, finding the cheapest instance that meets a hardware bar, or discovering equivalents across families.
Behavior: Pure lookup from the bundled SQLite catalog — no LLM, no
network. Prices reflect catalog snapshot date (see refresh CLI command
to update).
Inputs: provider, query, vcpus, memory_gb, +1 more. Returns: result
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
Scored across 19 tools
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.
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.
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.
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
Related MCP Connectors
Designs, prices, and deploys AWS/GCP cloud infrastructure from plain-English requirements.
Unified API to query AWS, GCP, Azure and generate Terraform/CLI execution kits for AI agents.
Simulate cloud infrastructure and estimate cost before deploying or changing infrastructure.
Compare, estimate, and deploy cloud infrastructure across AWS, GCP, and Azure for AI agents.
Related MCP Servers
- AlicenseAqualityCmaintenanceAI infrastructure design agent. Describe your app in plain English; Riley designs, prices, and deploys AWS or GCP infrastructure with generated Terraform.24Apache 2.0

Synlake MCP Serverofficial
AlicenseAqualityDmaintenanceEnables AI agents to discover, evaluate, and provision cloud infrastructure across AWS, GCP, and Azure with cross-cloud normalization, cost comparisons, and deployable execution kits.512 npmMIT- AlicenseNot gradedqualityDmaintenanceEnables LLMs to model, validate, and analyze multi-cloud infrastructure as a typed graph, with tools for IaC import/export, cost estimation, and architecture review.599 npmApache 2.0
- AlicenseAqualityCmaintenanceCloud infrastructure provisioning via natural language. Enables deploying production-ready infrastructure on AWS, GCP, Azure, or Oracle with a single prompt.1213 npmMIT