Terraform模块搜索服务

TFModSearch MCP服务器

A. 模型上下文协议（MCP） 该服务器使用混合搜索（关键字匹配、BM25和语义嵌入）为Terraform AWS模块文档提供智能搜索功能。

随时可用：包括一个预构建的搜索索引，其中嵌入了63个精心策划的Terraform AWS模块。立即安装并运行MCP服务器，无需构建索引！

🤔 为什么选择TFModSearch？

当人工智能助手编写Terraform时，它经常猜测模块名称，发明不存在的变量，或者寻找过时的语法。TFModSearch为您的助手提供 策划、版本化、离线知识库 官方 terraform-aws-modules --加上一组维护的供应商 云团队 填补官方集合未涵盖的空白的模块，因此它可以：

• 从意图中找到正确的模块 --“我需要一个Redis缓存”解析为 elasticache，而不是一个幻觉般的模块名称。
• 实际输入/输出中的地面生成代码 --助手根据需要提取完整的当前模块文档（子模块、变量、输出、示例），而不是即兴创作。
• 保持快速、私密和确定性 — 搜索 在CPU上针对预构建的索引本地运行。没有外部API调用，没有速率限制，没有网络round-tips。
• 需要时，抓取任何模块的实时文档 --对于精确定位变量/默认查找、策划的AWS目录之外的模块或特定的旧版本， grep_module_docs 获取注册表的当前文档（缓存的，版本可扩展的），并仅返回与上下文匹配的行。

将其视为每个地形aws模块的始终可用、可搜索的参考卡——保持准确并随时准备运行。

🚀 特性

• 混合搜索引擎：结合关键字匹配（IDF加权）、BM25文本相关性、精确的模块名称匹配和语义相似性，以获得准确的结果
• 实时注册成功: grep_module_docs 正则表达式搜索以下内容的完整、最新文档 任何 Terraform注册表模块（版本可尖峰化，缓存），仅返回具有上下文的匹配行——精确查找，不转储10万个令牌文档
• MCP集成：与Claude Desktop和其他MCP客户端无缝集成
• 快速高效：使用仅CPU推理的预构建搜索索引 intfloat/e5-small-v2 模型
• 随时可用：包括预置索引(model/tfmod_e5_small_index.pkl)嵌入来自 intfloat/e5-small-v2 模型和策划的Terraform AWS模块文档
• 综合目录：访问从官方来源编译的具有丰富元数据的terraform aws模块文档
• 安全第一：用于安全文件操作的内置路径验证和访问控制
• 可配置权重：通过YAML配置或CLI参数微调搜索评分

📋 目录

• 为什么选择TFModSearch？
• 安装
  • 插件安装（克劳德代码/Codex）
  • 快速安装（任何MCP客户端）
  • Docker（选择加入）
  • 共享HTTP实例（选择加入）
• 快速开始
  • Claude代码CLI集成
  • Claude桌面集成
  • Codex CLI集成
  • GitHub复制集成
• 用法
  • 构建指数
  • CLI搜索
• MCP工具
• 配置
• 发展
• 测试
• 安全
• 建筑学
  • 索引模块
• 贡献
• 许可证

📦 安装

插件安装（克劳德代码/Codex——推荐）

插件自动配置MCP服务器 和 添加了工作流技能，使代理在编写Terraform之前搜索当前模块文档。

克劳德代码：

/plugin marketplace add SantyagoSeaman/tfmodsearch
/plugin install tfmod-search@tfmodsearch

Codex CLI：

/plugin marketplace add SantyagoSeaman/tfmodsearch
/plugin install tfmod-search@tfmodsearch

两个捆绑包：

• 这 tfmod搜索MCP服务器 （运行通过 uvx tfmodsearch 默认情况下-- 紫外线 必修的；Claude Code插件可以选择通过Docker运行它，请参阅 码头工人 在......下面
• 八项技能:
  • aws-terraform-modules --为AWS编写Terraform时自动调用：先搜索，从当前文档写入，pin版本
  • /tf-module <query> --使用现成的粘贴代码段进行即时模块查找
  • /tf-grep <module> <pattern> --grep任何模块的实时注册表文档（版本pinnacle，非AWS）以获取确切的报价
  • /tf-stack <requirement> --构建具有正确输出的多模块堆栈→输入接线
  • tf-migrate --替换手写 aws_* 具有覆盖模块的资源，逐个属性验证
  • tf-module-upgrade --根据当前文档审核固定版本和变量使用情况
  • tf-review --查看差异或PR的模块使用情况
  • tf-troubleshoot --诊断地形故障；提供一个预过滤器脚本，将任何大小的日志减少到仅用于诊断
• 两个子代理 （克劳德代码）： tf-log-analyst 和 tf-diff-reviewer 在孤立的上下文中分析大型日志和差异，这样您的会话只能看到结果

快速安装（任何MCP客户端）

服务器位于PyPI上，无需克隆存储库。

先安装uv （如果尚未安装）：

curl -LsSf https://astral.sh/uv/install.sh | sh

然后添加到您的MCP客户端配置中：

{
  "mcpServers": {
    "terraform-modules": {
      "command": "uvx",
      "args": ["tfmodsearch"]
    }
  }
}

小贴士：运行 uvx tfmodsearch --warmup 安装后，它会预下载嵌入模型（约130MB）并端到端验证服务器，因此第一个真正的查询是即时的。

已打包并准备就绪：预先构建的搜索索引和所有63个模块文档都已发布 里面 包裹，所以 uvx 获取、安装和运行服务器，无需克隆或重建。（The intfloat/e5-small-v2 嵌入模型——约130 MB——在第一次搜索时自动下载以对查询进行编码，然后缓存以供后续查询使用。)

备注：如果出现“找不到命令”错误，请使用完整路径 uvx:

复制

# Find uvx location
which uvx
# Example output: /Users/username/.local/bin/uvx

然后在配置中使用完整路径：

复制

"command": "/Users/username/.local/bin/uvx"

🐳 Docker（选择加入）

uvx tfmodsearch 保持记录的默认值。官方Docker镜像也发布到 GHCR适用于更喜欢或需要容器的环境——气隙/离线设置、CI运行器 没有Python/uv工具链，也没有在Docker上标准化MCP服务器部署的团队。这 在构建时在嵌入模型、搜索索引和NLTK标记器数据中烘焙图像， 所以 search_modules, get_module，以及 modules_list 运行时不进行任何网络调用. (grep_module_docs 是一个旨在访问实时Terraform注册表的工具 需要真正的网络；仅仅一个 --network none 预热，从来没有叫它，完全离线。)

