Good Earth

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.

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.

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.

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.

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.

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.

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 the ``dpop_token`` — the same token. The calling application MUST remember it and pass it as the ``dpop_token`` parameter on every subsequent paid tool call. The proof (a hash of the token) is stored in the vault keyed by that hash — the MCP never stores the raw token itself. Free.

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.

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.

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.

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.

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 demonstrated-proof-of-possession token that the calling application MUST remember and pass as the ``dpop_token`` parameter on every subsequent paid tool call. The MCP does not retain this value across restarts. **Lifecycle:** The cached proof expires after the patron's chosen duration. When it expires, call ``request_npub_proof`` again for a fresh challenge, then wait for the user, then call ``receive_npub_proof``. Free.

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).

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.

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 message inline (0.31.0 reads the SQL error body that earlier wheels swallowed behind ``raise_for_status``). RESTRICTED to operator — requires proof (nsec-signed).

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.

Check the health and configuration of this service. Free.

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 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.

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.

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.

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.

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.

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.

Mark one task done, or put it back.

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.

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.

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.

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 proof (nsec-signed kind-27235 or a cached dpop_token phrase); patron proofs are rejected.

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.

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.

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.