# Good Earth

> Climate timing for gardens and small farms: frost, heat, soil and planting dates for your plot.

- name: io.github.lonniev/goodearth-mcp
- version: 0.3.0
- connection class: R2 (oauth_consent_once)
- trust: 94/100
- quality: 66/100 (needs work)
- owner: not claimed
- descriptor: https://api.protogrid.dev/v1/servers/io.github.lonniev%2Fgoodearth-mcp
- tools: https://api.protogrid.dev/v1/servers/io.github.lonniev%2Fgoodearth-mcp/tools

**An agent can connect after a one-time OAuth consent by a human.** Remote endpoint behind OAuth 2. Tokens stay with the agent; the registry only exposes the authorization metadata.

## Connection (mcpServers)

```json
{
  "mcpServers": {
    "goodearth-mcp": {
      "type": "http",
      "url": "https://goodearth-mcp.fastmcp.app/mcp"
    }
  }
}
```


## Trust

- hygiene: 100
- liveness: 100
- freshness: 85
- provenance: 90
- drivers: +repository +namespace-matches-repo +website +reachable +uptime-100% ~updated-31d-ago
- Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed.

## Quality 66/100 (needs work)

### protocol: n/a (weight 25)

- n/a `protocol.modern`, `protocol.stateless`, `protocol.transport`, `protocol.list_ttl`: no remote answered a protocol handshake (not probed yet, unreachable, or local-only)

### authorization: 83 (weight 15)

- pass `auth.prm`: Protected Resource Metadata (RFC 9728) published
- pass `auth.as_metadata`: authorization server metadata reachable
- warn `auth.cimd`: only Dynamic Client Registration, deprecated in 2026-07-28 in favour of CIMD
- n/a `auth.secret_in_url`: no templated URL

### tool hygiene: 79 (weight 30)

- pass `tools.descriptions`: every tool has a description
- warn `tools.description_length`: 12 tools have descriptions over 1,024 characters, which crowds the context
- pass `tools.schemas`: every tool has an object input schema
- pass `tools.annotations`: 85 of 85 tools declare readOnlyHint or destructiveHint
- pass `tools.directory_hints`: every tool declares readOnlyHint, destructiveHint, idempotentHint and openWorldHint
- fail `tools.token_cost`: about 30,897 tokens to load every tool, a large share of an agent's context
- pass `tools.api_dump`: tools are not a one-to-one API dump

### stability: 25 (weight 15)

- warn `stability.changes`: 104 tool changes in 30 days
- fail `stability.rug_pull`: 2 tools kept their name but changed most of their description in 30 days; review before trusting them

### dependencies: n/a (weight 15)

- n/a `deps.known_vulns`, `deps.mcp_sdk_version`, `deps.resolvable`: no npm or PyPI package

