Quick Answer (TL;DR)
An MCP (Model Context Protocol) server for FinOps gives your AI assistant (Claude, Cursor, and other MCP clients) tools to query real cloud cost data, so "what's costing us money this month" gets answered from the bill instead of from the model's imagination. The design contract that makes this safe has three clauses: the assistant gets read-only tools over costs, resources, and recommendations; writes are rejected at the protocol layer, not by prompt instructions or token scope; and every call is audited. An assistant that can read everything and change nothing is a superpower; one that can change anything is a new incident category.
Why this happens
Two curves crossed. Engineers now live inside AI assistants, and cloud bills are exactly the kind of tedious, structured question those assistants are good at when grounded and dangerous at when not: an ungrounded model asked about your AWS bill will produce confident, plausible, wrong numbers. MCP standardized the fix (a server exposes typed tools; the assistant calls them; answers carry real data). But the same standard makes it trivially easy to hand an assistant write access, and a stochastic system with mutation rights over production infrastructure is a blast radius nobody has finished thinking about. The interesting design question is therefore not "can my assistant see the bill" (yes, easily) but "what is it structurally prevented from doing".
Fix #1: Connect the assistant to cost data, read-only by construction
The bar to hold any FinOps MCP server to (vendor-provided or your own):
- Read-only toolset: costs by service, account, team, and period; resource inventories; idle and orphan findings; recommendation lists with their evidence. Enough to answer every "what, where, why" question.
- Writes rejected at the protocol layer: mutation attempts fail in the server regardless of what token the assistant holds or what the prompt claims. "The model promised to be careful" is not an enforcement mechanism; a server that has no mutate handlers is.
- Per-call audit: every tool invocation logged with its caller and arguments, so "what did the assistant look at" is a query, not a mystery.
- Scoped data, same as any client: the server sees what its credential sees, so your existing RBAC keeps meaning something.
With that in place, the workflows are immediately useful: "which team's spend grew fastest this month and why", "list idle databases over $100 a month with their evidence", "draft the cost section of the platform review", all answered from live data, in the tool where the engineer already is.
Fix #2: Build a thin one over your own billing warehouse
If you already land billing exports in a warehouse, a useful internal MCP server is a weekend project: a 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
Keep the warehouse credential read-only (a database role with SELECT on the billing schema and nothing else) so the safety property is inherited from the database, not promised by the code. Resist the temptation to add "just one" write tool; the moment one exists, every prompt-injection scenario in every document the assistant reads becomes a potential caller of it.
Fix #3: The write question, answered without writes
Teams eventually want the next step: "fine, it found the idle database, let it stop the thing." The safe shape for that is proposal, not action: the assistant files a pending approval record (a ticket, an approval-queue item) that a human reviews and executes through the normal, audited path. The assistant's output is a request; the human holds the trigger. That preserves the entire value (the finding, the context, the prepared action) while keeping mutation authority in systems designed for it, with approvals, preconditions, and rollback, none of which a chat session has.
How to prevent this
Prevention here means preventing the failure modes of assistant-to-infrastructure access, before they're incidents:
- Treat assistant sessions as untrusted input. Assistants read web pages, tickets, and docs; any of those can carry injected instructions. Read-only tools make injection a privacy question instead of an outage question.
- Separate credentials: the MCP server's own least-privilege identity, revocable in one step, never a human's personal token.
- Audit review: skim the tool-call log weekly like any other access log; volume and shape anomalies show up fast.
- Version the contract: when the server adds tools, review them like API changes, because that's what they are.
- Write the "what it can never do" list down and publish it to the team; unstated guarantees don't calm anyone.
FAQ
What is MCP, in one paragraph?
Model Context Protocol is an open standard that lets AI assistants call tools exposed by external servers: the server declares typed tools, the assistant invokes them, results flow back as structured data. It's the plumbing that turns "ask the model about your systems" from hallucination into database queries, and it's supported by Claude, Cursor, and a growing set of clients.
Is it safe to give an AI assistant access to my cloud bill?
Read access to cost data through an audited, read-only MCP server is one of the lower-risk, higher-value assistant integrations: billing data is sensitive but not secret-bearing, and the failure mode of a bad query is a wrong chart, not an outage. The risk arrives exclusively with write access, which is why the read/write boundary belongs in the server, not in the prompt.
Can the assistant change my infrastructure through MCP?
Only if someone gives it tools that do so. A well-designed FinOps server rejects writes at the protocol layer regardless of token scope, and the mature pattern for actions is proposal-plus-human-approval: the assistant prepares, a person executes through the normal audited path.
Which assistants can use a FinOps MCP server?
Any MCP client: Claude Desktop and Claude Code, Cursor, and the expanding ecosystem of IDEs and agents that speak the protocol. One server, every client, which is precisely why the server's own guarantees (read-only surface, auditing) matter more than any single client's behavior.
