How we built our FinOps MCP server: lessons learned

Tanguy Compagnon de La Servette — Thu, 16 Jul 2026 14:40:34 +0000

TL;DR — Our first MCP was basically our API, exposed as-is. Claude wouldn't use it. We had a dedicated tool to compare two periods and it never called it once: it just called query_cost twice and did the subtraction itself. The tools made sense if you knew our database. The model didn't. We ended up rebuilding most of it, and the app is better for it.

Costory pulls in billing data from all your cost centers (AWS, GCP, Azure, Cursor, Anthropic, Aiven, Kubernetes Cost), normalizes it into one common format (FOCUS, from the FinOps Foundation), then ties the spend to the things that explain it: business metrics like DAU and revenue, events like tech releases or known incidents, and technical metrics from tools like Datadog and CloudWatch.

Developing a FinOps MCP server (Model Context Protocol) was an obvious fit. FinOps work is repetitive, our users are technical, and our whole point is that engineers should spend less time on FinOps, not more.

But building the MCP turned out to be less about shipping an API and more about rethinking our product to make it more logical. LLMs need simple contracts, where every parameter means something.

The FinOps MCP we shipped first: a wrapper around our API

Our first MCP was really just our app, exposed. Six tools, each one a mirror of an internal endpoint:

query_cost: return the cost time series
query_cost_diff: return a cost change between two periods
search_filters: search across dimensions
get_metric: retrieve a business or technical metric
query_metric: return the time series of a metric
create_alert: create an alert (with painfully complex parameters)

It worked, technically. But once we started using it, almost everything about it fought the model instead of helping it.

The first one that stuck with us was query_cost_diff. It mirrored our internal split between time-series and period-comparison endpoints, so we assumed the model would reach for it whenever it needed a comparison. It never did: ask Claude to compare this month to last month and it called query_cost twice and did the subtraction itself. To us the split made sense. To the model it was noise — and to the customer, a source of errors whenever Claude's own arithmetic slipped.

The filter format was worse. Internally every where clause is a deeply nested react-querybuilder JSON object, and the model got the structure slightly wrong constantly, so perfectly reasonable queries failed on syntax before they ever ran.

Eventually the common thread became obvious: the tools matched the shape of our database, not the way a model reasons about a problem. So we stopped forcing our API onto the model and started over. That meant changing four things: our query surface, our data model, our error semantics, and how we inject context. A wrapper optimizes for API parity; a native tool optimizes for what the model can reason about in a single shot.

Fix #1: One query tool instead of five

Our first mistake was thinking the MCP's job was to answer specific questions. So we built a tool per question: one endpoint for cost, one for a period diff, one for metrics, one for budgets. Every time a new kind of question came up: budget end of month vs cost, cost per DAU, savings over time, we'd go build another endpoint for exactly that shape. It doesn't scale for us (small dev team, many endpoints), and it caps what the model can ever ask: the model can only pose the questions we already anticipated and hard-coded.

So we stopped shipping answers and shipped tools instead. There's now a single query tool. You hand it a list of named queries, each one a type (cost, metric, usage, externalMetric, budget, formula). We don't build a "savings" endpoint anymore. The model asks for public cost as a, amortized cost as b, and writes a - b. Cost per DAU is cost / daily_active_use. A Kubernetes waste ratio is idle-namespace cost over cluster cost, a / b. None of those are features we built just formulas the model composed out of the same handful of primitives.

{
  "queries": [
    { "type": "cost", "name": "a", "metricId": "list_cost", "currency": "USD" },
    { "type": "cost", "name": "b", "metricId": "effective_cost", "currency": "USD" },
    { "type": "formula", "formula": "a-b" }
  ],
  "from": "2026-03-01",
  "to": "2026-03-31",
  "aggBy": "MONTH"
}

That tool became Advanced Explorer. It started life as an MCP tool and is now a feature in the app itself: the interface we designed for the model turned out to be the better design for people too.

Fix #2: Large Language Model, not Large JSON Model

Filters were the other place the wrapper fell apart. Internally we build a where clause with react-querybuilder, which spits out a nested tree of rule objects. To scope a query to AWS spend that is either EC2 or production, that looks like this:

{
  "combinator": "and",
  "not": false,
  "rules": [
    { "field": "cos_provider", "operator": "in", "value": ["AWS"] },
    {
      "combinator": "or",
      "not": false,
      "rules": [
        { "field": "cos_service_name", "operator": "in", "value": ["AmazonEC2"] },
        { "field": "cos_environment", "operator": "in", "value": ["prod"] }
      ]
    }
  ]
}