- tools: 85, about 30,897 tokens to load them all
- tool set hash: 27bbda8936667270304d6c64f10d2aea
- tools last changed: 2026-10-16T16:28:11.108Z
- badge: [![protogrid quality](https://protogrid.dev/badge/io.github.lonniev/goodearth-mcp.svg)](https://protogrid.dev/servers/io.github.lonniev/goodearth-mcp)
- Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed.

### Tool changes

- 2026-10-16 `goodearth_tree_suitability` changed (description)
  - before: 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 second. * **Will it fruit?** A deciduous fruit tree needs chill hours to break dormancy cleanly. The answer is how many winters on record delivered them. Both come back as a FREQUENCY across the record rather than a yes. A tree that survives nine winters in ten is a different proposition from one that survives five, and any single word hides the difference. Chill is counted as hours in the 32-45 °F band between 1 November and 15 February — the window the published chill-hour figures were derived against. A wider window would bank more hours against a requirement calibrated to a narrower one and report a tree comfortable where it is not. The requirements are yours. Hardiness limits and chill hours are cultivar figures that vary widely within a species; Good Earth computes what this ground delivered against them and does not publish agronomy.
  - after: 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 second. * **Will it fruit?** A deciduous fruit tree needs chill hours to break dormancy cleanly. The answer is how many winters on record delivered them. Both come back as a FREQUENCY across the record rather than a yes. A tree that survives nine winters in ten is a different proposition from one that survives five, and any single word hides the difference. Chill is counted as hours at or below 45 °F between 1 November and 15 February (1 May to 15 August south of the equator) — the model and window the published chill-hour figures were derived against. A wider window would bank more hours against a requirement calibrated to a narrower one and report a tree comfortable where it is not. The requirements are yours. Hardiness limits and chill hours are cultivar figures that vary widely within a species; Good Earth computes what this ground delivered against them and does not publish agronomy.
- 2026-10-15 `goodearth_pest_threshold` changed (inputSchema)
- 2026-10-15 `goodearth_frost_window` changed (description)
  - before: 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 pools in low, so a single forecast low is optimistic for a hollow and pessimistic for a bench on the same block.
  - after: 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. A season begins where this ground's own record never frosts — mid-July in Vermont, mid-January south of the equator — given as ``first_frost.season_starts``. ``this_season`` is the season so far, up to yesterday: its first frost, or with none yet, ``given_none_yet`` — when the seasons still frost-free by now went on to frost, which is the answer once the median has passed. The spread is the answer's point. Frost forms on still, clear nights when cold air drains off high ground and pools in low, so a single forecast low is optimistic for a hollow and pessimistic for a bench on the same block.
- 2026-10-15 `goodearth_sunlight` changed (title, inputSchema, annotations)
- 2026-10-15 `goodearth_block_transform` changed (title, inputSchema, annotations)
- 2026-10-15 `goodearth_drying_window` changed (title, inputSchema, annotations)
- 2026-10-15 `goodearth_disease_risk` changed (title, inputSchema, annotations)
- 2026-10-15 `goodearth_block_item_list` changed (title, inputSchema, annotations)
- 2026-10-15 `goodearth_block_item_save` changed (title, inputSchema, annotations)
- 2026-10-15 `goodearth_block_list` changed (title, inputSchema, annotations)

Full history: https://api.protogrid.dev/v1/servers/io.github.lonniev%2Fgoodearth-mcp/changes

## Remotes

- https://goodearth-mcp.fastmcp.app/mcp (streamable-http, auth oauth2, reachable true, uptime30d 1)

## Packages

_none_

## Tools (85)

- `goodearth_account_statement`: 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.
- `goodearth_account_statement_infographic`: 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.
- `goodearth_adoption_status`: 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).
- `goodearth_almanac`: 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 forecast.

Growers read these together with the heat. A week of high dew points is
disease weather whatever the degree-day total says, and a dry August is an
irrigation decision that heat accumulation cannot make for you.

One call covers every measure — three upstream requests regardless.
- `goodearth_block_item_list`: 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.
- `goodearth_block_item_save`: Record what you grow, watch for, saw, or hold seed for 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.
- `goodearth_block_list`: 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 the farm that contains it is two
blocks, each answered for its own ground. Read an overlap as intent, not as
one outline being wrong.

Each block names its `groups`. A group path like 'North Farm / Orchard'
sits inside 'North Farm'; `group` lists one group with everything inside it.
- `goodearth_block_save`: Save a plot of land, so every other tool can work it by name.

Several at once go in `blocks`: a whole layout in one call, because a
garden subdivided into beds produces many blocks at once and each one
should not be its own fare.

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 overlap is not a drawing error to correct.
- `goodearth_block_transform`: Propose bed layouts inside a plot. Writes nothing.

Reads the plot's outline and returns `variants` layouts, each with its
metrics (beds, path share, worst and median compactness, narrowest path,
and for rows the row-metres, turns and headland share), warnings, a small
SVG preview, and `accept.blocks`: the exact list to pass to
goodearth_block_save(blocks=…) to keep it. Blocks already inside the plot
are retired under a `v1 ` name in that same list, so the old layout stays
readable and its names are free. The new beds are saved in a group named
for the plot, inside each group the plot is in. A layout over 100 blocks comes as
`accept.batches`, saved in order.

Paths are the space between beds, kept at the width asked for after the
edges are softened. Below one terrain cell (about 90 m) neighbouring beds
share a climate sample; the warning says so, because the beds are then
bookkeeping and the climate answers stay at the plot's scale.
- `goodearth_calendar_dataset`: 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 feed token, which the
Good Earth site serves at a subscribable URL. Point any iCal or Google
Calendar client at it and the season appears next to the school run and the
market stall, which is where a grower will actually see it.

This is the computed act: it reads the weather feeds and rebuilds
everything. Pass the same token again to recompute in place — subscribers
keep their subscription and the events update rather than duplicating.

Nothing is passed in but the block: what it grows, what it watches for and
what is due are read from the record. That is what makes a refresh safe —
while those collections travelled as arguments, nobody could recompute an
existing feed without knowing what had been handed to it the first time,
so a refresh silently published a smaller season than the one it replaced.
- `goodearth_calendar_fetch`: 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 separate act from computing, and
every read is counted so the operator can see how hard a feed is worked.
- `goodearth_calendar_list`: The calendar feeds you have published, and how often each is polled.
- `goodearth_calendar_revoke`: Stop publishing a feed. Subscribers stop receiving updates. Free.
- `goodearth_calibration`: 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 bias in *heat* from crop stages (this ground accumulates more or less
than the grid credits) and a bias in *days* from observed frost (this
ground frosts earlier or later than the region). The block's sunlight
reports are counted and pointed at goodearth_sunlight, which reads them.

Nothing is applied silently. A correction appears only once several
observations agree, implausible values are set aside rather than averaged
in, and the reports behind every figure come back with it.
- `goodearth_check_authority_balance`: 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.
- `goodearth_check_balance`: 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 balances.
- `goodearth_check_payment`: 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.
- `goodearth_check_price`: 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.
- `goodearth_check_proof_status`: Check whether a proof grant 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. Expiry is read from
the grant itself; the only store consulted is the patron's
revocation watermark.

Free, no side effects — touches no relay.
- `goodearth_companions`: Companions for one planting on this block, of one of two kinds.

**Synergy** reads the planting's family and genus from iNaturalist and
applies published companion-planting rules — nitrogen fixers beside heavy
feeders, open flowers that feed the wasps that take aphids, alliums that
mask a carrot from its fly, walnut and fennel that poison the ground
beside them, the same family sharing its pests. Every row names its
mechanism or its tradition and a citation. These rules Good Earth
publishes rather than computes; it says so in the note.

**Design** is arithmetic over what you wrote down: a colour opposite on
the wheel is complementary, beside it analogous, white a foil; a plant in
a different height band layers; two that bloom in the same months are
seen together. A planting with no `flower_color` gets the field named
rather than a guess.

Candidates are the plantings on this plot, then everything you have grown
on your other blocks or retired, then a few classic garden examples —
each row says which. Plantings with no species chosen are listed as
`unplaced`; a typed name is never guessed into a family.
- `goodearth_crop_gdd_status`: 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 asking about eight beds costs one round trip
rather than eight.
- `goodearth_crop_suitability`: 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 season is
left after the crop is done, in the days a grower plans in. A crop that
finishes on the last warm day of an average year fails in half of them.

Requirements are yours. Published degree-day figures vary by cultivar and
maturity group; Good Earth computes against your ground rather than
publishing agronomy.
- `goodearth_delete_coupon`: 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.
- `goodearth_delete_operator_credential`: 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-delivery.

Stored-but-untemplated fields are first-class: the delete is keyed on
what is vaulted, not on what the current template declares. Idempotent
— already-absent fields report ``removed: false`` without rewriting
the vault. RESTRICTED to the operator — requires the operator's proof
(a kind-27235 event or a proof grant); patron proofs are rejected.
A deletion is as destructive as a write.
- `goodearth_delete_patron_credential`: 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.
- `goodearth_disease_risk`: 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 warm it was while it did, which is why
a dry August that accumulated heat all month grows no botrytis. A season
with nothing qualifying is reported as exactly that — risk that is absent is
as useful to a grower as risk that is present.

WETNESS IS ESTIMATED, NEVER MEASURED. No feed publishes a leaf wetness
sensor for arbitrary ground, so it is inferred from modelled humidity and
rain, and every answer names the estimator and the feed that fed it. That
matters more here than elsewhere: humidity crosses the 90% line in a step,
and two feeds a couple of degrees apart on dew point can differ threefold on
the hours they count.

Good Earth runs published models against your ground. It does not publish
plant pathology and it never recommends a treatment — registration is
jurisdiction-specific and a label rate is law. Take the decision to your
extension service, whose word counts where this service's does not.
- `goodearth_drying_window`: 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 hours, reference evapotranspiration (FAO-56 ET0) and peak
vapour-pressure deficit — how hard the air is pulling water out of anything
wet. Ten days ahead, from one forecast call.

Not wet is not drying: a still, overcast, humid day wets nothing and dries
little, which is why ET0 travels with every day. Wetness is ESTIMATED from
modelled humidity and rain, never measured, as in `disease_risk`.

Conditions only. Good Earth never says a crop is ready to cut or that hay
will cure — that depends on the crop, the swath and the field — and it
publishes no agronomy.
- `goodearth_forget_coupon`: 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``.
- `goodearth_forget_credentials`: 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.
- `goodearth_forget_my_ground`: 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 been told something
untrue. Any calendar feed you published stops resolving at once.

**You remain a patron.** Your balance and your purchase history are not
touched — those are the network's ledger rather than this operator's record
of your farm, and there is no name, email or KYC in this system to forget.
Sign in again with the same npub and you can start over on new ground.

Requires proof of the npub, like any call that reads your record. Free:
charging someone to leave is a toll on the door out.
- `goodearth_frost_window`: 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. A season
begins where this ground's own record never frosts — mid-July in Vermont,
mid-January south of the equator — given as ``first_frost.season_starts``.
``this_season`` is the season so far, up to yesterday: its first frost,
or with none yet, ``given_none_yet`` — when the seasons still frost-free
by now went on to frost, which is the answer once the median has passed.

The spread is the answer's point. Frost forms on still, clear nights when
cold air drains off high ground and pools in low, so a single forecast low
is optimistic for a hollow and pessimistic for a bench on the same block.
- `goodearth_gdd_season_curve`: 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 whole block.
- `goodearth_get_nostr_profile`: 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.
- `goodearth_get_notarization_proof`: Generate a Merkle inclusion proof that a patron's balance was
included in a Bitcoin-notarized snapshot.
- `goodearth_get_operator_onboarding_status`: 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.
- `goodearth_get_patron_credential_fields`: 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 fields is itself
sensitive (reveals which integrations a patron has set up).
- `goodearth_get_patron_onboarding_status`: 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.
- `goodearth_get_pricing_model`: 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.
- `goodearth_list_canonical_identities`: 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 missing from the registry. The latter appear
with ``registered: false`` (and in the top-level ``unregistered``
array) so Reconcile can flag deploy drift instead of silently
reporting clean when a live tool was never seeded (#174).

If the operator renames a function or rebrands a slug, the
mcp_name in this output changes but tool_id stays. That's the
whole point of the canonical-UUID design.

Also diffs the live FastMCP wire surface against the registry.
Tools exposed on the wire but absent from the registry appear in
``unregistered`` so Reconcile can flag deploy drift instead of
silently under-reporting (issue #175).

Free, no side effects.
- `goodearth_list_constraint_types`: 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.
- `goodearth_list_coupons`: 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.
- `goodearth_list_my_coupons`: 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``.
- `goodearth_list_notarizations`: List recent Bitcoin notarization records.
- `goodearth_mint_coupon`: Create a new operator-owned discount coupon.

The coupon owns its binding: ``tool_ids`` names the tools it
discounts, and re-pricing a tool never touches it. A coupon bound
to no tool discounts nothing, however many patrons redeem it.
- `goodearth_nearby_species`: 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 true total on every page.

**Species are a landscape fact, not a field one.** A nine-hectare hayfield
contains almost no observations, so the search widens to the surrounding
country and the answer says how wide it looked. Every other tool here
answers about the drawn ground and nothing outside it; this one cannot.

**The count measures observers as much as organisms.** A roadside is
better recorded than a back hayfield, so a high count is evidence somebody
was standing there — not that a thing is common on your ground.

No judgement of any kind. iNaturalist does not say which of these is a
pest, a weed, or worth planting, and sorting them into those would be
adding a claim the feed never made.
- `goodearth_notarize_ledger`: 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.
- `goodearth_oracle_about`: Describe the DPYC ecosystem via the Oracle. Free.
- `goodearth_oracle_get_tax_rate`: Get the current DPYC certification tax rate. Free.
- `goodearth_oracle_how_to_join`: Get DPYC onboarding instructions from the Oracle. Free.
- `goodearth_oracle_lookup_member`: Look up a DPYC community member by npub. Free.
- `goodearth_oracle_network_advisory`: Get active network advisories from the Oracle. Free.
- `goodearth_pest_catalog`: 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 281 in Vermont —
a convincing 8 October that is really a heat sum. Those are counted and
named as unreadable rather than rendered as dates.

The insects recorded nearby come from iNaturalist and are a landscape
fact: one field holds almost no observations, so the search is widened
to the surrounding country and the answer says how far.
- `goodearth_pest_threshold`: 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
numbers belong to your extension service and vary by region and biotype.
- `goodearth_plan_the_season`: 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 one question at a time. The
ordering is the point — it moves from the grower's decision to its
consequences rather than from the available data to a report.
- `goodearth_planting_window`: 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 frost record and the soil allow,
whichever is later; a tender crop waits for the last spring frost, a hardy
one uses the shoulder before it, a direct sowing waits for the soil, which
lags the air by weeks. Latest — the last day a sowing still has enough heat
left to beat the first fall frost, which is what decides whether an August
succession is worth the seed.

All from this block's own record rather than a zone map. The requirements
are yours.
- `goodearth_publish_nostr_profile`: 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.
- `goodearth_purchase_credits`: 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.
- `goodearth_receive_credentials`: 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 popped DM with the
wrong session phrase is deleted and its sender is NACK'd; the first DM
with the matching phrase is accepted (ACK'd) and the scan stops. If
none match, the queue is drained and a ``courier_not_found`` result is
returned. Do NOT poll, loop, or retry.

If a credential_card (ncred1...) is provided, it is redeemed directly
without any relay access (dpop_token not required for that path). On
success, the payment processor client is reinitialized from the new
credentials — no server restart needed.
- `goodearth_receive_npub_proof`: 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 ONLY the pinned
rendezvous relay that challenge was published on, stopping at the DM
whose phrase matches. Mismatched DMs are deleted and NACK'd (without
revealing the expected phrase). If called before the user replies,
their message will never be found. Do NOT poll, loop, or retry.

The signed DM itself proves npub ownership (the patron's nsec
signed it). On success, returns a new ``dpop_token``: an
Operator-signed **proof grant envelope** ``{"grant": …, "nonce": …}``
bound to the patron, this challenge, and the duration the patron
named. The calling application MUST remember that whole string and
pass it as ``dpop_token`` on every subsequent paid tool call. The
grant is self-verifying; nothing about it is stored here. Free.
- `goodearth_redeem_coupon`: 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 existing
redemption.
- `goodearth_report_issue`: 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). The report is PUBLIC
and goes to the maintainers' normal triage; nothing is verified here.

Returns the filed issue's repo, number, and url. If this operator has not enabled
field reports, returns an "issue reporting not configured" situation and you are not
charged.
- `goodearth_request_adoption`: 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
``adoption_status`` for progress; the operator flips to ``ready``
once the Authority provisions it.
- `goodearth_request_credential_channel`: 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 with a credential template. The recipient
must read the DM in their Nostr client, fill in the fields,
and reply manually. **This is a human-in-the-loop flow.**

After calling this tool, STOP and tell the user what to do.
Wait for the user to confirm they have replied before calling
``receive_credentials``. Do NOT poll or retry — each
``receive_credentials`` call destructively drains the relay
mailbox.
- `goodearth_request_echo`: Echo what the client sent with this request. Free.

Reports the URL path and query, the headers, the cookies and the MCP
request ``_meta``. Values are SHA-256 fingerprints, so nothing a client
sends is repeated back; equal fingerprints mean equal values. Call it
from two conversations and compare: a value that stays the same within
one and changes between them identifies the conversation.
- `goodearth_request_npub_proof`: 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 client. **This is a human-in-the-loop flow.**

After calling this tool, STOP and tell the user to check their
Nostr client and reply to the challenge. Wait for the user to
confirm they have replied before calling ``receive_npub_proof``.
Do NOT poll or retry — each ``receive_npub_proof`` call
destructively drains the relay mailbox.

**Returns** a ``dpop_token`` — the one-time challenge nonce shown in
the DM. Pass it to ``receive_npub_proof`` to collect the reply. It
is a matching token, not a credential: on its own it authorizes
nothing.

**Lifecycle:** ``receive_npub_proof`` returns the proof grant, which
expires after the duration the patron named in their reply. When it
expires, call ``request_npub_proof`` again for a fresh challenge,
then wait for the user, then call ``receive_npub_proof``.

Free.
- `goodearth_reset_pricing_model`: 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).
- `goodearth_restore_credits`: 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, patrons closing Top-Off sheets before settle,
any infrastructure incident that left an invoice settled at BTCPay
but uncredited on the operator's ledger.

Idempotent — if the invoice is already credited (in the patron's
``credited_invoices``), returns success with credits_granted=0.
- `goodearth_restore_neon_schema`: Prepare this operator's database schema again, ignoring the breadcrumb.

Diagnostic / recovery tool for when Neon keeps answering 4xx and the
operator suspects a table or grant is missing. Every statement is
idempotent, so a clean re-run is harmless; the breadcrumb is rewritten
at the end. Returns one step per concern, with Neon's own error text
inline for any that failed.

RESTRICTED to operator — requires proof (nsec-signed).
- `goodearth_review_roster`: 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 nearby.

Three findings:

- **out_of_range** — listed, and this ground's record does not know it.
- **absent** — the record knows it well and the roster does not list it.
- **implausible** — an observation that cannot be right, with what makes it
  wrong. This is the one that matters: observations feed
  ``goodearth_calibration``, which shifts the heat and frost bias for the
  whole block, so a junk entry degrades every later answer rather than
  merely showing a wrong row.

**Every reason is about the RECORD, never about the animal.** "Not recorded
within 16 km" is a fact; "does not live here" is natural history, which
Good Earth does not publish. Nothing is removed — the grower who genuinely
saw the odd thing is precisely the case worth learning from, so findings are
proposed and the patron decides.
- `goodearth_service_status`: Check the health and configuration of this service. Free.
- `goodearth_session_status`: Check operator readiness. Returns the operator lifecycle
state and clear guidance on what to do next. Free.

Lifecycle states:
- ready: Vault AND pricing model verified on this call. Proceed with
  tool calls — this is the answer the moment the vault is up.
- warming_up: Persistence could not be reached on this call (a
  transient failure, seen, not assumed). Retry; the next call
  completes the bootstrap. Never reported on a clock.
- misconfigured: Persistence rejected a query with a permanent SQL
  error (permission denied, missing relation). Paid tools will fail
  until the operator repairs the database — retrying does not help.
- quota_exceeded: The persistence provider (Neon) answered HTTP 402 —
  the operator's database has exhausted its compute/storage quota, so
  the books are locked for billing. Paid tools fail; retrying does NOT
  help. The operator's Authority must restore capacity (upgrade the
  plan or wait for the quota reset). Free tools remain available.
