# GreenPick (pypi · greenpick)

Greener, cheaper cloud infra decisions — carbon + cost + latency tradeoffs, in-editor.

- Trust score: 65/100 (medium)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-10-22

## Components

- pypi · `greenpick`: 65/100 (this document), [markdown](https://verifymcp.io/servers/bithug01-greenpick/greenpick.md), [page](https://verifymcp.io/servers/bithug01-greenpick/greenpick)

## Channel facts

- Registry: `pypi`
- Package: `greenpick`
- Version: `0.1.1`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-10-22.

- **Supply Chain Security**: 100/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - Runs setuptools.build_meta at install time, a recognised build step with no custom scripting around it.
  - 0 of 28 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 45/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 0 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 57/100
  - AI-judged instruction clarity (good).
  - Context-footprint check failed: tool/resource definitions use about 2323 tokens (~154/item across 15 items; 15 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 0/100
  - Stability observed for 0 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 67/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 0% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 15 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 15 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

**Unverified: 1 category.** A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

## Install

### How do I install the GreenPick MCP server?

GreenPick runs locally as a PyPI package, launched with uvx greenpick. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add bithug01-greenpick -- uvx greenpick
```

### Cursor

```json
{
  "mcpServers": {
    "bithug01-greenpick": {
      "command": "uvx",
      "args": [
        "greenpick"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "bithug01-greenpick": {
      "command": "uvx",
      "args": [
        "greenpick"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add bithug01-greenpick -- uvx greenpick
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "bithug01-greenpick": {
      "type": "local",
      "command": [
        "uvx",
        "greenpick"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add bithug01-greenpick --command uvx --arg greenpick
```

### Hermes

```yaml
mcp_servers:
  bithug01-greenpick:
    command: "uvx"
    args: ["greenpick"]
```

### Netclaw

```json
{
  "McpServers": {
    "bithug01-greenpick": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "greenpick"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add bithug01-greenpick -t stdio -c uvx -a greenpick
```

### Other

```json
{
  "mcpServers": {
    "bithug01-greenpick": {
      "command": "uvx",
      "args": [
        "greenpick"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-10-22 (score 65)

First indexed and scored.

## MCP tools (15)

### `compare_regions_tri_axis` (~218 tokens)

Rank candidate cloud regions by carbon, with cost + latency tradeoffs, and recommend one.
Give the user's location (lat/lon) and the service shape (vcpu, ram_gb, egress). Pass `regions`
(e.g. ["us-east-1","us-west-2","eu-west-1"]) to rank ONLY those you'd actually consider,
instead of the whole catalog — your baseline is always kept in the comparison. If the pick is
in a different region from where your data lives, run data_locality_egress_check before moving:
cross-region/cross-cloud egress can erase the carbon/cost win.

Input parameters:

- `baseline_region`
- `est_monthly_egress_gb` (number)
- `max_added_latency_ms`
- `optimize_for` (string)
- `providers`
- `ram_gb` (number, required)
- `regions`
- `user_lat` (number, required)
- `user_lon` (number, required)
- `vcpu` (number, required)

### `greener_alternative_to` (~189 tokens)

You picked `current_region` — find the greenest region within +max_added_latency_ms,
with the carbon/cost/latency delta vs. your current choice. The core 'nudge' tool. Pass
\`regions` to limit the search to options you'd actually move to; your current region is
always included. Before accepting a move, run data_locality_egress_check if your data stays in
the current region — the egress to feed compute from afar can outweigh the greener-region win.

Input parameters:

- `current_region` (string, required)
- `est_monthly_egress_gb` (number)
- `max_added_latency_ms` (number)
- `providers`
- `ram_gb` (number, required)
- `regions`
- `user_lat` (number, required)
- `user_lon` (number, required)
- `vcpu` (number, required)

### `estimate_workload_carbon` (~81 tokens)

Rough kgCO2/month for a workload running in a region. An ESTIMATE (documented power
model x grid intensity), not a measurement.

Input parameters:

- `hours_per_month` (number)
- `provider` (string, required)
- `ram_gb` (number, required)
- `region` (string, required)
- `vcpu` (number, required)

### `region_carbon_now` (~41 tokens)

Current grid carbon intensity for a region, with source, timestamp, and data freshness.

Input parameters:

- `provider` (string, required)
- `region` (string, required)

### `cleanest_hours_to_run` (~153 tokens)

Carbon-aware scheduling: given a region, report its cleanest recent hours so you can
time a DEFERRABLE job (nightly ETL, batch, backups, training) when the grid is greenest.
Returns the lowest-carbon hours + the % reduction vs. the dirtiest hour. Pass `window_hours`
(e.g. 6) for a job of known duration — it finds the cleanest CONTIGUOUS run of that many hours
to start at, since you can't split one job across scattered non-adjacent hours. Directional.

Input parameters:

- `provider` (string, required)
- `region` (string, required)
- `top_n` (integer)
- `window_hours`

### `greener_instance_family` (~140 tokens)

Suggest a greener SAME-SIZE instance family in the SAME region. The mechanism is
performance-per-watt: a newer-generation or ARM (Graviton-class) family does the same
work on less energy -> less CO2 at the region's grid intensity. Give your current family
(e.g. 'm5', 'n2', 'Dv5') for a savings delta. Directional, not a measurement.

Input parameters:

- `current_family`
- `hours_per_month` (number)
- `provider` (string, required)
- `ram_gb` (number, required)
- `region` (string, required)
- `vcpu` (number, required)

### `estimate_inference_carbon` (~201 tokens)

Energy + CO2 of running an LLM INFERENCE workload (serving queries) — the inference-side
sibling of estimate_training_carbon. Give the model SIZE CLASS (small | mid | large |
frontier_dense | moe, or a param alias like '8b' / '70b' / 'moe'), monthly request volume, and
avg OUTPUT tokens per request (output drives inference energy). Pass `region` to add CO2 at live
grid intensity. Returns a LOW-HIGH kWh/CO2 band (wide on purpose — serving choices move the same
model many-fold). Directional, most trustworthy for self-hosted/open models; keyed on size class,
NOT a named-model leaderboard. Smaller size class is the biggest lever.

Input parameters:

- `avg_output_tokens` (integer)
- `monthly_requests` (number, required)
- `provider`
- `region`
- `size_class` (string, required)

### `rightsizing_check` (~201 tokens)

Right-sizing (the #1 FinOps win) with a carbon twin: if you're over-provisioned, a smaller
size cuts BOTH cost and carbon — same work, less waste, no tradeoff. Give the provisioned size
(vcpu, ram_gb) and observed CPU utilisation (0..1, e.g. 0.2 for 20%); optionally RAM utilisation.
Returns the right-sized target (keeps ~40% headroom) with the monthly $ AND kg CO2 saving. Lead
with the cost number, carbon is the twin. Directional, design-time — uses the utilisation you
report, not a reading of your fleet.

Input parameters:

- `cpu_utilization` (number, required)
- `hours_per_month` (number)
- `provider` (string, required)
- `ram_gb` (number, required)
- `ram_utilization`
- `region` (string, required)
- `vcpu` (number, required)

### `carbon_metric_scaffold` (~196 tokens)

Emit paste-in instrumentation so the user's OWN app can report an ESTIMATED carbon metric
over time. Consider offering this when the user is building an app/service and wants ongoing
visibility into its footprint. GreenPick returns a code snippet (Python in v1) + the power-model
coefficients + a methodology note; the app measures observable proxies (CPU utilisation, vCPU/RAM,
uptime) and multiplies by GreenPick's power model x the region's grid intensity. Pass `region`
to bake in live grid intensity. The emitted number is a DIRECTIONAL estimate, self-labelled, NOT
metered energy — and it's for SELF-tracking, not ranking against other apps. GreenPick does not
run or measure anything itself.

Input parameters:

- `language` (string)
- `provider`
- `ram_gb` (number)
- `region`
- `vcpu` (number)

### `serving_pattern_advice` (~222 tokens)

Design-time advice for a USER-FACING PLATFORM: should you serve users from ONE region or
SEVERAL? Consider calling this when the user is building a web app / dashboard / API that serves
end users. Give `hubs` as where your users are — a list like
[{"name":"eu","share":0.4},{"name":"us","share":0.4},{"name":"apac","share":0.2}] (known names
us/eu/uk/apac/au/india/japan/sa resolve automatically, or pass lat+lon). Rough shares are fine.
Scores single-region-for-all vs one-region-per-hub on weighted latency + grid carbon, and flags
the multi-region catches: cross-region data-sync egress and cross-jurisdiction residency. This is
design-time guidance, NOT a runtime meter — it never measures your running app.

Input parameters:

- `hubs` (array, required)
- `providers`
- `ram_gb` (number)
- `vcpu` (number)

### `data_locality_egress_check` (~159 tokens)

Will running compute away from where your DATA lives backfire via egress? Give where
compute runs, where the data lives (provider+region), and monthly GB crossing between them.
Returns a directional egress-COST ballpark, a coarse transfer-carbon figure, and — if you
pass the carbon saving the greener-region move buys — whether it's still a net win. Use this
before accepting a greener-region suggestion when your data stays put.

Input parameters:

- `carbon_saving_kg_co2_from_move`
- `compute_provider` (string, required)
- `compute_region` (string, required)
- `data_provider` (string, required)
- `data_region` (string, required)
- `monthly_cross_boundary_gb` (number, required)

### `carbon_forecast` (~153 tokens)

Forward-looking scheduling: which UPCOMING hours will be cleanest? Uses the EU day-ahead
wind+solar forecast (ENTSO-E) to rank the greenest hours over the next `hours_ahead`. This is
a RELATIVE ranking (more forecast renewables = cleaner), not an absolute gCO2/kWh forecast.
EU regions get a true forecast; US/uncovered regions degrade to the recent historical pattern
(labelled 'historical'). Use this to PLAN a deferrable job, vs cleanest_hours_to_run (reactive).

Input parameters:

- `hours_ahead` (integer)
- `provider` (string, required)
- `region` (string, required)
- `top_n` (integer)

### `cleanest_time_of_day` (~124 tokens)

For a RECURRING job (e.g. a nightly batch you run every day), find the region's cleanest
time of day — each hour-of-day averaged across the recent days of data. Returns the cleanest/
dirtiest hour-of-day and the % gap. Honest scope: a DAILY pattern over the few days of free
data, NOT a 7-day day-of-week pattern. Use `cleanest_hours_to_run` for a one-off job's timing.

Input parameters:

- `provider` (string, required)
- `region` (string, required)

### `estimate_training_carbon` (~215 tokens)

Carbon of a GPU training run, with greener WHERE (region) and WHEN (hours) guidance.
Give the GPU (e.g. 'a100', 'h100', 'l4'), how many, and total GPU-hours for the run. Omit
\`region` to rank regions greenest-first; pass one to score just that region. Training is both
portable and deferrable, so this combines region choice with cleanest-hours timing. Directional
(TDP-based energy); GPU availability per region is NOT checked - verify your card is offered there.
Training data is often large: if your dataset lives in another region, run data_locality_egress_check
before shipping the job to the greenest region - the data egress can outweigh the carbon saving.

Input parameters:

- `gpu` (string, required)
- `gpu_count` (integer, required)
- `gpu_hours` (number, required)
- `provider`
- `region`
- `top_n_regions` (integer)
- `utilization`

### `explain_methodology_and_limits` (~30 tokens)

GreenPick's assumptions and what it explicitly does NOT claim. Read this before trusting a number.

## Diagnostics

Captured diagnostic sections: Provenance, Install scripts, Dependencies. The full working is on the page: https://verifymcp.io/servers/bithug01-greenpick/greenpick#diagnostics

## Score history

- 2026-10-22: 65

## Common questions

### What is the GreenPick MCP server?

GreenPick is an MCP server listed in the public MCP registry as io.github.bithug01/greenpick. Greener, cheaper cloud infra decisions, carbon + cost + latency tradeoffs, in-editor. This page covers its PyPI package (greenpick).

### Is the GreenPick MCP server safe to use?

GreenPick scores 65 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 22 October 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the GreenPick MCP server expose?

GreenPick exposes 15 tools: compare_regions_tri_axis, greener_alternative_to, estimate_workload_carbon, region_carbon_now, cleanest_hours_to_run, and 10 more. Their descriptions and schemas cost roughly 2,323 tokens of context every time the server is loaded.

### Is the GreenPick MCP server still maintained?

GreenPick is still listed as active in the MCP registry. We last reached this channel on 22 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the GreenPick MCP server under?

GreenPick declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- PyPI project: https://pypi.org/project/greenpick/
- Socket report: https://socket.dev/pypi/package/greenpick
- Repository: https://github.com/bithug01/greenpick
- Changelog RSS feed: https://verifymcp.io/servers/bithug01-greenpick/greenpick.xml
- Changelog JSON feed: https://verifymcp.io/servers/bithug01-greenpick/greenpick.json
- HTML version of this page: https://verifymcp.io/servers/bithug01-greenpick/greenpick