从0.19.0开始，镜像运行ONNX编码后端，而不是torch: model.onnx + tokenizer.json 在构建时进行烘焙（请参阅下面的“嵌入后端”），而不是 火炬/句子变换器堆栈及其HF模型缓存。仔细斟酌的： 1.42 GB→ 559 MB 未压缩的 （发布后已验证拉取大小），相同的搜索结果——以余弦值验证 与所有162个句子变换器相比，≥0.99999988（最大元素差异4.06e-07） 黄金查询，加上CPU上约5倍的查询编码速度。 uvx tfmodsearch /PyPI安装如下 不受影响——他们默认保留火炬。

任何MCP客户端，直接启动图像（从不添加 -t/--tty --它腐蚀了stdio JSON-RPC流）：

{
  "mcpServers": {
    "terraform-modules": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "ghcr.io/santyagoseaman/tfmodsearch:0.24.0"]
    }
  }
}

Claude代码插件，捆绑的启动器默认为 uvx 并在以下情况下切换到Docker TFMODSEARCH_DOCKER=1 已设置（in ~/.claude/settings.jsons env 阻止或导出之前 启动克劳德代码）：

export TFMODSEARCH_DOCKER=1
# optional: pin a different tag
export TFMODSEARCH_IMAGE=ghcr.io/santyagoseaman/tfmodsearch:0.24.0

如果请求了Docker但没有打开 PATH，发射器回落到 uvx 用警告代替 失败。此双模启动器目前适用于 仅限Claude代码插件 --the Codex插件保留 uvx-仅（Codex CLI尚未可靠地解析中的插件相对路径 它的 mcp.json).

备注：Claude Code插件现在通过捆绑的 python3 启动器脚本而不是 召唤 uvx 直接，所以a python3 口译员on PATH 是插件的先决条件 （除了 uv/uvx)--在macOS/Linux上，这通常已经存在；在Windows上，make 当然 python3 （不只是 python/the py 启动器）解析 PATH.

自己验证脱机属性：

docker run --network none -i --rm ghcr.io/santyagoseaman/tfmodsearch:0.24.0 --warmup

🌐 共享HTTP实例（选择加入）

stdio是每个客户端会话的一个服务器进程：每个MCP客户端（以及它生成的每个子代理） 启动自己的进程，每个进程自己加载~600MB的嵌入模型。Fan任务 跨N个子代理输出，您需要为N个模型负载付费——成本与扇出相乘。 流式HTTP传输（从0.16.0开始）颠倒了这一点： 一个长期存在的共享实例，许多 客户端通过URL连接到它。模型和索引加载一次；主会话和每个子代理 共享该单一实例。

这是一个 操作员管理的选择加入模式 --stdio通过 uvx tfmodsearch 仍为默认值 插件和上面的每个安装路径。仅当您希望共享一个守护进程时才使用HTTP 跨机器上的会话/子代理。

快速入门（Docker）:

docker run -d --name tfmodsearch-http --restart unless-stopped \
  -p 127.0.0.1:8765:8765 \
  ghcr.io/santyagoseaman/tfmodsearch:0.24.0 \
  --transport http --host 0.0.0.0 --port 8765

或与捆绑 docker-compose.yml （同一配方，一个命令）：

docker compose up -d

快速入门（无Docker）:

tfmodsearch --transport http

然后将Claude Code指向正在运行的守护进程（URL，而不是命令）：

claude mcp add --transport http --scope user tfmod-search http://127.0.0.1:8765/mcp

保留插件（代理模式，自0.18.0起推荐）：插件用户不必 不再在技能和共享守护进程之间进行选择。设置一个env变量和插件 捆绑的服务器成为守护进程的轻量级stdio代理——技能、子代理和 自动搜索工作流都在继续工作，600 MB模型只在守护进程中加载一次：

// ~/.claude/settings.json
{ "env": { "TFMODSEARCH_URL": "1" } }               // default daemon on 127.0.0.1:8765
// or a custom target:
{ "env": { "TFMODSEARCH_URL": "http://127.0.0.1:9000/mcp" } }

启动器运行状况首先检查守护进程（3秒）：如果它没有响应，包括在 重新启动后，守护进程仍在预热中——会话将回退到正常的本地 服务器发出stderr警告，因此停止的守护进程永远不会中断会话（回退是有代价的 全局部模型负载；在守护进程报告正常后重试）。像这样的赤裸裸的起源 http://127.0.0.1:8765 也工作—— /mcp 路径是自动添加的。代理通过运行 uvx --from "tfmodsearch>=0.18.0"，因此紫外线必须能够解决这种释放（首次使用需要 网络或温紫外缓存）。点 TFMODSEARCH_URL 仅在您信任的守护进程上：代理 逐字转发每个工具调用。 TFMODSEARCH_URL 优先于 TFMODSEARCH_DOCKER回滚：取消设置变量。任何MCP客户端都可以使用相同的模式，而无需 插件： tfmodsearch --proxy-url <url>.

从插件迁移（无插件设置）：如果你根本不想要这个插件，请制作 当然只有一个 tfmod-search 服务器已注册。禁用插件，然后添加HTTP条目：

claude plugin disable tfmod-search
claude mcp add --transport http --scope user tfmod-search http://127.0.0.1:8765/mcp

HTTP守护进程公开了完全相同的四个工具，因此代理工作流可以继续工作。返回： claude mcp remove tfmod-search 并重新启用插件。

Codex 命令行界面：该插件仅保留stdio，但最近的Codex CLI版本可以连接到 可流式传输的HTTP MCP服务器直接在 ~/.codex/config.toml:

[mcp_servers.tfmod-search]
url = "http://127.0.0.1:8765/mcp"

（检查您的Codex版本是否支持HTTP MCP服务器；首先删除插件的stdio条目，相同 一个如上所述的服务器规则。)

准备就绪：轮询健康端点（不需要MCP握手）。服务器加载索引 并对嵌入模型进行预热 之前 它开始监听，因此预计连接在 启动后，端口打开后为200：

curl -s http://127.0.0.1:8765/health
# {"status": "ok", "version": "0.24.0", "modules": 63,
#  "latest_version": null, "update_available": false}

配置 （CLI标志优先于env变量，env变量优先于 默认值如下）：

