We Added MCP to Our Cloud Designer: Giving an AI Architect Live Tools
An AI assistant that designs cloud architecture is only as good as what it knows. Training data ages; your Terraform provider schemas, cloud prices, and docs don't wait. Here's how we wired the Model Context Protocol (MCP) into CloudForge — and the security model that makes agentic tool use safe inside a SaaS product.
Why MCP, and why now
Vani — CloudForge's AI architect — answers questions about the architecture on your canvas: what it costs, whether it violates policy, how to wire it. Before MCP, every answer came from model weights. That works for design principles; it fails for anything that moves: provider schema versions, regional prices, brand-new services.
The Model Context Protocol gives us a standard way to hand the model live tools instead of stale knowledge. An MCP server exposes tools over a simple JSON-RPC interface; the model decides when to call them mid-conversation. One protocol, any data source — which is exactly what you want when your users span three clouds and every conceivable stack.
What we shipped
Two things, both in the designer's Tools menu:
1. An integrations catalog (one click, zero config)
Connect any of the built-in servers and Vani can use them immediately during chat:
- Terraform Registry — live provider & resource schema lookups while generating IaC
- Azure Pricing / AWS Pricing — real price sheets instead of stale training data
- Microsoft Learn — authoritative Azure guidance, quoted with sources
- GitHub — read repos, issues, and workflows during design discussions
- Context7 & DeepWiki — up-to-date library docs and repo deep-dives
- Cloudflare Docs — edge and DNS design answers
- Hugging Face — model discovery for AI workloads
- Pulumi — Pulumi-side schema and conversion answers
When Vani uses a tool to answer, the response shows a small chip naming the server it consulted — no silent magic.
2. Bring your own MCP server
Teams have internal catalogs, price books, CMDBs, and runbooks. Register up to five of your own streamable-HTTP MCP servers (with custom auth headers) and Vani treats them exactly like the built-ins. Your internal tooling becomes part of the conversation.
The security model (the part that actually took thought)
Letting a SaaS backend call user-supplied URLs on behalf of an LLM is an SSRF machine unless you design otherwise. The rules we enforce:
- HTTPS only, no redirects.Every BYO server URL must be https, and redirect following is disabled so a well-behaved URL can't bounce us somewhere else.
- DNS-resolution guarding on every call.We resolve the host and reject private, loopback, link-local, metadata, and carrier-grade NAT ranges — re-checked at call time, not just at registration, so DNS rebinding doesn't help.
- Encrypted credentials. Auth headers are encrypted at rest; they never appear in logs or responses.
- Bounded tool loops.The model gets a fixed budget of tool rounds and a hard time limit per conversation turn. Runaway agent loops aren't possible by construction.
- Graceful degradation. If a server is down or slow, Vani answers without it. Tools add capability; they never add fragility.
- Namespaced tools. Every tool is prefixed with its server name, so two servers exposing
searchcan't shadow each other — and you can always tell who answered.
What it changes in practice
Ask "what would this diagram cost in Australia East?" and Vani queries a live pricing server instead of guessing from training data. Ask "what arguments does azurerm_kubernetes_clustertake in the latest provider?" and the answer comes from the Terraform Registry — current, not remembered. Wire in your own price book and the same question uses your negotiated rates.
This is the quiet shift MCP enables: the AI stops being a well-read consultant and starts being one with your systems on speed dial.
Try it
The MCP Integrations catalog and BYO servers are live for paid plans today — open the designer, hit Tools → Integrations, and connect your first server in one click.