Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者による説明(英語の原文)
Greener, cheaper cloud infra decisions — carbon + cost + latency tradeoffs, in-editor.
この3つを1つのスコアにまとめることはしません。意見、測定、人気はそれぞれ別のものだからです。
このサーバーのやさしい解説はまだ書いていません。以下はレジストリから読み取った事実です。
使っているAIアプリを選んで、設定をコピーしてください。
GREENPICK_CARBON_SOURCE, EIA_API_KEY, ENTSOE_TOKEN, ELECTRICITYMAPS_TOKEN, GREENPICK_CACHE_TTL_SECONDS, GREENPICK_LOG_LEVEL「秘密」と表示された値は、あなたのアカウントの鍵です。絶対に人に教えたり、チャットに貼り付けたりしないでください。
必要なもの
どのアプリを使っていますか?
上でアプリを選んでください。選んだアプリを覚えておくので、次からはボタンに「…にインストール」と表示されます。
Claude Desktop → Settings → Developer → Edit Config を開き、claude_desktop_config.json にこれを貼り付けます
{
"mcpServers": {
"greenpick": {
"command": "uvx",
"args": [
"greenpick"
],
"env": {
"GREENPICK_CARBON_SOURCE": "your-value",
"EIA_API_KEY": "your-value",
"ENTSOE_TOKEN": "your-value",
"ELECTRICITYMAPS_TOKEN": "your-value",
"GREENPICK_CACHE_TTL_SECONDS": "your-value",
"GREENPICK_LOG_LEVEL": "your-value"
}
}
}
}ターミナルでこれを実行します
claude mcp add greenpick --env GREENPICK_CARBON_SOURCE=your-value --env EIA_API_KEY=your-value --env ENTSOE_TOKEN=your-value --env ELECTRICITYMAPS_TOKEN=your-value --env GREENPICK_CACHE_TTL_SECONDS=your-value --env GREENPICK_LOG_LEVEL=your-value -- uvx greenpick動かす前に、空欄の値を入力してください。
プロジェクトの .cursor/mcp.json、または ~/.cursor/mcp.json に貼り付けます
{
"mcpServers": {
"greenpick": {
"command": "uvx",
"args": [
"greenpick"
],
"env": {
"GREENPICK_CARBON_SOURCE": "your-value",
"EIA_API_KEY": "your-value",
"ENTSOE_TOKEN": "your-value",
"ELECTRICITYMAPS_TOKEN": "your-value",
"GREENPICK_CACHE_TTL_SECONDS": "your-value",
"GREENPICK_LOG_LEVEL": "your-value"
}
}
}
}ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
プロジェクトの .vscode/mcp.json に貼り付けます
{
"servers": {
"greenpick": {
"type": "stdio",
"command": "uvx",
"args": [
"greenpick"
],
"env": {
"GREENPICK_CARBON_SOURCE": "your-value",
"EIA_API_KEY": "your-value",
"ENTSOE_TOKEN": "your-value",
"ELECTRICITYMAPS_TOKEN": "your-value",
"GREENPICK_CACHE_TTL_SECONDS": "your-value",
"GREENPICK_LOG_LEVEL": "your-value"
}
}
}
}ブラウザがアプリを開いてよいか確認し、そのあとアプリが設定を表示して確認を求めます。キーの値は空欄のままなので、自分で入力してください。
これはパソコンで動くサーバーですが、ChatGPTがつなげるのはインターネット上のサーバーだけです。ほかのアプリを選んでください。
選んだアプリは、この端末のCookieに保存されます。アカウントは不要です。
GREENPICK_CARBON_SOURCE envGREENPICK_CACHE_TTL_SECONDS envGREENPICK_LOG_LEVEL envこの設定は、作者のレジストリ登録情報から作成しています。READMEと違う場合は、READMEに従ってください。
パソコンで動くサーバーです。インストールすると、ツール一覧がAIアプリに表示されます。
誰でも見られる情報をチェックしており、コードは読んでいません。当てはまらない項目は数に入れていません。 · 2026年11月6日にチェック
レジストリ名は、リポジトリを所有するGitHubアカウント bithug01 で確認済みです
このリポジトリはまだGitHubから読み取っていません
このリポジトリはまだGitHubから読み取っていません
これはパソコンで動くため、インターネット上のエンドポイントはありません
パソコンで動き、代わりにローカルの設定を使います
パソコンで動くサーバーです。ツール一覧を読み取れるのは、インターネット上のエンドポイントがある場合だけです
レジストリでこのカテゴリにある有効なすべてのサーバーと比較しています。スターは、公開者がリポジトリの所有者である場合だけ数えます。
当てはまる基本チェック1項目のうち1項目に合格しました。コードは読んでいません。キーやトークンを追加する前に、サーバーがどんなアクセスを求めているかを確認し、必要な権限だけを持つキーを使ってください。
入力が必要なもの:EIA_API_KEY, ENTSOE_TOKEN, ELECTRICITYMAPS_TOKEN
あなたのパソコンで動きます。必要なときにAIアプリが起動し、データは作者のサーバーを通りません(サーバー自体がオンラインサービスを呼び出す場合を除きます)。
GitHubリポジトリの最終更新は–、最新バージョン(0.6.2)がレジストリに届いたのは昨日です。
Claude Desktop、Claude Code、Cursor、VS CodeなどのMCP対応アプリで使えます。パソコンにPython (uv)も必要です。
同じカテゴリには:Spec Driven Development, Remote Desktop Commander, Symantec Cloud DLP AIops
同じカテゴリで、ほかの作者が作ったサーバー。スターの多い順。
カードの見方:★ GitHubスターi3つの柱:レビュー · チェック · 利用状況i更新=最新バージョンをレジストリに公開した日i
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Governed Symantec Cloud DLP — 14 MCP tools, read-only with audit.
作者のリポジトリから書かれたとおりにコピーしたものです。PopNx MCPは内容を確認・推奨していません。HTML、画像、スクリプトは取り除いています。リンクはこのサイトの外へ移動します。
GreenPick
Write greener, cheaper cloud infrastructure — before you deploy.
A design-time sustainability co-pilot that runs as an MCP server inside your vibe-coding environment (Cursor / Claude Code / Kiro). Ask it where to deploy, when to run a job, or how to right-size — and it answers with an honest carbon + cost + latency tradeoff, in-editor, in seconds. (It responds when you ask; auto-nudging on infra-code changes is on the roadmap.)
Status: working — 19 tools. Live carbon for US (EIA-930), EU (ENTSO-E) and Canada (Hydro-Québec,
IESO — no key needed), cross-cloud cost
parity (Vantage-refreshed), per-axis R/Y/G ratings, carbon-aware scheduling + day-ahead forecast,
GPU-training and LLM-inference carbon, right-sizing, serving-pattern and data-locality/residency
checks — all shipped. Offline or without API keys, falls back to clearly-labelled *typical* values:
this month's average for each grid, from a year of real data.
*The same 40-GPU-hour training run emits ~0.6 kg CO₂ in Stockholm vs ~17.5 kg in Sydney — a ~28× difference from region choice alone (typical October grids; Sydney on Ember's 2025 national figure, a lower bound for its coal-heavier state grid). Ask GreenPick and it surfaces that (with the cost and latency tradeoff) while you're still in the editor, before you commit.*
▶ [See the 5-minute demo](docs/demo.md) — three scenarios with real tool output (training placement, the egress backfire, the forecast).
The same web service emits very different CO₂ depending on which region it runs in, because electricity grids differ in carbon intensity. Existing tools either rank regions in the abstract, or measure carbon *after* you deploy. GreenPick does it at the moment you choose, and tells you what the greener choice *costs you* in latency and dollars — so you can accept or reject it with eyes open.
The combination — cross-cloud, carbon + cost + latency, at design time, in the editor, with backfire guards — is the part nothing else puts together.
Roadmap: data-format/engine efficiency advice, sub-national grid zones, CI/CD integration. See docs/user-questions-backlog.md.
19 tools, grouped by what you're trying to do.
| Tool | What it does |
|---|---|
compare_regions_tri_axis | Rank candidate regions by carbon with cost + latency tradeoffs; recommend a pick, each axis rated R/Y/G. Pass regions to rank only the ones you'd actually consider. |
greener_alternative_to | "You picked X — the greenest region within +N ms latency is Y (−Z% carbon, Δcost)." The core nudge. |
region_carbon_now | Current gCO₂/kWh for a region, with source + timestamp + freshness — and, when live, whether that's cleaner, dirtier or about usual for that hour this month. |
| Tool | What it does |
|---|---|
cleanest_hours_to_run | Cleanest recent hours to time a deferrable job (ETL, backups, training), + % reduction. Pass window_hours for a job of known duration → cleanest contiguous window to start at. |
cleanest_time_of_day | For a recurring job (nightly batch): the region's cleanest time of day, averaged across recent days. A daily pattern, not a 7-day weekly one. |
greenest_regions_on_average | Which regions are cleanest on a typical day in a given month (or the whole year), ranked from last year's real data. Offline, no keys; a planning view, not today's grid. |
carbon_forecast | Forward-looking: which upcoming hours will be cleanest, from the EU day-ahead wind+solar forecast (ENTSO-E). Relative ranking; US/uncovered zones degrade to the recent historical pattern. |
| Tool | What it does |
|---|---|
estimate_workload_carbon | Rough kgCO₂/month for a workload in a region (an *estimate*, not a measurement). |
estimate_training_carbon | Carbon of a GPU training run (TDP-based energy × live grid), with greener where (region ranking) + when (cleanest hours) — the two levers that compound for portable, deferrable training. |
estimate_inference_carbon | Energy + CO₂ of an LLM inference workload, by model size class × output tokens × requests (× live grid). A low–high band; smaller size class is the big lever. Self-hosted-friendly; not a named-model leaderboard. |
| Tool | What it does |
|---|---|
greener_instance_family | A greener same-size family in the same region via perf-per-watt (newer generation / ARM Graviton-class does the same work on less energy). |
rightsizing_check | Right-sizing (the #1 FinOps win) with a carbon twin: if you're over-provisioned, a smaller size cuts both cost and carbon → the right-sized target with monthly $ and kg CO₂ saving. |
offhours_check | For dev/test/staging that doesn't need to run 24/7: the monthly $ and kg CO2 saved by running it only N hours a week. Compute only, directional. |
data_locality_egress_check | Warn when running compute away from where your data lives backfires: directional egress $ + coarse transfer carbon, and whether a greener-region move is still a net win. |
migration_payoff | Does moving the data to the compute's region pay off? Payback in months, one-off vs monthly egress and transfer carbon, net over 12 months. Egress only. |
region_move_justification | A short paste-ready paragraph for a pull request or decision record, with the carbon, cost, latency and egress numbers and their quality labels. Says so if the move is not an improvement. |
serving_pattern_advice | For a user-facing platform: serve from one region or several? Traffic-weighted latency + carbon, with the multi-region data-sync egress and cross-jurisdiction residency catches. |
| Tool | What it does |
|---|---|
carbon_metric_scaffold | Emits paste-in instrumentation (Python) so your app reports its own estimated carbon over time — observable proxies × GreenPick's power model × live grid. Self-tracking, directional; not a runtime meter. |
explain_methodology_and_limits | The assumptions and what GreenPick explicitly does not claim. |
cleanest_hours_to_run from recent hourly history.data/typical.json, refreshed by scripts/refresh_typical.py). Labelled quality: "typical" — a realistic norm, never presented as a current reading.data/annual.json). Labelled quality: "annual_average"; fine for comparing regions, but carries no timing signal.冒頭だけを表示しています。続きはリポジトリで読めます