Comprehensive Model Context Protocol server for managing Home Assistant through AI assistants.
Good Earth is installed from its publisher's own source and answers where it runs, so this marketplace is not in the path of a single call. There is no address here to send one to, and a panel that pretended otherwise would be showing you an answer we made up. Install it and call it from your own client — the Installation tab has the entry for each one.
What it does
Climate timing for gardens and small farms: frost, heat, soil and planting dates for your plot.
Quickstart
# 1 — add it to Claude Code
claude mcp add --scope user --transport http good-earth-mcp https://goodearth-mcp.fastmcp.app/mcp
# 2 — ask your agent for something these tools do
# goodearth_check_balance, goodearth_purchase_credits, goodearth_check_payment and 78 more
Good Earth costs nothing on mcprush: there is no plan to choose here, no cap to set and nothing mcprush can bill you for.
Collected from a public index. Nobody has claimed this account, so nothing here was written by its author — claim it if it is yours.
Where are you running it?
Every route below installs the same thing and ends at the same approval screen. Nothing here runs on your machine and nothing runs on ours: this server answers at its publisher’s own address, and what you install is the connection straight to it.
This is a public server: it answers at its publisher’s own address and this marketplace is not in the path. Claude Code registers it in one command; --scope user makes it available in every project. The transport below is http, as the publisher's own manifest declares it.
claude mcp add --scope user --transport http good-earth-mcp https://goodearth-mcp.fastmcp.app/mcpReconnect, or start a new session, and the tools appear in the model’s tool list.
One config entry pointing straight at the publisher’s own address — this marketplace is not in the path, and nothing from this listing executes on your machine.
81 tools, with what each one reads, writes and reaches shown before you agree — the same list on every route above. Read the tool surface.
Tool surface
What the model actually sees. Descriptions are diffed on every release — see version history.
Check a patron's credit balance at this operator. This is the patron's spending balance — credits purchased via Lightning for tool calls at this operator. For the operator's own balance at the Authority (needed to certify patron purchases), use authority_check_balance instead. Free — no credits required. Proof of npub ownership is required to prevent anyone-with-the-registry from enumerating bal
No parameter schema on file.
Buy credits via Bitcoin Lightning. Creates a Lightning invoice. Pay it with any Lightning wallet, then call check_payment to confirm. Proof of npub ownership is required so credits land in the correct ledger. Free — no credits required to call.
No parameter schema on file.
Check the payment status of a Lightning invoice. Call after paying the invoice from purchase_credits. Free — no credits required. Proof of npub ownership is required to prevent credit-grant front-running by an observer of the invoice ID.
No parameter schema on file.
Credit a patron's ledger from a BTCPay-settled invoice. RESTRICTED to the operator — the operator owns the books and is the only party who can issue a manual credit grant. Patrons who believe they paid but never got credits must escalate to the operator's support, who then invokes this tool on their behalf. Use cases: cold-start vault races during check_payment, ncred delivery hiccups, patro
No parameter schema on file.
Generate a patron's account statement at this operator. Returns the patron's purchase history, active credit tranches, per-tool usage breakdown, and recent daily usage logs. This is the patron's spending account — not the operator's Authority tax balance. Free — no credits consumed. Proof of npub ownership is required to prevent statement-scraping of arbitrary patrons.
No parameter schema on file.
Generate a visual SVG infographic of your account statement. Returns the same data as account_statement, rendered as a dark-themed SVG graphic with balance hero, metrics cards, health gauge, tranche table, and tool usage breakdown. Costs 1 api_sat per call. Proof is verified by `debit_or_deny` before any cost is incurred.
No parameter schema on file.
File a field report about this service as a GitHub issue on the operator's repo. Found a tool's metadata or response wrong or confusing? Report it where the tool lives. The author of record is your npub — no npub / no proof, no issue — and it is stamped into the issue so the report is attributed to you, not the operator. Costs a small fee (a free write to an issue tracker would be abused). Th
No parameter schema on file.
Check the health and configuration of this service. Free.
No parameter schema on file.
Report this operator's configuration readiness. Shows which operator settings are configured, which are missing, and how to deliver each missing value. For patron-level credential status, use get_patron_onboarding_status instead. Free.
No parameter schema on file.
Report a patron's credential readiness for this operator. For set-once services (eXcalibur, TheBrain), shows which patron secrets are configured and which are missing. For dynamic/OAuth2 services (Schwab), reports that no patron credentials are needed. Free. Proof of npub ownership is required because credential presence is sensitive information about the patron's setup.
No parameter schema on file.
Check operator readiness. Returns the operator lifecycle state and clear guidance on what to do next. Free. Lifecycle states: - ready: Operator is warm and fully operational — vault AND pricing model verified. Proceed with tool calls. - warming_up: Operator is initializing (cold start). Try a tool call — it will warm up on demand. - misconfigured: Persistence rejected a query with a permanent S
No parameter schema on file.
Open a Secure Courier channel for credential delivery. This is the CREDENTIAL-DELIVERY flow — use it to hand over a service secret (API keys, tokens). To merely prove you control an npub (the usual answer to a `proof_required error), use request_npub_proof instead. Note: dynamic/OAuth2 services (e.g. Schwab) need NO couriered secret — check service_status` first. Sends a welcome DM wit
No parameter schema on file.
Pick up credentials from the Secure Courier. Completes the CREDENTIAL-DELIVERY flow (the ownership-proof counterpart is `receive_npub_proof). Call this only after the user confirms they have replied. Deterministic, one-shot retrieval: name the response you want with (sender_npub, service, dpop_token)` and the tool drains ONLY the rendezvous relay that channel was pinned to. Every poppe
No parameter schema on file.
Delete vaulted credentials for a specific service and npub. For operator credentials, pass the operator's own npub. For patron credentials, pass the patron's npub. Always requires proof of npub ownership — a deletion is as destructive as a write.
No parameter schema on file.
Add or update a single patron credential field. Merges into existing stored credentials without affecting other fields. Useful for setting an account identifier after OAuth, changing a default brain, etc. Free. Proof of npub ownership is required — this is a write to the patron's sensitive credential vault.
No parameter schema on file.
Add or update a single operator secret field. Merges into the operator's stored credentials without touching the others — the field-level counterpart to re-delivering the whole bundle over Secure Courier. Use it to rotate one secret (a reissued `btcpay_api_key`, say) without restating the six you did not change, where any field omitted from a courier reply is destroyed. The value is never echo
No parameter schema on file.
Remove a single patron credential field. Deletes one field from stored credentials without affecting other fields. Free. Proof of npub ownership is required — this is a write to the patron's sensitive credential vault.
No parameter schema on file.
Remove a single operator secret field. Deletes one key from the operator's encrypted credential blob without touching the others — the field-level counterpart to `forget_credentials, which wipes the whole row. Use it to retire a leftover after an SDK cutover (a Prefect key after Modal, or a stored but untemplated orphan like anthropic_api_key`) without taking the operator down for a full re
No parameter schema on file.
List stored patron credential field names (not values). Returns the names of fields stored for a patron, plus each field's `delivered_at` ISO-8601 timestamp when known (null for secrets vaulted before timestamps were recorded). Values are never exposed — use this to verify which fields are configured and how old each one is. Free. Proof of npub ownership is required: the list of configured fiel
No parameter schema on file.
Request npub ownership proof from a patron via Nostr DM. This is the npub-OWNERSHIP-PROOF flow — use it when a call returns `proof_required. It proves the caller controls an npub; it does NOT deliver any service secret. To hand an operator its API keys or OAuth secrets, use request_credential_channel` instead. Sends a challenge DM that the patron must sign and reply to using their Nostr cl
No parameter schema on file.
Receive npub ownership confirmation from a patron. Completes the npub-OWNERSHIP-PROOF flow (the credential-delivery counterpart is `receive_credentials). Call this only after the user confirms they have replied. Deterministic, one-shot retrieval: name the response with (patron_npub, dpop_token) — the dpop_token being the value returned by request_npub_proof`. The tool drains ON
No parameter schema on file.
Check whether a previously-cached dpop_token is still valid. Mirrors `check_oauth_status` for the npub-proof flow: a calling agent can ask "will my next paid call accept this dpop_token?" before burning credits on a guaranteed failure. Free, no side effects — does not evict the cache or touch relays.
No parameter schema on file.
Get DPYC onboarding instructions from the Oracle. Free.
No parameter schema on file.
Get the current DPYC certification tax rate. Free.
No parameter schema on file.
Look up a DPYC community member by npub. Free.
No parameter schema on file.
Describe the DPYC ecosystem via the Oracle. Free.
No parameter schema on file.
Get active network advisories from the Oracle. Free.
No parameter schema on file.
Check this operator's tax balance at the Authority. Returns the sats available for certifying patron credit purchases. When this balance reaches zero, patron top-ups cannot be certified and the operator must call purchase_credits on the Authority. This is the operator's own funding — not a patron balance. Free.
No parameter schema on file.
Get the active pricing model for this operator. Free. If no model exists, self-initializes a scaffold with all registered tools at 0 sats. No economic data from code.
No parameter schema on file.
Set the active pricing model. RESTRICTED to operator. Requires a valid proof (Schnorr-signed kind-27235 event) proving the caller holds the operator's nsec.
No parameter schema on file.
Erase all pricing models and restore a viable default. Deletes every stored model, then self-initializes a fresh one from the tool registry — all tools at 0 sats with proper UUIDs. Returns the new model. RESTRICTED to operator — requires proof (nsec-signed).
No parameter schema on file.
Ask a chosen Authority to adopt this operator (deferred courtship). RESTRICTED to the operator — requires proof the caller controls this operator's npub. Resolves the Authority's MCP endpoint from the community registry, mints an inline ownership proof with this operator's nsec, and delivers the request MCP-to-MCP. The Authority records it as pending; its owner approves on their own time. Poll ``
No parameter schema on file.
Check this operator's adoption-request status at a chosen Authority. Free. Polls the Authority MCP-to-MCP for the status of this operator's request (pending / approved / rejected / provisioned).
No parameter schema on file.
Re-run `ensure_schema() on every NeonVault this operator uses. Diagnostic / recovery tool for the case where the Neon HTTP SQL API is returning persistent 4xx errors and the operator suspects the schema isn't there or grants are wrong. Idempotent — uses CREATE TABLE IF NOT EXISTS` so a successful re-run is harmless. Returns the per-step result. If any step raises, surfaces the Neon error m
No parameter schema on file.
Return canonical (tool_id, mcp_name, …) for every tool the wheel exposes. The authoritative source for any client (Studio, agents, FE) that needs to know how this MCP identifies its tools. Reconcile uses this output to UUID-join against the stored pricing model — no name-based UUID derivation, no guessing. Includes both ToolIdentity-seeded tools and any UUID recorded by `@paid_tool` that is mi
No parameter schema on file.
Read an npub's public Nostr profile (NIP-01 kind-0 metadata). Free, no proof — the data is already public on relays. Returns the latest metadata fields (name, display_name, about, picture, banner, nip05, website, lud16) or an empty profile if none is published.
No parameter schema on file.
Publish a CLIENT-SIGNED kind-0 profile to relays for an npub. The wheel never holds a patron nsec. The frontend signs the kind-0 metadata event with the patron's session key or a NIP-07 extension and passes the signed event (JSON) here; the wheel verifies the signature matches the npub, then relays it to public relays. The signature is the authorization — no proof token, no key custody. Free.
No parameter schema on file.
Preview the effective cost of a tool call. Shows the base cost and any constraint effects (discounts, free trials, surge pricing). Free — no credits required.
No parameter schema on file.
List all available constraint types and their parameter schemas. Returns the type, category, description, and parameter specs for every constraint that can be used in a pricing pipeline. Free — no credits required.
No parameter schema on file.
Create a new operator-owned discount coupon.
No parameter schema on file.
List every coupon this operator has minted (newest first). Each row carries the current `times_redeemed counter — the Studio renders a progress bar from this against total_uses`. RESTRICTED to operator — requires proof.
No parameter schema on file.
Patch a coupon's editable fields. Pass only the fields you want to change. To set a cap to unlimited (NULL in the schema), pass `clear_uses_per_patron=true or clear_total_uses=true`. Renaming the code is allowed — existing patron redemption rows survive (they key on coupon id). RESTRICTED to operator — requires proof.
No parameter schema on file.
Delete a coupon. Cascades to all patron redemptions. Any chain step referencing the deleted coupon_id becomes a no-op (the constraint returns neutral on unknown ids) — the Studio surfaces orphan references as warnings. RESTRICTED to operator — requires proof.
No parameter schema on file.
Claim a coupon by its name (the code the operator shared). Looks up the operator's coupon by `code, validates the window and total cap, and records a per-patron redemption row. Subsequent paid tool calls on this MCP auto-apply the discount until uses_per_patron is exhausted. Free — no credits required. Requires proof of npub`. Idempotent: redeeming the same code twice returns the exis
No parameter schema on file.
List the coupons this patron has redeemed on this operator. Returns both active and exhausted redemptions with a per-row `status (active / window_closed / patron_limit / total_limit). Free — requires proof of npub`.
No parameter schema on file.
Remove a coupon from this patron's redemption list. Cosmetic only — the coupon itself still exists at the operator, and the patron can re-redeem the same code later while the window allows. Free — requires proof of `npub`.
No parameter schema on file.
Build a Merkle tree of all patron balances and submit the root to Bitcoin via OpenTimestamps. Operator-only background task. Bitcoin confirmation takes 1-6 hours. Free — no credits required.
No parameter schema on file.
Generate a Merkle inclusion proof that a patron's balance was included in a Bitcoin-notarized snapshot.
No parameter schema on file.
List recent Bitcoin notarization records.
No parameter schema on file.
Growing degree day accumulation across a region, season to date. Returns accumulation with its spread across your ground, the band of the last ten seasons to read it against, a 7-day forecast extension, and a projection at the recent rate. The spread is the answer's point: it says how much the same field varies from bench to hollow, which is what decides whether one planting date serves the whol
No parameter schema on file.
When frost normally arrives on this ground, and whether it is coming this week. Returns first-frost dates from the last ten seasons, how far the region's own terrain spreads that, and a night-by-night assessment of the coming forecast for the *coldest* ground rather than the average. The spread is the answer's point. Frost forms on still, clear nights when cold air drains off high ground and poo
No parameter schema on file.
Where every planting on a block stands, and whether it finishes before frost. Returns, per planting: heat accumulated since set-out against its target, the projected date it reaches that target at the season's recent rate, and a verdict on whether that lands before the median first frost. One call answers the whole block. The season curve and the frost record are shared across plantings, so aski
No parameter schema on file.
When the soil on this ground crosses a planting threshold. Returns the near-term forecast at planting depth, the date it crosses within that horizon if it does, and when the crossing normally happens here — so a grower knows both "plant this week?" and "how long have I got?". Soil lags air by weeks and is the steadier signal. It is what decides whether a clove or a seed should go in, not one war
No parameter schema on file.
Where a pest model's degree-day stages stand on this ground. Returns, per model: heat accumulated since its biofix, which stages have been crossed, and the projected date of the next one — plus a short list of which pests to go and look for this week. Good Earth computes when your models arrive on your ground. It does not publish entomology: the thresholds are yours, because the authoritative nu
No parameter schema on file.
Turn a block's own field reports into a correction on the model. Every other tool here answers from a 9 km grid refined by a physical terrain model. What that cannot know is the part that makes a farm particular — the hedgerow, the pond, the outlet the cold air drains through. Your observations measure exactly that gap. Returns two corrections, kept separate because they fix different things: a
No parameter schema on file.
The sky's own record for this ground — normal, actual, and what is coming. Degree days say what the season is doing to the plants. This says what the season is doing: temperature, dew point, rain, wind, sunshine and day length, each against what is normal here, what has actually happened, and the fortnight ahead. Plus the sun and moon, which are astronomy and so are computed exactly rather than f
No parameter schema on file.
The season-planning interview, as a workflow to follow. The same text the plan_the_season MCP prompt carries. It exists twice because prompt support is uneven: a client that surfaces prompts offers this as a command, and one that does not can still reach it by calling a tool. Both read one constant, so they cannot drift into two different interviews. Follow the returned steps in order, asking
No parameter schema on file.
Audit a roster against what this ground's record actually knows. Asked "are these the right pests to watch?", an agent will answer from its own training data — unverifiable, different per model, and confidently wrong exactly at the margins where a review matters. This answers from the record instead: the degree-day models USA-NPN publishes for these coordinates, and what iNaturalist has recorded
No parameter schema on file.
Create or update one task. Single-day by design: one date and optional clock times on it. No recurrence and no multi-day spans — a farm list is a list of days.
No parameter schema on file.
One page of a region's tasks, ordered and filtered by the database. The sorting, the timeframe filter and the search all happen in SQL, so a long list costs one page rather than the whole table. `sort_col` names a column rather than supplying one: it indexes a fixed map and falls back to the due date, so an unrecognised value gives the default order rather than an error — and can never reach t
No parameter schema on file.
Remove one task. Scoped to the caller's npub in the WHERE clause, so a known id is not on its own enough to delete somebody else's task.
No parameter schema on file.
Mark one task done, or put it back.
No parameter schema on file.
Which pest stages are modelled for this ground this season. Read from the USA-NPN degree-day forecasts rather than from a list in this service, so a model they publish next season appears here without anyone editing anything, and a Georgia orchard gets Georgia's dates. Only layers measured to encode a day of year become dated events. Some carry accumulated heat instead, and one of those reads 28
No parameter schema on file.
Search what is actually recorded near this ground, a page at a time. This replaces asking for a whole catalogue. There are more than three thousand insect and spider species recorded around one Vermont block; the old answer showed forty of them and said nothing about the rest, and fetching all of them costs eleven round trips to build a list nobody reads. So: search, twenty to a page, and the tru
No parameter schema on file.
Which animals are actually recorded around this ground. Birds, mammals, amphibians and reptiles observed near here, ranked by how often each has been seen — so the answer for a Vermont lakeshore is not the answer for a Georgia orchard, and neither is a roster someone typed. Species are a landscape fact. A nine-hectare field contains almost no observations of anything, so the search widens to the
No parameter schema on file.
When the other creatures working your season arrive. A farm is not only its crops. Robins arrive, woodchucks wake, squirrels start caching. The same drivers that time a crop time the animals — heat accumulation, day length, and the calendar the sun keeps — so they can be computed for your ground rather than read off a regional average. Three clocks, because animals do not all run on one: a degre
No parameter schema on file.
Which crops finish on this ground, and with how much room to spare. "What can I grow?" is not a lookup. Two farms in the same county, one on a bench and one in a hollow, have different answers — so this measures the block's own frost-free window and the heat it accumulates inside it, then judges each crop's requirement against that. The answer that matters is not yes or no but MARGIN: how much s
No parameter schema on file.
Whether a tree survives and gets its chill on this ground. A tree is not asked "does it finish before frost" — that is a question only something that must finish in one season can be asked. It is asked two others, both settled before it goes in the ground: * Will it survive? Every winter on record has a coldest night; a cultivar has a limit. The answer is how often the first went below the
No parameter schema on file.
When spring reached this ground, and what the sap did. First leaf and first bloom, from USA-NPN's Spring Index, dated for this block and set against its own thirty-year normal. "Spring is early this year" is a headline; "leaf-out reached this block seven days before its normal" is something to act on. First bloom is also when the pollen starts. That is a restatement of what bloom is, not a p
No parameter schema on file.
Compute this block's dated season as a dataset, and store it for publishing. Every dated thing this block knows about: crop targets, pest stages, wildlife and husbandry dates, the frost record, and your tasks. Returned as structured rows — a calendar is one rendering of them, and a caller wanting a table or a notification wants the same data. An iCalendar rendering is stored alongside under a fe
No parameter schema on file.
Read a stored calendar dataset by its feed token. This exists for the Good Earth site, which serves the subscribable URL: a calendar client speaks HTTP and knows nothing about MCP, JSON-RPC or npub proofs, so the site fetches through here and renders the response as text/calendar. The unguessable token is the credential — there is nowhere in an iCalendar subscription to put a proof. Serving is a
No parameter schema on file.
The calendar feeds you have published, and how often each is polled.
No parameter schema on file.
Stop publishing a feed. Subscribers stop receiving updates. Free.
No parameter schema on file.
When to start seed, when to put it out, and the last day it still finishes. Heat requirement answers whether a crop CAN finish here. It says nothing about when to start, which is the decision actually made with a seed packet in hand in February. This answers three separate questions: Start seed indoors — counted back from the day it can go out, for a transplanted crop. Out — the earliest the fro
No parameter schema on file.
Delete every block you have here, and everything recorded on them. Blocks, crops, plantings, pest models, wildlife watches, field reports, tasks, published calendar feeds and the cached weather read for your ground. A real delete, not a retirement: every other removal in this service keeps the row as history, and this one does not, because a grower who asks to be forgotten and is quietly kept has
No parameter schema on file.
Save a plot of land, so every other tool can work it by name. Its area and sample count are measured here from the bounds you give, and returned — they are facts about the geometry, so there is nothing for you to keep in step. Blocks may overlap or nest. A grower who saves the whole farm and then the meadow inside it has asked two questions about two pieces of ground, and both are right; the ove
No parameter schema on file.
The ground you have saved, with its bounds. The blocks themselves and nothing else — what grows on them, what you watch for, and what you have seen are their own listing, so this answer stays the same size whether you farm one plot or forty. A grower who has saved nothing gets the worked example, marked as such, so there is always somewhere to stand. Blocks can overlap — a meadow drawn inside t
No parameter schema on file.
Record what you grow, watch for, or saw on a plot. A whole batch in one call, because an afternoon in the field produces several notes at once and each one should not be its own fare.
No parameter schema on file.
What you grow, watch for, or saw on a plot — a page at a time. as_of is how a past season answers: the record as it stood that day, rather than as it stands now. Sorting and searching happen in the database, over as many rows as the block holds rather than the page you are looking at.
No parameter schema on file.
Hours of leaf wetness on this ground, and what the disease models make of them. Returns the estimated wet hours since the season began, every qualifying infection period each model found, which of its criteria were met and which were not, and the wet stretch the forecast implies next. Degree days are the wrong clock for a fungus. What decides an infection is how long the leaf stayed wet and how
No parameter schema on file.
When the dew burns off this ground, the dry days ahead, and the next rain. Answers "is it dry enough yet?" for a grower planning to cut flowers, pick, mow or make hay. Returns this morning's and tomorrow morning's dew-off hour (the first hour the leaves are estimated to stay dry for two hours running), the first run of forecast days with no rain, the next hour of rain, and per day the rain, wet h
No parameter schema on file.
- Every tool — any call limit is its publisher’s, not ours
- No card, and mcprush charges nothing for it
- Runs at its publisher’s own address — this marketplace is not in the path
- Nothing to cap, because mcprush bills nothing
What counts against your monthly calls
| Tool | Unit | Calls used | Out of the allowance |
|---|
Nothing here is billable: mcprush charges nothing to install Good Earth or to call it, at any volume.
Two independent axes, because powerful and malicious are different questions. The grade is threat only. The capability level is blast radius, and it is never a penalty on the grade — it is priced as one subtract-only term in the score, where you can see it.
This listing is an address its publisher runs, and you connect to it directly — this marketplace is not in the path. The scanner reads packages and public source, and an address is neither: the repository linked on this page is where this record was collected from, not a copy of what the address serves, so it is not graded in its place. So there is no grade — not a withheld one, an unmeasured one.
Release history
This is an address its publisher runs: which release it serves is theirs to choose, so there is nothing here to pin. The history below is for reading; the current release on file is 0.3.0.
No release note was published with this version.
One review per account, from a signed-in account that does not publish this listing. Nothing else is asked — you can say what you think before you install it. Publishers can reply once per review, and a review can be edited or deleted by whoever wrote it.
Any signed-in account that does not publish Good Earth can review it, once — before installing it or after. A review from an account that has installed it is marked as one.
Nobody has reviewed this listing. The rating on the card is the mean of the reviews written here and nothing else, so there is no rating until somebody writes the first — which takes a signed-in account that does not publish it, and nothing else.