Page 5 of 7 · Worked example · two MCP servers, one outcome
From Capability to Calculation
You want to improve your Rate Optimization practice. This page walks the exact chain an AI agent walks: official FinOps Framework guidance → the KPIs that matter → the FOCUS™ columns that feed them, per spec version → a real number computed on real billing data.
Know the capability official
The Framework server answers what Rate Optimization is — verbatim Foundation content:
Its official maturity path runs from ad-hoc purchases (crawl) to a centrally-run cadence with utilization alerting (walk) to automated, KPI-triggered purchase cycles tied to workload architecture (run).
framework · get_capability {capability: "rate-optimization"} · assess_maturity_path {crawl → run}
Pick the KPIs official
Four KPIs are featured on the capability’s own page. Expand each for its official formula:
Effective Savings Rate Percentage featured
Commitment Utilization Score featured
% of Commitment-Based Discount Waste featured
Consumption versus Commitment featured
framework · get_kpis {capability: "rate-optimization", featured_only: true}
Translate to FOCUS columns derived · unofficial
No official KPI→FOCUS mapping exists — this one is derived by the FOCUS server and flagged unofficial on every response. Six columns cover all four KPIs. Flip the spec version to see what your billing data must provide:
| Column | Feeds | Type | Feature level | Normative requirements |
|---|
focus · get_kpi_mapping {capability: "rate-optimization", version} · get_column {column, version} · compare_versions {}
Compute on real data unofficial calculation
The FOCUS server computes KPIs over the official FOCUS 1.0 sample dataset — 1,000 rows of real, anonymized multi-provider billing data published by the FOCUS project (AWS 942 · Microsoft 51 · Oracle 7 rows).
26.55%
The three commitment KPIs tell a different — and instructive — story on this sample. The official 1.0 sample has no commitment-purchase rows, so their shared denominator is zero — and rather than fabricating a number, the server refuses:
“Could not calculate commitment-utilization-score over the FOCUS 1.0 official sample: the sample contains no ChargeCategory="Purchase" rows carrying a CommitmentDiscountId, so the commitment-spend denominator is 0 and this ratio is not computable (not 0%, 100%, or 0) — FOCUS 1.2's bundled sample has qualifying commitment purchase rows; try version="1.2".”
Taking the error's advice and re-running at version: "1.2" (synthetic sample, every result flagged UNOFFICIAL):
The lesson carries to production: validate that your export actually has commitment rows before trusting these ratios — and prefer tooling that says “not computable” over tooling that invents a zero.
focus · calculate_kpi {kpi, version: "1.0" → "1.2"} × 4 (bundled samples only)
Act
What a practitioner walks away with
Six FOCUS columns — ListCost, EffectiveCost, BillingPeriodStart/End, ChargeCategory, CommitmentDiscountId, ContractedCost — cover all four featured Rate Optimization KPIs, with identical semantics in FOCUS 1.0 and 1.2, so a pipeline built on 1.0 keeps working on 1.2 unchanged. The one version-aware upgrade: 1.2’s new CommitmentDiscountQuantity enables a true quantity-based consumption ratio instead of the spend proxy. Official guidance targets to steer toward: ~80% utilization waterline, daily unused-commitment detection, laddered expirations.
Connected to your own FOCUS-conformant billing export — or wired into an agent through these two MCP servers — this same chain turns “improve Rate Optimization” into monitored numbers and automated purchase-cycle triggers.
This example paired the two servers directly: see each on its own in the finops-framework-mcp and finops-focus-mcp reference pages, or continue to the other worked examples — Showback Reporting (an Allocation-focused chain from framework capability to a computed showback table), the Forecasting maturity journey (Crawl→Walk requirements plus the FOCUS columns a forecasting pipeline needs), and Quick Q&A (four unscripted live prompts across both servers, no pre-planned chain).