生命周期所有权：操作员拥有守护进程--启动它，保持它运行(--restart unless-stopped /撰写健康检查），并停止它。MCP客户端从不自动启动或管理 如果守护进程关闭，Claude Code将显示 tfmod-search 服务器故障/断开连接，以及 它的工具会消失，直到守护进程回来。这就是共享一个实例的代价 跨届会议。

管理守护进程:

docker compose down                # stop (or: docker rm -f tfmodsearch-http)
docker logs -f tfmodsearch-http    # server + uvicorn logs (READY line, warnings, tracebacks)
# upgrade when a new release ships: bump the pinned tag in docker-compose.yml, then
docker compose pull && docker compose up -d

compose文件装载一个命名卷(tfmodsearch-cache)完毕 /home/app/.cache，所以 grep_module_docs 注册表文档缓存在容器重新创建和映像升级中幸存下来。跑步 非Docker变体作为守护进程在你身上（终端多路复用器， nohup，或a launchd/systemd单元）——服务器本身只是一个前台进程。

更新通知 （从0.17.0开始）：固定的图像标签意味着守护进程以其他方式运行 永远没有新版本存在的信号。在HTTP模式下，服务器检查PyPI一次 通过三个渠道揭示其发现-- curl /health 收益 latest_version/ update_available 字段中，出现警告 docker logs 过期时每个周期一次，以及 update_notice 字段出现在 search_modules/modules_list/grep_module_docs 回应 （当没有什么可报告时完全缺席），这样你的代理人就可以直接转达。无 自动更新——操作员仍然拥有碰撞标签和运行 docker compose pull && docker compose up -d.Set TFMODSEARCH_UPDATE_CHECK=0 完全禁用检查 （气隙部署）。 隐私：检查是一个匿名获取公共PyPIJSON API-没有关于你或你的 主机已发送。

不要同时运行插件的stdio条目和HTTP条目。 二 tfmod-search 同时注册的MCP服务器会出现重复的工具集并造成混淆 特工们决定打电话给谁。在添加之前删除或禁用插件的stdio条目 HTTP条目（反之亦然）。

安全：HTTP传输具有 没有身份验证，也没有TLS.保持港口 仅限环回(127.0.0.1:8765:8765，不 0.0.0.0:8765:8765)切勿将其直接暴露于 网络前面没有添加身份验证的反向代理。绑定 0.0.0.0 里面 容器 这是意料之中的，很好——容器自己的环回会使已发布的端口无法访问-- 实际的安全边界是主机端口映射(-p 127.0.0.1:8765:8765)，这限制了 可访问主机的环回接口。

先决条件

• Python 3.12或更高版本
• 紫外线 （推荐）或pip

本地安装（用于开发）

# Clone the repository
git clone https://github.com/SantyagoSeaman/tfmodsearch.git
cd tfmodsearch

# Create virtual environment and install dependencies
uv venv --python 3.12
source .venv/bin/activate  # On Windows: .venv\Scripts\activate
uv pip install -e .

使用pip

# Clone the repository
git clone https://github.com/SantyagoSeaman/tfmodsearch.git
cd tfmodsearch

# Create virtual environment and install dependencies
python -m venv .venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate
pip install -e .

准备就绪：存储库包含一个预构建的搜索索引，因此您可以跳过索引构建步骤，在安装后立即运行MCP服务器！

🏃 快速开始

1.构建搜索索引（可选）

备注：此存储库包括一个预先构建的搜索索引，位于 model/tfmod_e5_small_index.pkl 嵌入63个精心策划的Terraform AWS模块。如果要使用包含的模块，可以跳过此步骤，直接继续测试或运行服务器。

要重建索引或使用其他模块创建新索引，请执行以下操作：

python src/tfmod_search_cli.py index \
  --docs_dir ./modules/terraform-aws-modules

备注：第一次运行将下载 intfloat/e5-small-v2 型号（~130MB）。

2.测试搜索（CLI）

使用命令行界面测试搜索功能：

python src/tfmod_search_cli.py search \
  --query "s3 bucket with kms encryption and versioning" \
  --top_k 5

Claude代码CLI集成

更喜欢 插件安装 --它配置服务器，并在两个命令中添加工作流技能。

选项1：使用uvx（不需要克隆）

claude mcp add terraform-modules -- uvx tfmodsearch

或者添加到您的克劳德代码设置中(~/.claude/settings.json):

{
  "mcpServers": {
    "terraform-modules": {
      "command": "uvx",
      "args": ["tfmodsearch"]
    }
  }
}

备注：如果 uvx 未找到，请使用完整路径（run which uvx 找到它）：

复制

"command": "/Users/username/.local/bin/uvx"

选项2：使用本地安装

# Add the MCP server (replace with your actual path)
claude mcp add --transport stdio terraform-modules -- \
  /absolute/path/to/tfmodsearch/.venv/bin/python \
  /absolute/path/to/tfmodsearch/src/tfmod_mcp_server.py

# Verify the server was added
claude mcp list

或者手动添加到您的克劳德代码设置中(~/.claude/settings.json):

{
  "mcpServers": {
    "terraform-modules": {
      "command": "/absolute/path/to/tfmodsearch/.venv/bin/python",
      "args": [
        "/absolute/path/to/tfmodsearch/src/tfmod_mcp_server.py"
      ]
    }
  }
}

Claude桌面集成

添加到您的Claude Desktop配置(~/Library/Application Support/Claude/claude_desktop_config.json 在macOS上）：

选项1：使用uvx（推荐-不需要克隆）

{
  "mcpServers": {
    "terraform-modules": {
      "command": "uvx",
      "args": ["tfmodsearch"]
    }
  }
}

备注：如果 uvx 未找到，请使用完整路径（run which uvx 找到它）：

复制

"command": "/Users/username/.local/bin/uvx"

选项2：使用本地安装

{
  "mcpServers": {
    "terraform-modules": {
      "command": "/absolute/path/to/tfmodsearch/.venv/bin/python",
      "args": [
        "/absolute/path/to/tfmodsearch/src/tfmod_mcp_server.py"
      ]
    }
  }
}

Codex CLI集成

更喜欢 插件安装 --它配置服务器，并在两个命令中添加工作流技能。

对于手动设置，请全局注册服务器：

codex mcp add tfmod-search -- uvx tfmodsearch

或添加到 ~/.codex/config.toml （全球）或 .codex/config.toml （每个项目）：

[mcp_servers.tfmod-search]
command = "uvx"
args = ["tfmodsearch"]
startup_timeout_sec = 30   # default 10s is tight while the embedding model loads

首次运行：执行 uvx tfmodsearch --warmup 预先下载一次嵌入模型（约220 MB），这样服务器启动就可以在超时时间内正常进行。

要促使Codex（或任何代理）主动使用服务器，请在项目的 AGENTS.md （或 CLAUDE.md 克劳德代码）：

Before writing Terraform that uses AWS, call the tfmod-search MCP server:
search_modules to find the module, then get_module for current variable
names and versions. Do not write module blocks from memory.

GitHub副本集成（VS代码）

在VS Code中将MCP服务器添加到GitHub Copilot（需要VS Code 1.99+）：

步骤1：创建 .vscode/mcp.json 在项目根目录中（或通过命令面板打开用户级配置：“MCP:打开用户配置”）：

选项1：使用uvx（推荐-不需要克隆）

{
  "servers": {
    "terraform-modules": {
      "type": "stdio",
      "command": "uvx",
      "args": ["tfmodsearch"]
    }
  }
}

备注：如果 uvx 未找到，请使用完整路径（run which uvx 找到它）。

选项2：使用本地安装

{
  "servers": {
    "terraform-modules": {
      "type": "stdio",
      "command": "/absolute/path/to/tfmodsearch/.venv/bin/python",
      "args": [
        "/absolute/path/to/tfmodsearch/src/tfmod_mcp_server.py"
      ]
    }
  }
}

步骤2：单击出现在顶部的“开始”按钮 mcp.json 用于初始化服务器的文件。

步骤3：打开GitHub Copilot聊天，选择 代理人 从弹出菜单中选择模式，然后单击工具图标以验证 terraform-modules 服务器及其工具可用。

通过命令面板进行替代设置:

1. 打开命令选项板(Cmd+Shift+P 在macOS上/ Ctrl+Shift+P 在Windows/Linux上）
2. 运行“MCP:添加服务器”
3. 选择“stdio”作为服务器类型
4. 进入 terraform-modules 作为服务器名称
5. 输入Python路径作为命令
6. 输入脚本路径作为参数

管理MCP服务器:

• “MCP:列出服务器”--查看已安装的服务器和可用操作
• “MCP:重置缓存工具”--如果工具未出现，则刷新工具发现
• “MCP:显示输出”--调试服务器连接问题

有关更多详细信息，请参阅 VS代码MCP文档 和 GitHub Copilot MCP指南.

📖 用法

1.建立指数

备注：存储库包括一个预构建的索引——如果你想添加更多模块或自定义现有模块，你只需要构建一个新的索引。

根据模块文档构建或重建搜索索引：

python src/tfmod_search_cli.py index \
  --docs_dir ./modules/terraform-aws-modules \
  --index_path ./model/tfmod_e5_small_index.pkl

选项:

• --docs_dir：包含Terraform模块标记文件的目录（必需）
• --index_path：酸洗索引文件的输出路径（可选，默认为 ./model/tfmod_e5_small_index.pkl)
• --model：要使用的句子转换器模型（默认值： intfloat/e5-small-v2)

2.CLI搜索（独立）

在不运行MCP服务器的情况下搜索模块：

# Search by functionality
python src/tfmod_search_cli.py search \
  --query "kubernetes cluster management" \
  --top_k 3

# Search by exact module name
python src/tfmod_search_cli.py search \
  --query "vpc" \
  --top_k 5

# Search with custom weights
python src/tfmod_search_cli.py search \
  --query "object storage" \
  --w_kw 2.5 \
  --w_exact 4.0 \
  --w_bm25 1.5 \
  --w_sem 1.0

# Search with optional query instruction for BGE models
python src/tfmod_search_cli.py search \
  --query "s3" \
  --query-instruction "Represent this sentence for searching relevant passages: "

🛠️ MCP工具

MCP服务器提供了四种用于Terraform模块发现和文档检索的工具：

modules_list()

在目录中列出所有可用的Terraform模块。

参数：无

退货：包含名称、路径、描述、关键字和注册表坐标的完整模块列表(module_id, latest_version).

示例:

{
  "modules": [
    {
      "module_name": "vpc",
      "path": "modules/terraform-aws-modules/vpc.md",
      "description": "Terraform module to create AWS VPC resources...",
      "keywords": ["vpc", "subnet", "networking", "aws"],
      "module_id": "terraform-aws-modules/vpc/aws",
      "latest_version": "6.6.1"
    }
  ],
  "count": 63
}

search_modules(query: str, top_k: int = 3)

使用关键字、确切名称或自然语言查询搜索Terraform模块。

参数:

• query （string）：自由文本搜索查询
• top_k （int，可选）：要返回的结果数，1-10（默认值3）。对于模棱两可的查询，请提高它，例如 "iam".

退货：元数据和相关性得分排名靠前的模块。每一次打击也带来 module_id （注册表坐标，例如。 terraform-aws-modules/vpc/aws)以及 latest_version，这样助手就可以直接将命中链接到 grep_module_docs 无需猜测坐标。

