Dora NodaYour chargeback dashboard just got an API an agent can call. Since v1.118, announced in October 2025, OpenCost — the CNCF Incubating cost-allocation engine — ships a built-in MCP server, on by default in the Helm chart, that exposes cost allocation, asset inventory, and cloud spend as tools an AI agent can invoke in plain language. No scraper, no dashboard screenshots, no human in the loop reading a graph: the agent asks for the number and gets the number.
That is a genuine unlock for a self-hosted fleet, and a genuine new attack surface. This post covers both: the exact tool surface (three original tools plus a newer efficiency tool), a worked example of the question every multi-tenant operator asks first, three agent patterns the tools enable, and the scoping rules that decide whether read-only cost data is actually safe to hand an agent.
The tool surface, concretely
The server lives inside the OpenCost deployment (pkg/mcp/server.go upstream) and speaks the same allocation model as the REST API. Four tools, all read-only:
| Tool | Required params | Key optional params | Example question it answers |
|---|---|---|---|
get_allocation_costs | window (e.g. 7d, 1h, 30m) | aggregate (namespace, pod, node…), step, accumulate, share_idle, include_idle | "Show me the cost breakdown by namespace for the last 7 days" |
get_asset_costs | window | asset type: Node, Disk, LoadBalancer, Network, Cloud, ClusterManagement | "Which load balancers are most expensive?" |
get_cloud_costs | window | aggregate, provider (AWS, GCP, Azure…), service, region | "Compare EC2 spend between regions" |
get_efficiency | window | step, target workload | "Which workloads are paying for CPU they never use?" |
The first three shipped with the v1.118 announcement; get_efficiency arrived later with its own step handling. For a fleet on owned hardware, the first two do almost all the work: allocation tells you what each tenant burned, assets tell you what the iron underneath costs. Cloud costs matter the moment you run hybrid or compare your Hetzner bill against the hyperscaler you left.
One operational detail worth knowing up front: the chart serves the MCP endpoint on port 8081 with an explicit toggle (opencost.mcp.enabled) and a query timeout (MCP_QUERY_TIMEOUT_SECONDS). The announcement shipped it enabled by default, but verify the default in whatever chart version you pin — and set the timeout deliberately, because an agent firing wide-window allocation queries against a big cluster can hold a request open longer than your gateway's idle cutoff.
Worked example: "what does this tenant's namespace cost this month?"
This is the question the dashboard makes you click six times to answer. The agent version is one tool call:
{
"tool": "get_allocation_costs",
"arguments": {
"window": "30d",
"aggregate": "namespace",
"share_idle": true,
"include_idle": false
}
}What comes back is a per-namespace breakdown in dollars over the window, and the two idle flags are where operators get tripped up, so get them right once:
- Allocated cost is
max(request, usage)per container, summed up — what the tenant reserved or burned, whichever is larger. This is the OpenCost spec's core formula, and it means an over-provisioned namespace looks expensive even when idle. - Idle cost is cluster spend no workload claims.
include_idle: falsekeeps the unclaimed pool out of the per-tenant numbers;share_idle: truedistributes a proportional cut of shared overhead (system namespaces, unallocated headroom) into each tenant's figure instead.
For showback to tenants, share_idle: true is usually the honest setting: the tenant's namespace didn't rent the whole node, but somebody has to pay for kube-system and the headroom the autoscaler keeps warm. For waste-hunting, flip to share_idle: false, include_idle: true so the idle pool shows up as its own line item — that number, not any single tenant's, is the size of your rightsizing prize.
That distinction is also why the agent beats the dashboard here. A human reads one aggregation and moves on; an agent can pull both cuts in two calls and report "tenant-acme burned $412 this month, of which $96 is their share of idle" without being asked twice.
Three things an operator agent can now do inline
1. Answer cost questions where the conversation already happens. The canonical case: an operator asks in chat "what did the inference namespace cost last week?" and the agent calls get_allocation_costs with window: 7d, aggregate: namespace instead of anyone opening Grafana. This is FinOps maturity level 1 (visibility) with the dashboard step deleted. It sounds minor until you count how many cost questions die because answering them meant context-switching into another tool.
2. Put a dollar figure inside scale-down and rightsizing proposals. An agent that can already propose "drop this Deployment from 8 replicas to 4" via your deploy tooling can now call get_allocation_costs first and lead with the money: "this namespace's idle share is $96/month; the proposed scale-down reclaims roughly $60 of it." Cost becomes an input to the decision rather than a report about it afterwards. Keep the actual mutation behind the same human approval you already gate deploy/rollback tools with — the cost read informs the proposal, it doesn't authorize the action.
3. Watch for spend anomalies on a schedule. A cron-triggered agent pulling get_cloud_costs weekly, or allocation by namespace daily, can flag "namespace X is 3x its trailing average" before the invoice does. Upstream is heading this way explicitly: an open feature request proposes anomaly detection and GPU cost attribution as native MCP tools, so today's hand-rolled scheduled query becomes tomorrow's built-in call.
The honest caveat on pattern 2: verify efficiency output before acting on it. The get_efficiency tool has an open upstream issue reporting that it treats allocated resource-hours as usage, which pegs efficiency at 100% and recommendations at a flat +20%. That may be fixed by the time you read this — check the issue status — but the principle stands: a read-only tool can still be wrong, and an agent that quotes a wrong number with full confidence is worse than no agent at all. Cross-check the first few efficiency answers against the allocation numbers by hand.
Read-only is not harmless: the scoping rules
Here is the hard question from the top of this post, answered directly: no, read-only cost tools are not automatically safe to expose. They can't mutate anything, but tool output lands in agent context, and cost data is more revealing than it looks. Five rules:
| Rule | Why | How |
|---|---|---|
| Scope cost tools per audience, not per cluster | A tenant's cost breakdown leaks usage patterns — traffic shape, job schedules, GPU hours — you'd never show another tenant's dashboard to them | Give tenant-facing agents only their own namespace's slice (filtered queries or a proxy); keep cluster-wide aggregation on the operator agent |
| Keep cost-read and deploy-write agents separate | An agent holding both cost data and kubectl-equivalent tools can turn a leak into an action in one session | One identity with cost tools only, another with deploy tools behind approval; never merge them for convenience |
Set MCP_QUERY_TIMEOUT_SECONDS and bound window | Wide windows over long histories are the most expensive queries in the building; an agent in a retry loop can pile them up | Cap the timeout, cap the maximum window your proxy accepts, and rate-limit the endpoint like any other API |
| Audit-log every cost query | "The agent looked at tenant B's spend" is an incident you want a record of, not a mystery | Log tool name, arguments, and caller identity; the field-level-security playbook (scoped tools, passthrough identity, audit trails) applies here unchanged |
| Treat the MCP server as supply chain, like any other | Third-party MCP servers have had real CVEs — command injection via OAuth proxies, path traversal in hosted pipelines — and cost endpoints deserve the same suspicion | Pin the chart version, review what the server exposes before upgrading, and don't front it with broader network access than the REST API already had |
None of this is exotic. It is the same least-privilege discipline the MCP security press has been repeating all year — an August 2026 Hacker News rundown of enterprise-secret exposure via MCP servers makes the general case — applied to one specific data type. The only FinOps-specific insight is the first row: cost data feels boring, which is exactly why teams under-scope it. A per-namespace spend curve over 30 days is a usage fingerprint. Scope it like one.
Where this goes next
The trajectory is clear from the upstream tracker. The proposed additions — GPU cost attribution (allocated vs. effective vs. waste per workload), optimization recommendations, and anomaly detection as first-class tools — would move the server from "query layer" to "junior FinOps analyst." Combine that with v1.121's inference cost tracking, and the 2026 arc is obvious: OpenCost is racing to instrument exactly the workloads (GPU inference, agent sandboxes) whose costs teams understand least. The State of FinOps 2026 report found 98% of practitioners now manage AI spend; most still lack the granularity to govern it, which is the gap this tooling exists to close.
Adopt it now, with the scoping rules above, rather than waiting for the schema to settle. The three core tools wrap the same battle-tested allocation APIs the dashboard has used for years — the MCP surface is new, the numbers underneath are not. What is new is who (and what) can ask. Put the guardrails in first, then let the agent answer the cost questions your team never had time to click through.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
