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.
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".
The bar to hold any FinOps MCP server to (vendor-provided or your own):
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.
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.
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.
Prevention here means preventing the failure modes of assistant-to-infrastructure access, before they're incidents:
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.
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.
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.
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.