You'd think this is the format a machine would love. It's explicit, it's typed, nothing is left to interpretation. In practice it's the opposite. To write this, the model has to be extra careful about the structure while also thinking about what it's filtering on: which rules array it's in, whether this level is and or or, whether the braces line up.

The fix was simple: give it code. We dropped the JSON tree and now pass filters as a filterCel string (CEL, the Common Expression Language). Same filter, one line — and react-querybuilder supports it natively.

cos_provider in ["AWS"] && (cos_service_name in ["AmazonEC2"] || cos_environment in ["prod"])

Across repeated runs of the same query workflows in both formats, this cut the error rate by roughly 25%, and what's left isn't the model mangling structure anymore — it's mostly guessing a column name that doesn't exist, which is a much easier thing to fix (we get to that in the errors section).

Once we saw it work we started applying it everywhere we'd been handing the model a config blob. Alert conditions were structured JSON too; now they're a > 1000 or rollingSum(a, 7, DAY) > 50000.

Fix #3: Give the model context on the first call

An MCP session starts cold. The model doesn't know who's connected or what they did yesterday, so left alone it asks: which project, which team, which environment — every session from scratch. There is nothing more frustrating than an AI asking "Which GCP project?" every single day, and FinOps is the worst place for it, since the work repeats: same people, same dashboards.

So we built get_context and made it the first call of every session — we pin that in the MCP server instructions. It returns everything the user needs: dimensions often queried, the group-bys people reach for, recently touched dashboards, what they did last session (summarized), and their team ownership.

This reduced hallucinations from misunderstood dimensions, put the model back into its last-action context, and stopped it asking the same questions every day.

Fix #4: Rewrite your errors

When a query failed, we returned exactly what our API had always returned. A frontend knows what to do with that thanks to our well-defined contract — but a model can't tell whether the call was one typo away from working or fundamentally malformed, so it either gives up or retries the same mistake in a loop.

So we rewrote errors to be understandable "by a child," with options on how to fix them: what broke, whether it's worth retrying, and how to fix it. The same failure now reads:

Error: 'AmazonEC2' is not a recognized service name in this dataset. Available services are: 'Amazon EC2', 'Amazon S3'. Did you mean 'Amazon EC2'?

The model reads that and corrects itself on the next call. It was cheap to build, too: our runtime already runs on BigQuery, so the valid values and the "did you mean" suggestion were just a passthrough from BQ errors.

State was the other half of the same problem. Models are bad at tracking state across a session. update_dashboard used to want the entire widget list on each call, and the model would silently drop widgets it had lost track of. We looked at how other dashboarding solutions handle this: we saw Grafana MCP had similar issues and followed the same pattern: a diff of operations:

{
  "operations": [
    { "type": "add", "widget": "..." },
    { "type": "remove", "id": 786 },
    { "type": "replace", "id": 345, "widget": "..." }
  ]
}

It's still not perfect, but it stopped removing arbitrary widgets (or moving them 😅).

How we found all of this: we asked the model to debug our MCP

The primary user of an LLM-facing product is the LLM. If you want to know where your tool interface fails, just ask it.

Every time we add a workflow, we run it at least ten times on our demo datasets. After each execution, we ask the model to generate developer feedback detailing every misunderstanding, bad tool call, or bug it encountered. For example, while building the Virtual Dimensions MCP, the model pointed out a direct contradiction in our instructions: one tool optimized for rule size, while another strictly enforced rule execution order. The conflicting constraints were paralyzing the agent.

They are language models: ask them to explain their confusion. We eventually baked this feedback instruction directly into our MCP system prompt. It paid off massively when a customer forwarded us an unvarnished, Claude-generated feedback report after two months of usage — exposing edge cases we never would have caught manually.

Conclusion

We tried building an MCP by mimicking our existing API. You can't: internal APIs carry implementation details, endpoints that only make sense to developers, parameter names that aren't consistent between endpoints. An LLM has none of that context and no patience either — which makes it a good reviewer of your product.

Rebuilding for it was one of the best things we did: it forced us to rethink every user flow from scratch, and a lot of what came out made the app better too (Alerts, Advanced Explorer).

The Costory FinOps MCP server is available: it works in Claude, ChatGPT, Cursor, or any MCP-compatible client, and setup takes a couple of minutes. Read the MCP docs, browse the plugin on GitHub, or get started at costory.io — 15-day free trial, $250/month under 10M annual spend.

DEV Community: Tanguy Compagnon de La Servette