Inspiration

Your cloud bill tells you what a service costs — a GKE cluster, $8,400 a month. It never tells you what one order costs, because that infrastructure is shared across products, across teams, and across projects. Splitting that shared cost is a contested judgment call, not a lookup — and it's the unsolved problem at the heart of enterprise FinOps. UnitScope makes that judgment call a live, agent-assisted control.

What it does

UnitScope attributes app1's real cost per completed order across three layers:

  • Dedicated resources — attributed directly by label (Cloud SQL, Firestore, Storage, a Dataflow job).
  • Shared in-project resources — a GKE cluster split by pod label / namespace, a Pub/Sub topic split by a per-message source_app attribute.
  • Cross-project global services — a fraud-check and a payments-gateway in another team's shared-platform project that every order calls. These can't be split by resource label, because one instance serves every product at once. They're attributed by OpenTelemetry baggage (product=app1) propagated with each call across the project boundary.

A human sets the allocation policy and the governance guardrails; an agent uses the page's WebMCP tools to compute the unit cost, explain any number, trace the flow across projects, model what-if volume, and stage optimizations — but any change to a prod-tagged resource or to a guardrail is stopped for explicit human approval.

Why it's a strong fit for WebMCP

The answer to "what does one order cost" depends on a human judgment — the allocation basis — that swings the number more than 15%. The agent has to compute and re-explain within whatever basis the human picks, live, on the same page. That's only possible because the page exposes stateful, guardrail-aware tools the agent reads and the human governs. A plain chatbot can report a number; it can't let a human govern the methodology while an agent does the math inside it.

How it creates a better experience

Cost allocation is normally a static, after-the-fact spreadsheet argument. UnitScope turns it into a live conversation: flip the allocation basis and every downstream number and the agent's explanation recompute instantly; ask the agent to trace a cost across a project boundary and it shows the attribution mechanism; ask it to optimize and it respects the boundaries you set.

What people and agents can do together that was hard or impossible before

The standout is guardrail negotiation. When a prod-protection boundary blocks an optimization the human asked for, the agent proposes relaxing the guardrail and explains why — but it cannot flip it. Only the human can confirm. The agent proposes, the human governs, the boundary holds. That two-way loop — where neither party could complete the task alone — is what WebMCP uniquely enables.

How I implemented WebMCP

A single self-contained page (React) registers 11 WebMCP tools via document.modelContext.registerTool — 7 read and 4 write:

  • Read: compute_unit_cost, explain_allocation, trace_product_flow, compare_unit_cost_periods, discover_product_topology, get_allocation_policy, (plus draft output).
  • Write: set_allocation_policy (change methodology), set_business_volume (change the denominator / what-if volume), simulate_optimization (stage a cost optimization), propose_guardrail_change (negotiate a governance boundary).

Mutating tools carry readOnlyHint: false and gate on explicit human approval. Every tool reads current page state through a ref, so the human's on-screen choices are always what the agent sees.

Data & methodology

Every figure is a seeded, plausible synthetic month so the app runs standalone — no cloud credentials, instantly testable by a judge. What's real is the allocation logic and attribution model: the split keys (pod label/namespace for GKE, source_app message attribute for the shared Pub/Sub topic, OpenTelemetry product baggage for cross-project services), the policy composition, and the guardrail enforcement. In production only the data source behind each tool's execute() changes — to BigQuery billing export, Cloud Monitoring, and OpenCost — not the tools, the attribution model, or the human/agent loop. The numbers are illustrative; the mechanism is the deliverable.


Testing instructions (paste into the testing-instructions field)

Open the live URL in ChatGPT's desktop app built-in browser (model: GPT-5.6 Sol or Terra), or in Chrome 149+ with chrome://flags/#enable-webmcp-testing enabled. Confirm the header reads "11 WebMCP tools live" (green). No login required. Then ask the agent, in order:

  1. What does one app1 order cost? → calls compute_unit_cost; answers ≈ $0.0701/order.
  2. Trace app1's order across projects — how is the global fraud service's cost attributed? → calls trace_product_flow; explains fraud-check + payments in shared-platform, attributed by OpenTelemetry baggage product=app1.
  3. Allocate GKE by actual CPU instead of requests. → calls set_allocation_policy; unit cost drops live to ≈ $0.0590, trend flips negative.
  4. What would an order cost at 300k orders next month? → calls set_business_volume; the denominator changes and cost-per-order drops live.
  5. Simulate a 25% Dataflow improvement. → calls simulate_optimization; because Dataflow is prod-tagged and "protect prod" is on, it stages the change for approval rather than applying it.
  6. Approve the staged card, or ask "the guardrail is blocking it — what do we do?" → the agent calls propose_guardrail_change and stages a guardrail-change card only the human can confirm.

Note: the agent takes a few seconds to reason and call a tool — that's model latency, not the app; the tools execute instantly.


Links

Live URL:   https://tranquil-licorice-d72166.netlify.app/
Repository: https://github.com/sgade123/unitscope
Video:      https://youtu.be/ItaSJwYtToE

Built with (tags)

webmcp, react, javascript, finops, gcp, opentelemetry, opencost, bigquery, netlify

Built With

Share this project:

Updates

Submission history