- not_registered: Operator has no Authority relationship yet. Call register_operator first.
- no_identity: Operator nsec is not configured. Deployment issue.
- `goodearth_set_pricing_model`: 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.
- `goodearth_soil_temp_projection`: 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 warm afternoon.
- `goodearth_sunlight`: How many hours of direct sun each part of this ground gets, month by month — and what a panel would make.

Rasterises the block at 2–20 m and, from every cell, casts the sky line
of the ground to 20 km and the trees within 250 m — from the Copernicus
terrain model and the Meta/WRI 1 m canopy map, both global — then counts
the ten-minute steps on the 15th of each month when the sun stands above
that line. Reports per month the share of the block in full sun (6 h or
more), part shade (3–6 h) and full shade (under 3 h), the median hours
and the spread, and the sunniest and shadiest spots with their
coordinates. Bare deciduous crowns pass half the beam; a month is in leaf
when the block's own normals say so.

The first call on a block casts its horizon, which takes some seconds;
later calls read it. The horizon is recast when the block is redrawn.

`solar` is a screening estimate for a fixed panel array at the given
tilt and facing: open-sky and shaded kWh per kW installed per year
(median, p10, p90 across the block), solar access (shaded ÷ open-sky,
the shade-report figure), the monthly open-sky yield, and the best
place for panels with its coordinates. A typical year averaged from ten
years of the ERA5 archive, the isotropic sky model, a performance ratio
of 0.80. Not a site survey.