查询示例:

• "vpc" -按确切名称查找VPC模块
• "object storage with encryption" -自然语言搜索
• "kubernetes cluster management" - 查找EKS模块
• "serverless functions" -查找Lambda模块

get_module(module_identifier: str, sections: list[str] | None = None)

获取特定Terraform模块的文档。 默认情况下，返回一个紧凑的定向头 --不是完整的文档——因此第一次定向调用保持较小规模（大型模块完整运行到10k+个令牌）。

参数:

• module_identifier （string）：模块名称（例如。， "vpc")相对路径（例如。， "modules/terraform-aws-modules/vpc.md")，或 子模块地址 （例如。， "iam//modules/iam-role"，或全部 "terraform-aws-modules/iam/aws//modules/iam-role")--返回一个方向头 仅限于该子模块的部分 在一次通话中，而不是整个上级医生。
• sections （字符串列表，可选）：控制返回的内容。
  • 省略 → the 定向头：描述、模块信息、精确值 版本pin提示，人工智能代理的注意事项，文档中包含的任何重要Gotchas，关键功能，用例，以及带有 全断面库存 --一个包含逻辑键和文档中每个标题的显式菜单——这样下一个调用就确切地知道它可以请求什么。页脚还指出，策划的文档是一个子集，并指向 grep_module_docs 用于完整、精确的输入/输出，并将资源创建条件发送到模块源。对于模块 带有子模块，头部还嵌入了紧凑的子模块 库存 --每个子模块的名称、用途和可重复的源字符串——因此，当正确答案是一个子模块时，您可以通过上面的子模块地址固定其源代码或钻取。
  • 逻辑键或标题子字符串 → 这些部分添加在始终包含的核心之上。接受 inputs, outputs, examples, submodules, features, use-cases, best-practices, resources，或不区分大小写的标题子字符串（例如。 "karpenter" 对于单个EKS子模块）。这 inputs/outputs/examples 密钥也会在将其接口捆绑成组合的模块上解析 Main Module:/Root Module: 将其分段或分散到子模块中。
  • ["all"] （或 "full"/"everything") → 完整的文件逐字逐句。

