AI assistants recommend quantization configs all day long: "use NF4, it cuts VRAM by 60%." Almost none of them mention energy — not because the numbers don't exist, but because the assistant was never given a way to look them up. As of today, any MCP client can: the EcoCompute estimator is a mountable tool, and every answer it returns carries its own evidence boundaries.
The estimator API now speaks MCP (Model Context Protocol — the tool standard that Claude Desktop, Cursor, and most agent runtimes already speak). Four tools, stateless, no key required:
| tool | answers | example |
|---|---|---|
estimate_quantization_energy | "should I quantize this model on this GPU?" | 7B → NF4 on Ada: −28.5% (measured · medium confidence) |
get_quantization_crossover | "from what size does quantizing start saving energy?" | Ada NF4: ≈3.7B — below it, quantization costs energy |
list_data_coverage | "is my GPU actually measured, or a gap?" | measured / borrowed / gaps, in three honest columns |
search_measurements | "was TinyLlama ever run on a 4090?" | six anchors, ΔE each, run counts included |
The reason this is more than an API wrapper: every tool answer embeds its caveats in the same text as the number — the basis label (measured / interpolated / estimated), the confidence, the measurement scope (GPU package power via NVML, not wall power), the fact that most RTX 4090 anchors are single-run (n=1), and the two dataset DOIs the claim rests on. A model relaying the answer cannot quote the −28.5% without also carrying "measured · medium · package power · n=1 · doi:…" along with it, because they arrive as one string.
Why that matters here specifically: this whole project is built on one methodological claim — every energy number must travel with its measurement provenance. The MCP tools are that claim in machine-readable form. And the coverage tool goes one step further: not having data is a first-class answer. An assistant wired to these tools learns to say "your card isn't measured yet — want to measure it?" instead of inventing a number.
Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"ecocompute": {
"type": "streamableHttp",
"url": "https://ecocompute-estimator.zhanghongping1982.workers.dev/mcp"
}
}
}
Cursor: Settings → MCP → Add server → URL, paste the same address. Generic clients: it's a stateless streamable-HTTP JSON-RPC 2.0 server — initialize, tools/list, tools/call are all it takes. The REST API and /openapi.json remain as they were.
user: 3B on my RTX 4090 — should I run NF4?
assistant: (calls estimate_quantization_energy)
ΔE vs FP16: +13.0% — pooled from 4090 (+0.8%) and 4090D (+25.2%)
anchors: basis measured, confidence medium
(calls get_quantization_crossover)
Ada NF4 crossover ≈3.7B — 3B is below it, where quantization
tends to cost energy.
Not recommended for energy: keep FP16, or if you need the VRAM,
accept the energy cost knowingly. Check your exact card: the
4090 and 4090D anchors disagree by 24 points inside the class.
No hedging theater, no invented percentages — and the disagreement inside the Ada class surfaces instead of being averaged away silently. That last part is the point: a tool that hides its spread teaches the model to hide it too.
estimated), INT8 on Turing/Blackwell has no measurement, sizes beyond the measured ranges are refused rather than extrapolated.list_data_coverage doubles as the project's to-do map. If your GPU isn't on it, you can change that in one evening: run the ecocompute-mlcube container, paste the validator output into the new data-submission issue form, and your measurement joins the next curve refit — credited, CC BY 4.0. Your assistant's next answer about your card will then be basis: measured.