Good Earth

Goodearth Review Roster

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.

Input Schema

TableJSON Schema

Name	Required	Description
`npub`	No	Required. Your Nostr public key (npub1...) for credit billing.
`block`	Yes	The ground to answer for: a block you have saved — its id, its name, one of its aliases, or any part of its name that only one block has (e.g. "Meadow" for "Lower Meadow"). If several match, the error lists them with their ids. Blocks may overlap; each answers for its own ground. Save one with block_save first; geometry travels once, not on every call.
`pests`	No	The pests being watched: [{"pest": "Codling moth"}, ...].
`season`	No	Which season's roster to audit. Defaults to this one.
`wildlife`	No	The creatures being tracked: [{"species": "American robin"}, ...].
`dpop_token`	No
`observations`	No	Field reports to sanity-check: [{"kind": "frost", "observed_on": "2026-07-04"}, {"kind": "pest", "species": "Walrus", "observed_on": "2026-06-03"}].

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 15, 2026

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full disclosure burden. It explains that findings are about the record, never natural history, that nothing is removed, and that implausible observations feed goodearth_calibration and degrade later answers. This gives meaningful behavioral context beyond a simple 'audit' label.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than strictly necessary, with a motivational framing paragraph, but it is well-structured and front-loaded with the core purpose. Each subsequent section—findings, record-only constraint, patron decision—earns its place by clarifying behavior an agent needs before calling the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a conceptually complex tool with no annotations, the description covers the essential behavioral and conceptual context: sources, finding types, downstream consequences, and the non-destructive nature of the audit. It relies appropriately on the schema for parameter details and on the output schema for return structure, though it does not address permissions or prerequisites itself.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 86%, so the schema already documents most parameters. The description adds conceptual context about 'the record' and the meaning of findings, but it does not add details about individual parameters beyond what the schema provides. The baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Audit a roster against what this ground's record actually knows.' It names three distinct finding types (out_of_range, absent, implausible) and clarifies the tool is record-based rather than training-data-based, making it easy to distinguish from knowledge-answer tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear usage context: when asked 'are these the right pests to watch?' and when the answer should come from the record rather than the model's own knowledge. It does not explicitly name alternative sibling tools or when-not-to-use conditions, so it stops short of full exclusionary guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Good Earth tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.