退货：默认情况下是紧凑的方向头，当请求特定部分时是经过过滤的子集，或者当请求特定内容时是完整的标记文档 all/full 密钥已给出。

安全：仅包含以下文件 modules/ 目录是可访问的。绝对路径和路径遍历尝试被拒绝。

grep_module_docs(module_id: str, pattern: str, version: str | None = None, ...)

正则表达式 满，活 的文档 任何 Terraform注册表模块（不仅仅是精心策划的AWS目录），可选择固定到特定版本。该工具从Terraform Registry API获取模块的完整文档，将它们组装成一个文本（README+输入/输出/资源行+每个子模块和示例），缓存它们，并只返回与周围上下文匹配的行- grep 工具工作。单个模块的文档运行到100000多个令牌，因此grep（不是完整转储）是您在不淹没上下文窗口的情况下精确定位变量名、默认值或示例的方法。

参数:

• module_id （string）：注册表坐标 namespace/name/provider （例如。 "terraform-aws-modules/vpc/aws").直接来自a search_modules/modules_list 结果。
• pattern （字符串）：正则表达式（Python re 语法），例如。 "enable_nat_gateway" 或 "nat_gateway|subnet".
• version （string，可选）：固定一个版本（例如。 "6.6.1").省略 latest.
• case_sensitive （bool，默认值 false), context_lines （int，默认值 2, 0–20), scope （列表，可选--限制为 root/inputs/outputs/resources/submodules/examples), max_matches （int，默认值 50), refresh （bool，默认值 false --绕过缓存）。

退货: module_id, resolved_version, source_url, total_matches/returned_matches/truncated, cache 信息， available_sections （组装文档中的所有部分标签），以及 matches --每一个与 section 标签， line_number，匹配 line，以及 before/after 背景。

缓存：固定版本是不可变的，并且永远缓存； latest 已缓存 doc_cache_ttl_hours （默认24小时），之后或当 refresh=true缓存位置： ${TFMODSEARCH_CACHE_DIR:-${XDG_CACHE_HOME:-~/.cache}}/tfmodsearch/registry_docs，可通过 config.yaml.

示例:

{
  "module_id": "terraform-aws-modules/vpc/aws",
  "pattern": "enable_nat_gateway",
  "version": "6.6.1"
}

返回如下匹配项：

root/readme (line 23):   enable_nat_gateway = true
root/inputs (line …):  - enable_nat_gateway | bool | false | Should be true if you want to provision NAT Gateways ...

典型工作流程

编码助手分两步发现并使用模块：

1. 按意图搜索 --助手将自然语言需求转化为模块：

   复制

   search_modules("managed kubernetes cluster with node groups")
   → eks (score 8.9), eks-pod-identity (2.1), autoscaling (1.7)
   

2. 定向，然后钻孔 --它拉动一个紧凑的定向头，然后请求所需的零件：

   复制

   get_module("iam")
   → IAM orientation head: what it is, exact version pin + the submodule inventory
     inline (iam-role, iam-policy, iam-oidc-provider, … each with a pinnable source)
   get_module("iam//modules/iam-role")
   → head scoped to the iam-role submodule (its trust policy, OIDC, inputs) in one call
   

然后，助手使用真实的变量名和当前语法编写Terraform，而不是猜测。 search_modules 默认情况下返回前3名候选人（raise top_k 对于更广泛的查询），因此助手可以在密切相关的模块之间进行消歧（例如。 alb 对 elb, rds 对 rds-aurora)在承诺之前。 get_module 默认情况下返回一个小的方向头，这样第一个调用就不会溢出；作用域的 sections=["inputs", "examples"] 只提取需要的东西，以及 sections=["all"] 当真正需要整个文档时，返回完整的文档。

对于 精确查找 --一个变量的确切名称/默认值，或者特定功能的连接方式，或者模块的连接方式 在策划的AWS目录之外 或在a 特定旧版本，达到 grep_module_docs. search_modules/modules_list 把准备好的东西还给我 module_id，所以链是直接的：

grep_module_docs("terraform-aws-modules/eks/aws", "enable_cluster_creator_admin_permissions", version="20.8.5")
→ the exact input row + its default + the README lines that use it — no full-document dump

工具边界: search_modules 找到正确的AWS模块； get_module 返回其精心策划、紧凑的离线文档； grep_module_docs greps的实时注册表文档 任何 模块，版本可重复，用于手术查找。

⚙️ 配置

搜索权重配置

创建一个 config.yaml 在项目根目录下的文件中自定义搜索评分权重：

# Optional query instruction for BGE models (improves short query retrieval)
# Set to null to disable (default), or use:
# query_instruction: "Represent this sentence for searching relevant passages: "
query_instruction: null

search_weights:
  w_kw: 1.0      # Keyword overlap weight (IDF-weighted)
  w_exact: 3.0   # Exact module name match boost
  w_bm25: 2.0    # BM25 text relevance weight
  w_sem: 3.0     # Semantic similarity weight

上面的值是回购中装运的重量 config.yaml （与软件包捆绑在一起），因此它们是服务器开箱即用的。

配置优先级 （从高到低）：

1. CLI参数(--w_kw, --w_exact, --query-instruction等等）
2. config.yaml 文件
3. 内置默认值

嵌入后端

查询和索引编码通过一个小的后端接缝，通过以下方式选择 TFMODSEARCH_EMBED_BACKEND:

TFMODSEARCH_ONNX_MODEL_DIR 将ONNX后端指向包含以下内容的目录 model.onnx + tokenizer.json （默认为 <project_root>/onnx/e5-small-v2 如果未设置，这是官方Docker镜像烘焙它们的地方）。

uvx tfmodsearch /PyPI安装保持火炬 --核心依赖集保持不变，因此对于正常的本地安装没有任何选择。ONNX位是可选的额外位： pip install "tfmodsearch[onnx]" （添加 onnxruntime>=1.20 和 tokenizers>=0.21)，加上ONNX资产-- python scripts/export_onnx_model.py <output_dir> 出口 intfloat/e5-small-v2 （要求 optimum-onnx/仅在导出时使用torch，脚本位于repo中，而不是wheel中（克隆repo以运行它），并在安装了语句转换器后打印奇偶校验。注意额外的 添加 包，它不能从pip安装中删除torch（Python extrass只添加）：无torch的约559 MB占用空间是官方Docker镜像的属性，该镜像完全没有句子转换器。如果您希望ONNX代码路径位于该映像之外，则额外的功能非常有用。