`kw_prices` is what an array there would cost and earn, read live and
never stored in this code: `install` is DOE's PV system cost benchmark
(residential, commercial and utility $/W dc, modeled market price, and
the upkeep in $/kW a year, with its quarter) and `sell` is EIA's latest residential retail price for the
block's state in ¢/kWh (with its month) — the operator's EIA key makes the
second possible, and without one its `reasons.sell` says so.
`array_w_per_m2` (a 0.40 ground-coverage ratio of 220 W/m² modules) and
`tiers` turn a footprint into kW and pick the benchmark row. Sunlight ×
footprint × these is the arithmetic the web page does on a spot.

Measurements and classes only — the nursery-label definitions — never
what to plant. Trees cut or grown since the canopy imagery are not seen;
`sources` gives its date. Buildings are not modelled.

The block's own field reports correct that. Save an observation of kind
`sunlight` with goodearth_block_item_save — `{"kind": "sunlight",
"observed_on": "2026-06-14", "from": "09:00", "to": "14:00", "light":
"sun", "lat": 44.26, "lon": -72.58}` — and once three reports agree on a
spot, its hours and its light, that spot's horizon moves: a sun report
lowers the sky line where the sun was seen, a shade report raises the
tree line. `calibration` in the answer accounts for every report.
- `goodearth_task_delete`: 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.
- `goodearth_task_list`: 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 the query.
- `goodearth_task_save`: 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.
- `goodearth_task_set_done`: Mark one task done, or put it back.
- `goodearth_tree_suitability`: 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
  second.
