steam-mcp

一个用于判断哪些 Steam 游戏适合特定玩家的 MCP 服务器。它会将商店与玩家实际投入时间的游戏进行对比排序，并结合他们当前表达的游玩偏好。

共十个工具。recommend_games 是入口；其余工具的存在是为了让排序结果可以被质询，而不是盲目采信。

运行

npm install && npm run build
claude mcp add -s user steam-mcp -e STEAM_ID=<your SteamID64> -- node /path/to/steam-mcp/dist/index.js

环境变量：

• STEAM_ID（可选）：默认玩家，格式为 SteamID64。工具也接受每次调用时传入的 vanity 名称或资料页 URL。

• STEAM_API_KEY（可选）：来自 https://steamcommunity.com/dev/apikey。只有游戏库、最近游玩和 vanity 解析路径需要它。其他所有功能，包括公开资料上的愿望单，都不需要密钥，因此服务器在没有任何凭据的情况下也能使用。只是无法个性化。

磁盘缓存位于 $XDG_CACHE_HOME/steam-mcp（默认 ~/.cache）。商店的 appdetails 端点被限制为每个 IP 每五分钟约 200 次；客户端将该端点节奏控制在 1.5 秒，其他端点则快得多，并积极缓存（详情六小时，标签和 Deck 数据一周），因此同一会话中的第二次推荐基本免费。每个丰富列表的工具都在截止时间内工作，并报告跳过了多少游戏，因此长请求返回部分答案，而不是在代理处超时。

Related MCP server: Steam Review and Forum MCP

排序原理

src/taste.ts 包含整个模型。

画像。 每款游玩游戏的时长按其社区标签的投票份额比例归因到标签上，因此军事模拟游戏的时长主要归入 Military 和 Tactical，只有一小部分归入 Multiplayer。在此基础上叠加三项修正：

• 标签按稀有度加权，稀有度源自 Steam 自身标签字典的流行度顺序（无需额外请求）。没有这一点，每个画像都会以 Action、Open World、Simulation 开头，无论玩家是谁。

• 同一工作室的游戏在压缩前先合并。三个 Arma 条目是对同一种口味的三种测量，而不是三倍的证据。

• 游戏时长取平方根。一个异常值仍然领先，但不会主导整个画像。

当有密钥时，两周内的游玩记录会在终身时长之上再计一次：一次作为历史，一次作为玩家当前感兴趣的内容。

评分。 两个信号在同一 0..1 尺度上，等权混合：fit，候选游戏标签向量与画像之间的余弦值，相对于任何游戏能达到的最佳值；以及 want，候选游戏标签质量中玩家要求的部分占比。然后，口碑会对 Steam 的"Mostly Positive"线（70%）以下进行惩罚，并且永远不会奖励高于该线的部分，因为候选游戏已经按评测排序，再次奖励会重复计算流行度。每个报告的 matchedOn 条目都以分数点表示，并说明是游戏库还是请求赢得了它。

排序。 最终列表为多样性而进行贪心重排：候选游戏如果与已选游戏相似，最多损失 40% 的分数。分数按原样报告；只有顺序改变，工具描述中已说明这一点。

测试

npm test

两个测试套件都刻意针对实时 API 运行。test/smoke.mjs 通过真实的 MCP stdio 驱动构建后的服务器，这是唯一能发现静默丢弃的 schema 或更改的商店端点的地方。test/taste.ts 在 test/fixtures/library.json（一个真实的 45 款游戏库）上运行模型，并断言排序行为而非精确数字，因为标签投票会漂移。设置 STEAM_API_KEY 还可以测试需要密钥的工具。

使用密钥部署

长期运行的 stdio 服务器无法从请求作用域的密钥代理获取密钥，因此需要密钥的部署应放在进程启动时可以注入环境变量的地方：supervisord 的 environment= 行、Nomad 变量、systemd 的 EnvironmentFile。服务器在启动时读取一次 STEAM_API_KEY，并且永远不会将其写入任何地方。