模块文档格式

Terraform模块文档文件应该是Markdown，前面有YAML：

---
module_name: terraform-aws-vpc
keywords: [vpc, subnet, networking, aws]
---

# Terraform AWS VPC Module

Module description and documentation...

👩‍💻 发展

设置开发环境

# Clone the repository
git clone https://github.com/SantyagoSeaman/tfmodsearch.git
cd tfmodsearch

# Install with development dependencies
uv pip install -e ".[dev]"

# Install pre-commit hooks
pre-commit install

发展依赖性

该项目包括以下开发工具：

• 测试：支持异步的测试框架
• 颈毛：快速Python linter和格式化程序
• 米皮：静态类型检查器
• 预承诺：Git挂钩提高代码质量

代码质量

# Run linter (includes flake8-bandit `S` security rules)
ruff check src/ tests/

# Run formatter
ruff format src/ tests/

# Run type checker
mypy src/

# Run all checks (linter + formatter + type checker)
pre-commit run --all-files

🧪 测试

该项目包括涵盖所有主要功能的全面集成测试。

运行测试

# Run all tests
pytest tests/ -v

# Run specific test suite
pytest tests/integration/test_all_modules_searchable.py -v  # Searchability, all 63 modules (196 tests)
pytest tests/integration/test_model_comparison.py -v -s     # Model comparison (31 tests)
pytest tests/integration/test_mcp_server.py -v              # MCP server tools (40 tests)
pytest tests/integration/test_doc_grep.py -v               # grep engine (6 tests)
pytest tests/integration/test_registry_docs.py -v          # registry client + cache (6 tests)
pytest tests/integration/test_grep_module_docs.py -v       # grep_module_docs tool (3 tests)
pytest tests/integration/test_parse_markdown.py -v          # Markdown parsing (14 tests)
pytest tests/integration/test_cli_index.py -v               # CLI index building (4 tests)
pytest tests/integration/test_security_config.py -v         # Security config contract (5 tests)

# Run the opt-in live tests (real calls to the public Terraform Registry)
RUN_REGISTRY_BENCHMARK=1 pytest tests/integration/test_registry_comparison.py -v -s
RUN_REGISTRY_BENCHMARK=1 pytest tests/integration/test_grep_module_docs_live.py -v

# Run with coverage
pytest tests/ --cov=src --cov-report=term-missing --cov-report=html

测试覆盖率

