FinOps MCP Server：让 AI 助手查询真实云账单

一个用于 FinOps 的 MCP（Model Context Protocol）服务器，让你的 AI 助手（Claude、Cursor 等 MCP 客户端）能够调用工具查询真实的云成本数据——从此"这个月什么在烧钱"这个问题的答案来自账单，而不是来自模型的臆想。这套设计契约之所以安全，靠三条条款：助手获得对成本、资源和推荐建议的只读工具；写操作在协议层被拒绝，而不是靠提示词指令或 token 范围来约束；每次调用都有审计日志。一个能读遍一切却改不了任何东西的助手是超能力；一个能改任何东西的助手是一种新型故障。

两条曲线交汇了。工程师如今活在 AI 助手里，而云账单恰好是那种枯燥、结构化的问题——当有真实数据支撑时，AI 助手很擅长回答，没有支撑时就很危险：一个没有真实数据支撑的模型被问到 AWS 账单，会生成自信、看似合理、实则错误的数字。MCP 标准化了这个问题的解法（服务器暴露带类型的工具；助手调用它们；答案携带真实数据）。但同样的标准也让给助手开放写权限变得极其容易，而一个对生产基础设施有变更权限的随机系统，是一个还没有人想清楚的爆炸半径。因此有趣的设计问题不是"我的助手能看到账单吗"（能，很容易），而是"它在结构上被禁止做什么"。

方案一：将助手连接到成本数据，从设计上就是只读的

对任何 FinOps MCP 服务器（厂商提供或自建）的底线要求：

只读工具集：按服务、账户、团队和周期维度的成本；资源清单；闲置和孤儿资源发现；带证据的推荐列表。足以回答所有"什么、在哪、为什么"的问题。

写操作在协议层被拒绝：无论助手持有何种 token 或提示词如何声明，突变尝试都会在服务器端失败。"模型承诺会小心"不是一种执行机制；一个根本没有 mutate 句柄的服务器才是。

每次调用都审计：每次工具调用都记录调用者和参数，所以"助手看了什么"是一个可查的记录，而不是谜团。

作用域数据，与任何客户端一样：服务器只能看到其凭证能看到的东西，所以你现有的 RBAC 仍然有意义。

有了这些， workflow 立即就有用了："这个月哪个团队的支出增长最快，为什么"、"列出每月超过 100 美元的闲置数据库及其证据"、"起草平台 review 的成本部分"——全部从实时数据回答，在工程师已经所在的那个工具里完成。

方案二：在你自己的计费仓库上构建一个轻量服务器

如果你已经把计费导出数据落库到仓库里，一个有用的内部 MCP 服务器就是一个周末的活儿： handful of read-only tools wrapping parameterized queries.

tools:
  get_cost_summary(period, group_by)      -> spend by service/account/team
  get_cost_trend(scope, days)             -> daily series for a scope
  find_idle_resources(type, min_monthly)  -> findings with evidence
  get_untagged_spend(period)              -> unattributed cost by account

让仓库凭证保持只读（一个数据库角色只有对计费 schema 的 SELECT 权限，其他什么都没有），这样安全属性是从数据库继承的，而不是代码承诺的。抵制加上"就一个"写工具的冲动；一旦存在一个，每个文档里每个提示词注入场景都可能成为它的调用者。

方案三：写操作问题，不通过写操作来回答

团队最终会想要下一步："好，它找到了闲置数据库，让它把那个东西停掉。"安全的形态是提案，而不是行动：助手提交一个待审批记录（工单、审批队列项），由人类通过正常、有审计的路径来审核和执行。助手的输出是一份请求；人类握着触发器。这样保留了全部价值（发现结果、上下文、准备好的操作），同时把变更权限留在为它设计的系统里——有审批、前置条件、回滚，这些 Chat 都不具备。

预防意味着在助手到基础设施的访问变成故障之前，先防止它们的故障模式：

把助手会话当作不可信输入。助手会读取网页、工单和文档；其中任何一个都可能携带注入的指令。只读工具把注入变成隐私问题，而不是故障中断问题。

分离凭证：MCP 服务器自己的最小权限身份，可一步撤销，绝不用人的个人 token。

审计审查：每周浏览工具调用日志，像其他访问日志一样；量和形态异常很快就会显现。

版本化管理契约：当服务器添加工具时，像 API 变更一样审查它们，因为它本质上就是 API 变更。

把"它永远做不到的事"列表写下来并发布给团队；未声明的保证安抚不了任何人。

MCP 是什么，一段话说清？

Model Context Protocol 是一个开放标准，让 AI 助手调用外部服务器暴露的工具：服务器声明带类型的工具，助手调用它们，结果以结构化数据形式返回。它就是把"向模型问你的系统"从幻觉变成数据库查询的管道，支持 Claude、Cursor，以及越来越多的 IDE 和 agent。

给 AI 助手开放我的云账单访问权限安全吗？

通过一个经审计的、只读的 MCP 服务器读取成本数据，是风险较低、价值较高的助手集成之一：账单数据敏感但不含密钥，坏查询的故障模式是一张错误的图表，而不是服务中断。风险只来自写访问，这就是为什么读/写边界属于服务器，而不是提示词。

助手能通过 MCP 改变我的基础设施吗？

只有当有人给了它这么做的工具时才会。一个设计良好的 FinOps 服务器在协议层拒绝写操作，无论 token 范围如何；成熟的行动模式是提案加人工审批：助手做准备，人通过正常审计路径执行。

哪些助手能用 FinOps MCP 服务器？

任何 MCP 客户端：Claude Desktop 和 Claude Code、Cursor，以及越来越多支持该协议的 IDE 和 agent。一个服务器，所有客户端，这正是为什么服务器自己的保证（只读表面、审计）比任何单一客户端的行为更重要。

默认只读：云成本工具需要什么样的访问权限

五分钟内从只读连接到你的第一份云浪费报告

Azure Cost Management Reader vs Billing Reader：精确的只读权限

如需进一步行动，你可以考虑屏蔽此人或举报滥用