Your cloud bill can now answer questions in plain English

If you work in FinOps, you have almost certainly run into both of these phrases by now: FinOps for AI, and AI for FinOps. The first one is about what your Bedrock and OpenAI lines are doing to your bill, and it gets most of the attention. The second one is the one I find genuinely interesting, and it gets talked about far more loosely.

So let me be concrete. The [CloudYali MCP server](https://www.cloudyali.io/features/mcp-server) is a local, read-only Model Context Protocol server that connects your CloudYali account to Claude, Cursor, VS Code or any other MCP client. Thirty-five actions cover cost and usage, budgets, savings recommendations, cost anomalies and asset inventory. You ask a question in plain English, you get the answer from your own live data, and it cannot change a thing.

That is what we think "AI for FinOps" means in practice. Here is why we built it that way.

Every FinOps tool works about the same way

Every FinOps tool today, ours included, works roughly the same way. You build reports. You set up filters. You slice and dice. It works, but only after you have learned the product properly. Which grouping to use, which filter is applied where, which view answers which question. That is a real time investment, and it lands on people who mostly wanted an answer, not a new skill. This is not unique to us either. The native cloud tools have a harder version of the same problem, which is why cloud cost management tools fall short for the people actually asking the questions.

And even once you have paid that cost, the experience stays siloed. What bothers me most is that the investigation flow is not natural. A real question almost never lives in one screen. Spend jumped, so you open the cost report. Which account? Different view. Is there already a recommendation open against that resource? Another page. Was there an anomaly that week? Somewhere else again. You are the integration layer, carrying context between tabs.

Which is strange, because the data is already sitting together in the backend. It is only the asking that got split up.

That is where an AI assistant turns out to be a very good fit. Not as a chatbot bolted onto a dashboard, but as the thing that stitches the questions back together, because it can reach all of it at once.

What CloudYali already had

This part made the decision easy. CloudYali already holds most of what those questions need:

• detailed [resource inventory](https://www.cloudyali.io/features/asset-inventory), and [cost and usage](https://www.cloudyali.io/features/cost-visibility) data across AWS, Azure and Google Cloud
• identified [savings](https://www.cloudyali.io/features/cost-savings), from wastage detection to idle resources to long-term commitment coverage
• [budgets](https://www.cloudyali.io/features/budget-management) and how they are tracking
• anomalies, and what caused them

None of that is new. What was missing was a way to ask across it in one breath.

So we opened it up over MCP. You ask about your bill the way you would ask a colleague who has read the whole thing.

What it actually feels like

You type this into Claude:

Which five services cost us the most this month, and how does that compare to last month?

And you get an answer. Not a link to a dashboard. Not a suggestion of which report to open. The answer itself, pulled live from your CloudYali account, with your accounts, your filters, your numbers.

Then you ask the follow-up, which is the part that matters:

Okay, the RDS jump. Which accounts, and do we have any open recommendations against them?

That is two different data domains stitched together in one breath: cost, and savings recommendations. By hand it is two pages, two exports and a spreadsheet. Here it is a sentence, and the assistant keeps its place while you keep thinking.

A few more it handles in one turn:

• "How are we tracking against our budgets?"
• "Any cost anomalies in the last seven days, and what caused them?"
• "Find every resource tagged environment=prod that's still running, and tell me what the biggest one cost last month."
• "How much would we save if we actioned every open recommendation?"

Thirty-five read-only actions sit behind it today, across five areas: cost reports and spend aggregation, budgets and their alert history, savings recommendations and their history, anomalies and their root causes, and resource inventory. Inventory alone takes twelve of those, because "which resources, where, tagged what, costing how much" turns out to be half of all real FinOps questions.

Ask for the report, not the number

One trait that has proved more useful than we expected is using the assistant to build custom reports on the spot. Not just getting numbers back, but actual artefacts.

Once the assistant is holding the real rows, the services, the budgets, the anomalies, the open recommendations, it can lay them out. And laying them out is the work that usually eats a Friday afternoon.

So instead of a number, ask for the artefact:

Pull August spend, budgets, anomalies and open savings, and build me a review I can send to the leadership team.

What comes back is a month-end review: the spend breakdown, six months of trend by cloud, budget states, the open anomalies, and the savings ranked by return. One sentence in, a page out.

A few examples:

• The standup one-pager. *"Show budget burn as of this morning, worst first, and flag anything over 90%."* Thirty seconds before the call instead of three tabs during it.
• The anomaly post-mortem. *"Chart daily spend for this account around the 29th, mark the anomaly, and write two paragraphs on what changed."* The chart and the narrative together, which is what the ticket actually needs.
• The savings pipeline, ranked by effort. *"Group open recommendations by how hard they are, not how much they save"* gets you the list you can act on before lunch.
• The comparison nobody has time to build. *"Same query, this quarter against last, and only show me what moved more than 15%."*

Read-only, and I mean it

The CloudYali MCP server is read-only and cannot change anything. Not your budgets, not your recommendations, not your tags, not your account settings. Creating and editing budgets still happens in the portal, by a human, on purpose.

We debated this. It would be genuinely useful to say "snooze that recommendation" and have it happen. But an AI assistant with write access to your cost controls is a category of blast radius I am not willing to hand anyone in version one, including myself. If we ever let it change something, it will be one narrow, named, explicitly-opted-into action at a time, and you will hear about each one.

Sign-in is your normal CloudYali login, the same browser flow, the same MFA, the same SSO. When you authorize, your terminal shows a short verification code and the browser shows one too. If they do not match, you do not approve. The credential is stored on your own machine, in your own home directory, locked to your user. It never travels to us and it never lands in a log.

And it sees exactly what your account sees. It does not widen your permissions by one row. If you cannot see a linked account in the console, the assistant cannot see it either.

Installing the CloudYali MCP server

It is a local server. It runs on your laptop, talks to CloudYali over HTTPS, and hands results to whichever assistant you have pointed at it. Node 20 or newer.

git clone https://github.com/cloudyali/cloudyali-mcp-server.git
cd cloudyali-mcp-server
npm install
npm run build

Then register it. In Claude Code that is one line:

claude mcp add cy -- node /path/to/cloudyali-mcp-server/dist/index.js

Claude Desktop, Cursor, Windsurf, Cline and VS Code use a JSON config file. Codex CLI uses TOML. The setup guide has the exact block for each. Ask it anything after that and it will walk you through signing in on first use.

The source is public and MIT-licensed at github.com/cloudyali/cloudyali-mcp-server. Read it before you run it. I would.

This is phase one

I want to be straight about where this sits. Read-only access over MCP is deliberately the first step, not the destination. It was the right thing to ship first because it is the half we can offer without asking you to trust an assistant with anything it could break.

But even this first pass has surprised us. Opening the data to an assistant has exposed more of what the platform can actually do than any amount of UI work did. Questions we never built a screen for get answered anyway, because the data was always there.

What comes next, roughly in order:

1. npm, so installation is one command instead of four.
2. A hosted server, so browser-based assistants can connect without anything running on your laptop.
3. More of the platform. Tag governance and cost views are the two most-asked-for gaps.
4. FinOps agents. Assistants that do not just answer, but watch, notice and propose. That is where this is heading, and it is a longer conversation than one post.

Try it, and tell me where it falls short. A wrong number, a confusing answer, a question it should have handled and did not. Open an issue on the repo, or mail me at support@cloudyali.io.

See what it looks like, or go ask your cloud bill something.