• 所有模块均可搜索 （196项测试）：63个模块中的每一个都通过关键字、确切名称和自然语言查询（前3名中的目标）以及目录元数据和搜索质量检查进行验证
• 模型比较 （31个测试）：嵌入模型性能与时序分析的比较
• MCP 服务器 （65次测试）： search_modules, get_module，以及 modules_list 工具， top_k 和 sections 参数（方向头默认值、内联子模块库存、子模块地址范围头、， all/full 逃逸舱口、组合/子模块接口密钥解析、版本引脚提示）， module_id/latest_version 字段、安全验证、集成工作流
• 文档架构 （441个测试）：模式完整性保护了所有63个精心策划的文档——通用的核心标题存在且唯一（包括方向负责人自己的关键功能+主要用例），公认的接口方案（拆分/组合） Main Module: /仅子模块）， inputs/outputs/examples 解析每个文档，一个干净的定向头，每个文档的子模块清单都出现在头上——所以 get_module 分段过滤不能静默中断
• 端到端 （59个测试）：针对衍生服务器进程的真实MCP stdio协议会话、轮有效载荷和入口点验证， uvx 打包服务器烟雾测试、Claude Code和Codex的插件清单/技能/代理合同、技能脚本测试（terraform日志预过滤器）、通过 claude 命令行界面
• grep_module.docs （15次测试）：grep引擎(test_doc_grep.py，6），注册表客户端+文档组装+磁盘缓存(test_registry_docs.py，6）和工具接线(test_grep_module_docs.py，3），加上2次选择加入实时烟雾测试(test_grep_module_docs_live.py)门控由 RUN_REGISTRY_BENCHMARK=1
• 模块ID标头 （1个测试）：每个策划的文档都有一个 Module ID 项目符号等于其根注册表 Source
• Markdown解析 （14次测试）： ## Module Information 解析（名称、关键字、， module_id, latest_version)、描述提取、规范化
• CLI索引构建 （4个测试）：索引创建、验证、搜索集成
• 安全配置 （5个测试）：Dependabot配置， SECURITY.md 报告策略，两个工作流的最低权限 permissions，并且发布作业保留了OIDC id-token: write 授予
• 注册表比较 （5个测试）：top-1/top-3检索基准与公共Terraform注册表（参见 注册表搜索比较)；一个网络免费保护程序始终运行，四个实时测试可通过以下方式选择加入 RUN_REGISTRY_BENCHMARK=1

总计：1130个测试（集成+e2e；1103个通过，27个跳过——6个选择加入实时测试，除非 RUN_REGISTRY_BENCHMARK=1，加上没有被模式保护跳过子模块清单的文档）

🔒 安全

TFModSearch是一个仅使用CPU的本地服务器，除一个模块外，其余部分均设计为脱机(tfmod_registry_docs.py，它通过HTTPS获取公共Terraform注册表文档 grep_module_docs).供应链和代码卫生是通过GitHub原生工具强制执行的：

• 漏洞报告：参见 SECURITY.md --请使用GitHub私有漏洞报告，而不是公开问题。
• CodeQL 默认设置对每个pull请求和每周计划运行静态分析。
• 依赖机器人 为易受攻击的依赖项打开每周GitHub Actions版本更新和自动安全更新PR。
• 秘密扫描+推送保护 在存储库上启用。
• 颈毛 S （8号高射炮强盗） 安全lint在CI中运行，注册表获取拒绝任何非-https URL。
• 最低权限CI：工作流与一起运行 permissions: contents: readPyPI发布使用具有PEP 740认证的OIDC可信发布（无长期令牌）。

🏗️ 建筑学

包含的内容

此存储库包括：

• 预构建搜索索引 (model/tfmod_e5_small_index.pkl):

  • 使用预计算嵌入的现成搜索索引 intfloat/e5-small-v2 模型
  • 包含BM25语料库、语义向量和关键字IDF分数
  • 包括63个精心策划的Terraform AWS模块
  • 文件大小：约4.87 MB

• 整理好的模块文档 (modules/terraform-aws-modules/ + modules/cloudposse/):

  • 为63个Terraform AWS模块编译的文档，涵盖计算、存储、网络、数据库、安全等领域
  • 55来源于官方 地形自动气象站模块 项目，外加8家供应商维护 云团队 间隙填充器（aws配置、ses、vpc对等连接、安全中心、警卫、云追踪、备份、sso）；来源保存在每个文档的模块ID/来源中
  • 格式化为Markdown ## Module Information 元数据块
  • 每个模块都包括全面的文档，包括最佳实践、用例和示例

索引模块

搜索索引包括63个跨多个服务类别的Terraform AWS模块。每个模块都有全面的描述、最佳实践、用例和集成示例。

计算和容器：

• app-runner -容器化web应用程序部署
• autoscaling -EC2自动扩展组
• batch -AWS Batch用于批处理计算工作负载
• ec2-instance -EC2虚拟机
• ecs -弹性集装箱服务
• eks -弹性Kubernetes服务
• eks-pod-identity -EKS吊舱身份配置
• lambda -无服务器功能

网络：

• alb -应用程序负载平衡器
• customer-gateway -VPN客户网关
• elb -经典负载平衡器
• transit-gateway -网络集线器的传输网关
• vpc -虚拟私有云
• vpn-gateway -VPN网关和站点到站点VPN

储存：

• ebs-optimized -EBS优化验证
• ecr -弹性容器注册表
• efs -弹性文件系统
• fsx -FSx文件系统（Lustre、ONTAP、OpenZFS、Windows）
• s3-bucket -S3对象存储

数据库：

• dms -数据库迁移服务
• dynamodb-table -DynamoDB NoSQL数据库
• elasticache -ElastiCache（Redis、Memcached）
• memory-db -Redis内存数据库
• opensearch -OpenSearch搜索和分析
• rds -关系数据库服务
• rds-aurora -Aurora无服务器数据库
• rds-proxy -用于连接池的RDS代理
• redshift -Redshift数据仓库

安全和身份：

• acm -AWS证书管理器
• iam -身份和访问管理
• key-pair -EC2密钥对
• kms -密钥管理服务
• secrets-manager -秘密经理
• security-group -VPC安全组
• wafv2 -AWS WAF v2 web应用程序防火墙

监控和记录：

• cloudwatch -CloudWatch日志和指标
• datadog-forwarders -Datadog日志转发
• managed-service-grafana -亚马逊管理Grafana
• managed-service-prometheus -亚马逊管理普罗米修斯

应用程序集成：

• apigateway-v2 -API网关HTTP和WebSocket API
• appsync -GraphQL API服务
• eventbridge -事件驱动架构
• msk-kafka-cluster -Kafka的流媒体管理
• sns -简单通知服务
• sqs -简单队列服务
• step-functions -无服务器工作流编排

内容交付和网络安全：

• cloudfront -CloudFront CDN
• global-accelerator -全球性能加速器
• network-firewall -AWS网络防火墙
• route53 -DNS和域管理

开发人员工具和自动化：

• appconfig -应用程序配置管理
• atlantis -Terraform拉取请求自动化
• notify-slack -Slack通知集成
• ssm-parameter -系统管理器参数存储

大数据与分析：

• emr -用于大数据处理的弹性MapReduce（Hadoop、Spark）

Cloud Posse（供应商维护的间隙填充器， modules/cloudposse/):

• config -AWS配置合规规则和多帐户聚合
• ses -简单电子邮件服务域和SMTP凭据
• vpc-peering -同一帐户VPC对等连接
• security-hub -安全中心调查结果汇总和安全标准
• guardduty -警卫威胁检测
• cloudtrail -CloudTrail API活动登录到加密的S3存储桶
• backup -AWS备份计划、保管库和选择
• sso -IAM身份中心（AWS SSO）权限集和帐户分配

所有模块都包括详细的文档，包括：

• 模块元数据和版本信息
• 全面的功能描述
• 真实世界的用例
• 安全和运营最佳实践
• 集成示例和代码片段
• AWS官方文档链接

组件

1. 搜索库 (src/tfmod_search_lib.py)

   • 混合评分的核心搜索引擎（关键字+BM25+语义）
   • 指标构建与管理
   • 支持YAML前端的Markdown解析

2. CLI工具 (src/tfmod_search_cli.py)

   • 索引构建和测试的命令行界面
   • 两个子命令： index 和 search

3. MCP 服务器 (src/tfmod_mcp_server.py)

   • 基于FastMCP的stdio服务器
   • 公开搜索和检索工具
   • 配置管理和日志记录

数据流

Documentation (.md files)
    ↓
CLI builds index (parse + embed + BM25)
    ↓
Pickled index file (.pkl)
    ↓
MCP server loads index
    ↓
Tools: search_modules, get_module, modules_list
    ↓
Claude Desktop / MCP Clients

搜索评分算法

混合搜索结合了四个具有可配置权重的信号：

1. 关键字重叠 (w_kw)：IDF加权关键字匹配
2. 精确匹配 (w_exact)：Boost用于精确匹配模块名称
3. BM25 (w_bm25)：统计文本相关性（Okapi BM25）
4. 语义相似度 (w_sem)：神经嵌入的余弦相似性

在加权组合之前，所有分数都是最小最大归一化的。

嵌入模型比较

该项目通过以下方式支持任何句子转换器模型 --model下表对5名候选人进行了基准测试 完整目录：所有54个模块，每个模块都有3种查询方式（确切名称、关键字、自然语言）——每个模型162个查询——使用以下的生产搜索权重 config.yaml.

为什么 e5-small-v2：这是唯一匹配的较小型号 bge-base-en-v1.5在这个语料库上的成功率为100% 约小3倍 和 每次查询速度提高约3倍，不需要重新调整权重或查询/段落提示前缀（两者都尝试过；都没有在这个语料库上移动指针）。 gte-small 是最小的选项（约65 MB，比旧默认值小约6倍），如果二进制大小比最后一个召回百分点更重要，则是一个合理的选择——请参阅 tests/integration/test_model_comparison.py 对于已提交的回购，CI会对所有三个进行比较(gte-small, bge-base-en-v1.5, e5-small-v2). bge-small-en-v1.5 和 all-MiniLM-L12-v2 也进行了评估，并在此处记录了完整性，但未被选中：没有明显的优势 gte-small/e5-small-v2 无论是尺寸还是精度。

若要使用其他模型，请使用以下命令重建索引 --model <name> （参见 构建指数)和点 --index_path / config.yaml 在新文件中。

