
OpenTofu Test
io.github.ogormans-deptstack由 GitHub 帳號 ogormans-deptstack 發布v0.1.0更新於 Oct 26, 2026
MCP server for the OpenTofu/Terraform native test framework: scaffold, mock, validate, run tests
概覽
針對 OpenTofu/Terraform 原生測試框架的 MCP 伺服器,讓助理產生、模擬、驗證並執行 .tftest.hcl 測試。
- 可以做什麼
- 查詢測試框架各區塊的參考與範例(run、assert、mock_provider、expect_failures)
- 依模組實際的變數與輸出產生 .tftest.hcl 測試骨架
- 依已初始化模組的 provider schema 產生 mock_provider 區塊
- 依路徑或原始內容靜態驗證測試檔,不執行 OpenTofu
- 執行測試套件並回傳精簡的逐 run 通過/失敗摘要
- 適用情境
- 適合在助理撰寫或修正 OpenTofu/Terraform 原生測試、經常寫出錯誤的 run、assert 或 mock_provider 區塊時使用,也適合想從現有模組產生測試並在執行前先檢查的情境。
- 執行需求
- 以本機 stdio 程序執行,可透過 go install 或已發佈的容器映像安裝。需要 schema 與執行功能的工具要求 PATH 中有 tofu(優先)或 terraform;參考查詢與靜態驗證工具則不需要。未宣告任何帳號、API 金鑰或環境變數。
安裝
在 SourceWeft 中
- 開啟 儀表板中的 OpenTofu Test,將其新增到工作區。
- 為需要使用其工具的對話啟用該服務。
Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。
其他 MCP 客戶端
參照 儲存庫 中的啟動說明。
README
opentofu-test-mcp
An MCP server for the OpenTofu / Terraform
native test framework (.tftest.hcl / .tfmock.hcl).
LLM agents are good at writing Terraform but routinely produce broken run,
assert, and mock_provider blocks because the test-framework grammar is small
but unforgiving. This server gives an agent the exact block reference, scaffolds
tests from a module's real variables and outputs, generates mock providers from
the installed provider schema, validates test files statically, and runs the
suite — so the agent can author and check tests without guessing.
It drives the tofu CLI when present and falls back to terraform.
Tools
Install
Requires tofu (preferred) or terraform on PATH for the schema- and
run-backed tools. tf_explain_test_schema and tf_validate_test work without
either.
Prebuilt binaries for macOS, Linux, and Windows (amd64/arm64) are distributed with checksums on GitHub Releases. Native binaries still need a separately installed OpenTofu or Terraform CLI.
Container
The release workflow publishes an image with OpenTofu included:
Use -i, not -t: stdio must remain an unmodified JSON-RPC stream. Module paths
passed to tools must be container paths, such as /workspace, not host paths.
Only mount modules you trust: native tests can apply real infrastructure and
execute provider code. The image does not inherit host cloud credentials.
Configure (client)
For Docker, configure command as docker and args as
["run", "--rm", "-i", "-v", "/absolute/module/path:/workspace", "ghcr.io/ogormans-deptstack/opentofu-test-mcp:0.1.0"].
Example
Ask the agent to "scaffold a test for this module and run it":
tf_scaffold_test { "dir": "." }→ a.tftest.hclskeleton.tf_gen_mock_provider { "dir": "." }→mock_providerblocks (module must be initialized).tf_validate_test { "path": "main.tftest.hcl" }→ structural problems, if any.tf_run_tests { "dir": "." }→passed=1 failed=0 errored=0 skipped=0.
Development
Automated MCP checks with Inspector
Requires Node.js 22.19+, Go, and OpenTofu 1.13.1 on PATH. Inspector is
pinned in package-lock.json; Node is development tooling, not a server runtime
dependency.
This launches the built server through the
Inspector CLI
over real stdio. It checks initialization, the exact five-tool inventory,
portable input schemas (tools/list --strict), structured output, all five
tools, a missing-input error, and both passing and deliberately failing native
tests. Fixtures use OpenTofu's built-in terraform_data provider, so no cloud
credentials or provider downloads are needed. The failing fixture is intentional.
Tests work in a temporary copy and use an in-memory Inspector secret store.
To check the container with the same suite:
To check another build, set MCP_SERVER=/absolute/path/to/opentofu-test-mcp.
CI runs both native and container smoke tests in addition to Go race tests.
For individual checks or interactive debugging:
Before contributing an MCP change, reproduce the behavior using a disposable
fixture, add assertions for the regression and its error path, then run the Go
and Inspector suites. Assert the JSON result, not just process exit status:
Inspector exits 5 for isError: true and 6 for strict schema failures,
but a valid tf_validate_test response with valid: false or a native test
summary with failed > 0 still exits successfully. Inspector checks complement,
not replace, unit tests; they do not prove semantic correctness of every
Terraform expression or compatibility with every MCP client.
The Inspector documentation
also describes the TUI and experimental mcpdo persistent connection client.
The CLI is sufficient for this server's stateless requests; use a persistent
client for future session-dependent flows. The pinned CLI defaults to the legacy
protocol era, matching the server SDK; do not force modern-era negotiation
without upgrading and testing the server first. Keep the web UI's default
loopback binding and authentication enabled, and do not put secrets in fixture
files or captured transcripts.
Releasing
- Update
server.json's top-level version and OCI identifier tag together. Commit the changes and wait for CI on that commit. - Tag that tested commit (for example
git tag v0.1.0) and push the tag..github/workflows/release.ymlrefuses mismatched versions and reruns CI. - The workflow builds six native archives with checksums, creates a GitHub
release, and publishes a Linux amd64/arm64 OCI image. The image embeds the
release version and the MCP Registry ownership label
io.modelcontextprotocol.server.name. - On the first release, GitHub may create the GHCR package as private. Change its package settings to public, then rerun failed workflow jobs. The workflow checks anonymous image access before registry publication.
- The final job validates
server.jsonand publishes it using GitHub Actions OIDC (id-token: write), without a long-lived registry secret.
Registry publishing follows the official OCI package requirements and GitHub Actions guide. The registry hosts metadata, not the binary or image, so the package must be publicly available first. Do not submit a PR to the registry repository.
OCI package entries must not contain registryBaseUrl, version, or
fileSha256; the full registry and version belong in identifier. The
publisher's validate command does not perform every package-specific check
that publish does, so the smoke suite checks those constraints too.
To retry registry publication after a metadata-only correction without moving
the release tag or rebuilding artifacts, push the correction and dispatch the
registry-only workflow: gh workflow run publish-mcp.yml --ref main. It checks
the existing public image and uses OIDC, just like the tag-triggered release.
For registry publication outside Actions:
Authenticate as ogormans-deptstack (or an authorized namespace owner), not an
unrelated GitHub account. To build native archives locally without publishing:
bash scripts/build-release.sh 0.1.0.
License
MIT — see LICENSE.
來源:README.md,提交 0cb59e5
工具
0版本歷史
1- v0.1.0最新Oct 19, 2026
評分
已滿足適用檢查項的 50%
該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。
- 近 30 天內可連通25 分
請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。
- 已宣告認證方式10 分
請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。
- 已列出工具15 分
請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。
- 描述必需15 分
- 圖示10 分
- 文件15 分
- 授權條款10 分