Why this matters
Changing a Kubernetes resource request takes two numbers: what the workload requests, and what it uses. The CloudZero MCP server now returns both, by cluster, namespace, or workload.
This gives you a number you can defend. Usage comes back as P95 over the date range you query, 30 days by default. When an engineering lead asks whether a service runs on a smaller request, that is the figure that settles it.
Over-provisioning and under-provisioning show up on the same query. Efficiency is usage divided by request. A workload sized about right shows up clearly. One that reserves far more than it uses is a rightsizing candidate. One using more than it asked for is where CPU throttling and OOM kills come from.
Your CPU and memory over-provisioning recommendations already point at the workload to fix. Pull the current request and the P95 usage into the same response as the recommendation, and the service owner gets a number to set in the manifest, not just a resource name and a cost estimate.
Cost and efficiency resolve in one conversation. get_cost_data returns what a namespace costs. get_container_usage returns how efficiently it runs. Your agent holds both, so “why did this namespace get more expensive” gets answered with the utilization behind it.
What we built
get_container_usage, a new tool on the CloudZero MCP server.
partition_by accepts k8s_cluster, k8s_namespace, or k8s_workload. CPU comes back in cores and memory in GiB, each with three values: P95 used, requested, and efficiency, capped at 2.0. date_range is optional and defaults to the last 30 days, matching get_cost_data. filters scopes the answer to one cluster, namespace, or workload.
The tool runs on the hosted CloudZero MCP server, so it works from Claude Code, Cursor, VS Code, Codex, Gemini CLI, and any other MCP-capable client, using the OAuth sign-in or API key you already use for cost queries.
Report
Finance needs to prove AI’s return: CloudZero report
260 senior finance leaders (more than half CFOs) told us why the speed of seeing AI spend, not the size of it, separates who pulls ahead on AI from who gets burned.
How it works
Connect your MCP client to the CloudZero MCP server and ask in plain language. “What is the CPU and memory efficiency of the workloads in the payments namespace?” resolves to get_container_usage partitioned by namespace, filtered to that namespace. Kubernetes usage data comes from the CloudZero Agent for Kubernetes, so clusters running the agent return full results.
Or start from cost. “What is the CPU and memory efficiency of the most expensive workloads owned by the Dev Team?” Your agent finds the top workloads by cost for that team with get_cost_data, then filters get_container_usage to those workload names.