注册表搜索比较（与Terraform Registry/HashiCorp MCP）

混合语义搜索与公共Terraform注册表中的普通关键字查找相比如何？下面使用的注册表端点-- GET /v1/modules/search?q=…&provider=aws -正是API hashicorp/terraform-mcp-servers search_modules 工具包装，因此这可以与竞争对手的模块搜索进行苹果对苹果的比较。

基准测试重复使用相同的 金色套装 正如可搜索性测试所示：所有54个模块，每个模块都有3种查询方式（确切名称、关键字、自然语言）——162个带标签的查询——询问 *“预期的模块是否在前1/3的结果中？”*注册结果有两种评分方式： official （仅当比赛来自 terraform-aws-modules 命名空间——我们记录的同一模块）和 any-author （如果任何命名空间返回一个名称匹配模块，请点击该按钮——这对注册表来说是故意慷慨的）。

要点：

• 这是一个检索质量的故事，而不是报道故事。 全部 54/54 策划模块作为独立的官方模块存在 terraform-aws-modules 注册表中的条目--注册表 能 归还每一个；它只是无法通过描述性查询来显示它们。
• 语义搜索在自然语言中占主导地位。 对于自由文本查询（例如。 managed kubernetes cluster → eks, serverless function execution → lambda)，TFModSearch保留 100%前三名 当官方登记处搜索土地时 5.6% （54次中有51次失误）。关键字搜索仅在查询已包含模块的术语时匹配。
• 注册表的失败模式是“根本不在结果中”，而不是排名错误。 它的官方前1名等于每一行的前3名——当正确的模块出现时，它已经是第一名了（下载计数将其浮起）；问题是，对于描述性查询，它不会出现。
• 仅在确切名称上对等。 如果您已经知道模块名称(vpc, s3-bucket)，关键字搜索很好——语义搜索的全部值在另外两行中，用户在其中描述 任务 而不是a 名字.
• 注意事项（对登记处有利）： 自然语言查询是与这个语料库一起编写的（轻微的本土偏见，尽管它们是通用的任务描述），以及 any-author 将相同命名的模块记入注册表 任何 作者——但与我们的100%相比，它仍然落后于前三名的51.2%。

自己复制（选择加入，向公共注册表进行实时调用）：

RUN_REGISTRY_BENCHMARK=1 pytest tests/integration/test_registry_comparison.py -v -s

比较结果如下 tests/integration/test_registry_comparison.py。它在正常CI中保持密封（除非有以下情况，否则跳过现场测试 RUN_REGISTRY_BENCHMARK=1，如果无法访问注册表，则优雅地跳过）；无网络保护测试将“100%前三名”的数字锁定在我们这边。

agent选择比较（真实agent循环中的工具）

上表衡量了 搜索引擎孤立 --一个问题，一个答案。这衡量了当一个完整的代理发生时会发生什么 用途 it：重新制定、链接调用和轮流推理，以选择一个模块并根据其输入进行定向。 这是两种不同的测试 --代理可以重新制定其通过弱单次搜索的方式，因此一个代理中的空白不一定出现在另一个代理上；两者都不是对方的证据。

设置。 23个基础设施要求纯粹是功能，带有模块名称及其明显的关键字 扣留 （查询描述的是结果，而不是AWS服务名称）——加上干扰因素、两个真正模糊的对和三个诚实性检查，正确答案在哪里 “没有适合的模块，退回到原始资源。” 条件 A. 只能使用TFModSearch；条件 B 只有官方 hashicorp/terraform-mcp-server --通过零交叉工具污染验证的互斥工具隔离。同一任务在三个消费者模型层上运行；每种情况3名工人。根据预先注册的金牌进行机械评分；方向（生成的骨架的变量名称是否真实和最新？）由独立的盲法官进行评分，所有车队都有一个固定的法官模型。

选择精度 --选择正确的模块（n=69=3个工人×23个要求）：

方向保真度 --骨架中真实的当前变量名（盲法判断，n=69）：

要点：

• 随着消费者模式的减弱，优势也在增长：+3→ +12 → +30. 强大的模型路线 周围 弱搜索——它重新制定和自我纠正——因此准确性处于前沿，工具的价值在于成本，而不是正确性。便宜的型号 不能 绕过它的路线：在原始注册表中，Haiku在官方模块上选择下载排名靠前的第三方分支，将存在的模块标记为“未找到”，并批量使用变量名（两次基线运行在方向上得分为6/23和7/23，主要是发明字段）。在精选目录中，同一型号达到64/69选择和53/69定向。
• 成本：相同的答案只需减少约2倍的文档调用 （边境平均26比53），每次运行的美元更便宜，例如Sonnet车队 22.89美元对40.54美元 --这一差距持续了13次。TFModSearch上的廉价模型 接近 边界模型在原始基线上的定向质量只占花费的一小部分。
• 直报： 在前沿推理中，选择关系在天花板和方向在噪声（+3）范围内。 “对正确模块的调用更少” 这是永远正确的说法； “捕捉到弱代理可能会出错的选择” 对于廉价车型来说，这是真实而巨大的，在前沿是看不见的。
• 注意事项： 小N（每层每种情况3个——这是对机制的演示，而不是基于幂的统计估计）；选择和骨架根据当前文档进行静态分级，没有 terraform apply廉价模型的选择失误是查询公式 上游 工具，而不是工具返回错误的结果；自动化工作者不会调用交互式工作流技能，因此人工会话可能比这些数字更好，而不是更差。

🤝 贡献

欢迎投稿！请遵循以下指南：

1. 分叉存储库
2. 创建要素分支(git checkout -b feature/amazing-feature)
3. 进行更改
4. 运行测试和代码质量检查
5. 提交您的更改(git commit -m 'Add amazing feature')
6. 推到分支(git push origin feature/amazing-feature)
7. 打开拉取请求

开发指南

• 遵循PEP 8风格指南（由 ruff)
• 向所有函数添加类型提示（由检查 mypy)
• 为新功能编写测试
• 根据需要更新文档
• 保持提交原子性和良好的描述

📄 许可证

此项目根据MIT许可证获得许可-请参阅 许可证 文件以获取详细信息。

🙏 致谢

• 内置于 FastMCP -FastAPI风格的MCP服务器框架
• 用途 句子变换器 用于语义嵌入
• Terraform模块文档来自 地形自动气象站模块

📞 支持

如有疑问、问题或功能请求：

• 打开一个问题 GitHub Issues
• 检查现有问题，找出常见问题和解决方案