Page 7 of 7 · Worked example · four live prompts, no script

Ask As You Go

The other three examples are pre-planned walkthroughs. This one is not: four ordinary questions asked back to back in one live session, each answered tools-only against the built servers with no lookup at the raw markdown artifact. It is the shape of day-to-day use — a practitioner exploring, not a script running.

finops-framework-mcp · capabilities, maturity, KPIs finops-focus-mcp · FOCUS 1.2 KPI mapping

List capabilities by domain official

PromptUsing only the MCP server for testing, list capabilities by domain.

One call returns all 22 capabilities with their domain already attached; grouping is just a client-side sort of the response:

Domain	Capabilities	Members
Understand Usage & Cost	4	Allocation Anomaly Management Data Ingestion Reporting & Analytics
Quantify Business Value	5	Budgeting Forecasting KPIs & Benchmarking Planning & Estimating Unit Economics
Optimize Usage & Cost	5	Architecting & Workload Placement Licensing & SaaS Rate Optimization Sustainability Usage Optimization
Manage the FinOps Practice	8	Automation, Tools, & Services Executive Strategy Alignment FinOps Assessment FinOps Education & Enablement FinOps Practice Operations Governance, Policy & Risk Intersecting Disciplines Invoicing & Chargeback

4 + 5 + 5 + 8 = 22, matching the tool's own total field — every capability the server knows about is accounted for in exactly one domain.

framework · list_capabilities {}

Summarize a capability official

PromptSummarize the sustainability capability.

“Incorporating sustainability criteria and metrics into FinOps activities to ensure environmental efficiency is balanced with financial value, and optimization decisions are aligned with organizational goals.”

Sustainability sits in the Optimize Usage & Cost domain. Its five featured KPIs, all carrying a published formula:

Carbon per Unit of Cloud Service SKU
Carbon per Unit of Cloud Spend
Carbon Waste / Carbon Efficiency
Forecast Accuracy Rate for Carbon Emissions
Percentage of CSP Cloud Carbon that is Tagging Policy Compliant

framework · get_capability {capability: "sustainability", include: ["summary","kpis"]}

Close a maturity gap official

PromptHow can we get to Walk maturity for this capability? How could we measure and validate our maturity?

The official assessment names the gap directly — Walk widens Crawl's narrow awareness and reactive optimization into org-wide, upstream, more formal practice:

At Crawl	Move to Walk
Basic awareness in a few key teams	All engineering teams and most other personas aware of impact on sustainability goals
Optimization = mostly elasticity / turning off unused resources	Expand to re-architecting / re-factoring workloads for both cost and carbon efficiency
Carbon data exists but poorly integrated	Share carbon data with engineering/product teams at finer granularity
Cost/carbon tradeoffs evaluated broadly, mostly on existing workloads	Evaluate more granularly; consider before migration/build decisions, not just after
Informal, inconsistent cross-persona collaboration	Structured collaboration with defined touchpoints and shared reporting
Sustainability reporting is manual / ad hoc	Begin incorporating sustainability metrics into allocation and chargeback models

The maturity levels are qualitative, not KPI thresholds — so validation pairs the checklist above with the capability's own KPIs as quantitative evidence the checklist items are actually true, not just self-reported:

Carbon Waste / Carbon Efficiency — a shrinking waste value is evidence optimization has moved from “turn off unused” to “re-architect for efficiency.”
% of CSP Cloud Carbon that is Tagging Policy Compliant — rising compliance is evidence carbon data is granular enough to allocate, the prerequisite for chargeback integration.
Forecast Accuracy Rate for Carbon Emissions — evidence carbon has actually entered the forecasting process, not just reporting.

framework · get_maturity_assessment {capability: "sustainability"} · get_kpis {capability: "sustainability"}

Cross-server starter KPIs official + UNOFFICIAL

PromptWhat are some initial simple KPIs to start our Unit Economics capability via FOCUS 1.2 data?

Unit Economics carries 9 official framework KPIs. Cross-referenced against the FOCUS server's derived KPI→column mapping, only 2 are computable from FOCUS billing data alone — the rest need external systems (carbon tooling, AI platform logs, finance/product analytics) the FOCUS spec does not carry:

KPI	Derived FOCUS 1.2 formula	Columns
Cost per API Call	SUM(EffectiveCost) WHERE ChargeCategory='Usage' AND ConsumedUnit denotes API calls / SUM(ConsumedQuantity)	ChargeCategory EffectiveCost ConsumedQuantity ConsumedUnit
Cost per Gigabytes Stored	SUM(EffectiveCost) WHERE ServiceCategory='Storage' / SUM(ConsumedQuantity) WHERE ConsumedUnit='GB'	ServiceCategory EffectiveCost ConsumedQuantity ConsumedUnit

Both are a plain SUM(cost) / SUM(quantity) group-by — good first KPIs precisely because they validate the pipeline's basic cost/usage join without needing anything beyond billing data. Neither is in the server's small auto-calculate_kpi list, though — asking for either returns:

“No calculable formula is registered for KPI 'cost-per-gigabytes-stored': its FOCUS-terms formula needs ambiguous free-text unit matching this server does not attempt to resolve automatically.”

Both the mapping and the formulas above are UNOFFICIAL — this server's own derived inference, not published by the FinOps Foundation or the FOCUS project — official: false on every response. Compute manually, or verify against get_column/get_requirements before production use.

framework · get_kpis {capability: "unit-economics"} · focus · get_kpi_mapping {capability: "unit-economics", version: "1.2"} · calculate_kpi {kpi: "cost-per-gigabytes-stored"|"cost-per-api-call", version: "1.2"} → error (not calculable)

Takeaways

What this session shows that the other three don't

Ad hoc questions work as well as planned walkthroughs. Nothing here was set up in advance — each prompt was answered from whatever the previous answer surfaced, the same way a practitioner would actually use it.
“Summarize” and “list” need no special tooling. A plain-language request maps directly onto one or two tool calls; the server does the structuring.
Maturity questions get qualitative answers with quantitative checks attached. The framework's Crawl→Walk bullets are prose, not thresholds — pair them with the capability's own KPIs to turn “we think we're doing this” into a trend you can chart.
Not every official KPI is FOCUS-computable, and the server says so. 7 of Unit Economics' 9 KPIs need data outside FOCUS entirely; of the 2 that don't, neither is in the auto-calculate list because “what counts as an API call” is provider-specific free text. A tool that names its own limits is more useful than one that guesses.

Back to the planned walkthroughs: Showback Reporting, Rate Optimization (ESR), and the Forecasting maturity journey — or the two server references, finops-framework-mcp and finops-focus-mcp.