* **Will it fruit?** A deciduous fruit tree needs chill hours to break
  dormancy cleanly. The answer is how many winters on record delivered them.

Both come back as a FREQUENCY across the record rather than a yes. A tree
that survives nine winters in ten is a different proposition from one that
survives five, and any single word hides the difference.

Chill is counted as hours at or below 45 °F between 1 November and
15 February (1 May to 15 August south of the equator) — the model and
window the published chill-hour figures were derived against. A wider window would bank more hours against a requirement
calibrated to a narrower one and report a tree comfortable where it is not.

The requirements are yours. Hardiness limits and chill hours are cultivar
figures that vary widely within a species; Good Earth computes what this
ground delivered against them and does not publish agronomy.
- `goodearth_tree_year`: 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 pollen forecast — Good Earth has no pollen feed, models
none, and says nothing about what anyone should do about it.

**The sap run**, for a block with maple, birch or walnut on it. Sap moves
on freeze and thaw rather than on warmth: a night below freezing followed
by a day above it. Counted off this ground's own season record, so it
costs no extra call. A block with nothing tappable gets no sap section —
the count would be just as true there and would answer a question nobody
on that ground asked.

The trees are read from the block's own record; nothing needs passing.
- `goodearth_update_coupon`: 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).
``tool_ids`` replaces the coupon's binding — tool ids or MCP tool
names, ``["*"]`` for every paid tool, ``[]`` to unbind it.

