CloudFormation support is live on the MCP server

One engine, now two languages

audytx has been a context-aware AWS Terraform reviewer since day one. As of engine v1.17, the parser front-end also reads CloudFormation and maps each template into the same resource vocabulary the rules and the cross-resource reasoning already understand — AWS::S3::Bucket lands where aws_s3_bucket does, before a single rule runs.

That one design decision carries the whole release:

• Same rule ids. A finding on a stack template has the id, severity, and remediation text it would have on Terraform. Mixed estates get one findings vocabulary, not two.
• Same context layer. audytx maps how the resources in a stack relate, and the false-positive suppression that map powers runs unchanged, each suppression printed with its rationale.
• Same response shape. scan_cloudformation reuses scan_terraform's implementation core, so agents consume both results with identical code.

Reading the template language properly

CloudFormation's intrinsic functions are a language, and a scanner that half-reads them manufactures false positives. The front-end ships with a real evaluator: YAML short tags (!Ref, !GetAtt, !Sub, !If), Fn::ForEach expansion, and symbolic tracking for ARNs that only exist at deploy time.

The case we sweated most is Fn::If. When a security-relevant attribute depends on a condition the template alone can't resolve, audytx evaluates both branches. If they disagree, the finding is marked conditional and annotated with why. It isn't dropped, and it isn't stated with more confidence than the template supports.

Behind the release sits a CloudFormation test corpus with positive and negative cases plus a set of benign templates, the same discipline the Terraform engine is held to.

One tool call

# Register audytx with your agent (Claude Code shown), then ask it to scan —
# or call the tool directly:
curl -s https://audytx.com/mcp \
  -H 'Content-Type: application/json' -H 'X-Client-ID: YOUR_CLIENT_ID' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{
        "name":"scan_cloudformation",
        "arguments":{"files":[{"path":"stack.yaml","content":"..."}]}}}'

Client IDs are free at the dashboard, and CloudFormation calls share your existing MCP quota — no new metering. A template is parsed in memory and not stored; the findings from a scan are kept in your dashboard for 90 days, like every hosted audytx scan.

What has shipped since

This note was written on the day CloudFormation support reached the MCP server. Everything it listed as still to come has shipped:

1. GitHub App. The GitHub App reviews CloudFormation pull requests: templates changed in a PR are detected and get the same summary comment, inline annotations and SARIF upload as Terraform.
2. SAM. AWS::Serverless::* resources are expanded into the CloudFormation resources the transform would generate and scanned with the same rules.
3. Change-set enrichment. A CI workflow can post DescribeChangeSet output to /changeset-upload (OIDC-authenticated, like plan upload), and the pull-request scan re-runs with resolved values.
4. CloudFormation benchmark. audytx's own results on three public CloudFormation corpora are on the CloudFormation benchmark.