
Good Earth
io.github.lonnievv0.3.0更新於 Oct 6, 2026
Climate timing for gardens and small farms: frost, heat, soil and planting dates for your plot.
概覽
為花園和小型農場提供依區域劃分的氣候分析,讓助理查詢某塊土地的霜凍、熱量、土壤與種植時機。
- 功能
- Good Earth 針對一塊土地而非單一座標點回答氣候問題。工具接受 GeoJSON 多邊形或緯度/經度/半徑的定位點,對範圍內地形取樣,回傳彙總值以及範圍內的差異。已上線的工具包括與過去十個季節比較的積溫季節曲線;其他工具涵蓋霜凍窗口、光照與水分平衡、土壤溫度、作物積溫狀態、霜前完成、害蟲閾值與依區域的校正。餘額、購買額度、憑證與定價由標準 DPYC 工具處理。
- 適用情境
- 當助理需要為特定花園、地塊或小型農場協助決定種植日期、霜凍風險或熱量累積時值得加入,尤其是地塊內海拔有變化的情況。若只是查詢單點天氣,免費計算機已能回答,用處不大。
- 執行需求
- 遠端 streamable HTTP 端點;不需帳號,也不需 API 金鑰。任何接受遠端伺服器 URL 的 MCP 用戶端都可連線。付費工具需要種植者的 Nostr npub、一次透過私訊完成的 npub 憑證交換,並在每次付費呼叫時傳入 dpop_token;額度以比特幣閃電網路發票購買。免費工具包括服務狀態與 oracle 工具。
安裝
在 SourceWeft 中
- 開啟 儀表板中的 Good Earth,將其新增到工作區。
- 為需要使用其工具的對話啟用該服務。
Web executable,透過 Streamable HTTP。 遠端服務在工作區中設定後即可從網頁執行環境執行。
其他 MCP 客戶端
把它新增到你客戶端的 mcpServers 設定中。
{
"mcpServers": {
"goodearth-mcp": {
"type": "http",
"url": "https://goodearth-mcp.fastmcp.app/mcp"
}
}
}README
Good Earth
Region-scoped climate analytics for small specialty-crop and flower farms, monetized with Tollbooth DPYC™ Bitcoin Lightning micropayments.
Sibling of the Good Brew store.
- For growers: the web app at https://goodearth.tollbooth-dpyc.com
- For AI agents: the MCP server at
https://goodearth-mcp.fastmcp.app/mcp(streamable HTTP) — the same tools the web app calls.
Connect an AI agent
Any MCP client that takes a remote server URL can connect; there is no account and no API key.
server.json at the repo root is the entry for the official
MCP Registry, as
io.github.lonniev/goodearth-mcp — the namespace the rest of the DPYC fleet
is listed under. .github/workflows/publish-mcp-registry.yml publishes it on
every v* tag, logging in with GitHub OIDC and taking the version from the
tag, so there is no key to keep. A test holds the committed version to
pyproject.toml.
First connection walkthrough
- Ask the grower for their Nostr npub — never their nsec.
goodearth_request_npub_proof(patron_npub=…)sends them a DM. They reply from their Nostr client; then callgoodearth_receive_npub_proof(patron_npub=…, dpop_token=…)once, and passnpub+dpop_tokenon every paid call.goodearth_check_balance; top up withgoodearth_purchase_credits(a Lightning invoice the grower pays) andgoodearth_check_payment.goodearth_block_list— their saved ground, or a worked example to start from.
Free with no proof: goodearth_service_status and the goodearth_oracle_*
tools. goodearth_check_price previews a fare. The server's own
instructions repeat all of this for an agent that connects cold.
The idea
A farm is not a point. A bench and a hollow on the same acreage do not share a frost date, and every free weather calculator answers for a pin.
Good Earth answers for ground. Every tool accepts a GeoJSON polygon or a
{lat, lon, radius_m} pin, samples the terrain inside it, and returns an
aggregate plus the spread across it. That spread is the product: it tells
a grower whether one planting date serves the whole block.
How the spread is actually produced
This is the design decision the whole product rests on, so it is stated plainly rather than buried.
The free gridded temperature feeds resolve about 9 km. Two sample points on one farm land in the same cell and return byte-identical numbers — reporting that as "the range across your region" would be a lie dressed as data. Terrain, however, resolves at 90 m, and terrain is what varies within a farm.
So Good Earth reads the regional signal from the coarse feed and derives within-region variation from elevation:
Every response carries the native resolution of each feed it used, so a grower is never sold precision the data does not contain.
Tools
Standard DPYC tools (check_balance, purchase_credits, Secure Courier,
Oracle, pricing, constraints) come from the wheel via
register_standard_tools — none of it is reimplemented here.
Data sources
All free, all public, no API key.
A whole-region season read costs three upstream requests regardless of sample count: sample points are folded onto the archive's own grid so a distinct cell is fetched once, and the ten-season normals band is one span request sliced locally rather than ten separate calls.
Onboarding roadmap
- Nostr keypair — generate one (
nak key generate); the nsec is the single env var the server needs (TOLLBOOTH_NOSTR_OPERATOR_NSEC). - Sponsor Authority — register; it provisions your Neon database.
- Secure Courier — deliver
btcpay_host,btcpay_api_key,btcpay_store_idviagoodearth_request_credential_channel. Never as env vars, never in code. - Set prices in Pricing Studio — new tools start unpriced and nobody can call an unpriced tool.
- Deploy on Horizon —
fastmcp.jsonis already wired.
Get Pricing Studio (iOS). It reads and writes the pricing model live in Neon, so prices never live in code — surge, happy-hour, loyalty discounts and free trials are the thing a flat paywall can never give you.
The SPA
frontend/ carries the Good Earth app (the taxsort-mcp pattern — one repo,
React app inside). Sign-in, the proof envelope, and the Nostr profile panel
are the fleet's existing modules, borrowed rather than rewritten. Patron
state lives on Nostr as NIP-44-encrypted NIP-78 events under the
goodearth/* namespace — no accounts, and the farm's data never lives on
the operator's server.
Develop
License
Apache-2.0
來源:README.md,提交 d1a6674
工具
0版本歷史
2- v0.3.0最新Sep 19, 2026
- v0.2.0Sep 16, 2026