RESTRICTED to operator — requires proof.
- `goodearth_update_operator_credential`: 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 echoed back. RESTRICTED to the operator —
requires the operator's proof (a kind-27235 event or a proof grant);
patron proofs are rejected.
- `goodearth_update_patron_credential`: 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.
- `goodearth_wildlife_calendar`: 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 degree-day
threshold, a photoperiod threshold (migration runs on this, which is why it
barely moves between a warm year and a cold one), or a date from your own
record.

The thresholds are yours. Good Earth works out when they arrive here; it
does not publish natural history.
- `goodearth_wildlife_catalog`: 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 surrounding country
and the response reports how wide it looked; treating that footprint as
the farm would be the dishonest version.

The ranking measures observers as much as animals — a roadside is better
recorded than a back field — so the counts travel with the answer.

Pass a scientific name as `species` and this answers with that animal's
life-cycle phenophases instead — nest building, nestlings, fledged young,
calls or song, emergence above ground. Those come from USA-NPN, which
publishes them; they are not written into this service. Roughly half the
species recorded around a farm have them, and one that does not returns an
empty list rather than a guess, because "not tracked" and "does nothing"
are different claims.

Set `with_events` to get those phenophases for EVERY species in the list at
once, as `habit_events`. Ask for it before writing a roster: an agent left
to name events from memory writes "rut onset" and "southbound flights",
words this service has never used, where NPN says "Nest building" and
"Fledged young". It costs one upstream call per species, which is why it
is off by default.

**The event name is not load-bearing.** A wildlife row is dated by its
DRIVER — heat, daylight, an interval, a calendar date — and the label is
the grower's own words. `habit_events` is a courtesy to a caller looking
for the right word, never a list of the only acceptable ones: "Big Night
crossing" is a real thing a salamander does and no catalogue holds it.

Good Earth times an event you set. It does not publish natural history.