Skip to main content
Glama

Good Earth

Goodearth Disease Risk

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
npubNoRequired. Your Nostr public key (npub1...) for credit billing.
blockYesThe 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.
modelsNoWhich published models to run, as a list. Omit for all of them. Each row names one: {"model": "hutton"} for potato and tomato late blight, {"model": "botrytis"} for grey mould on cut flowers, and likewise "mills" (apple scab), "wallin" (early blight) and "powdery_mildew". Add "ref" to carry a saved row's id back on the answer. Do NOT invent a model name — the five are the ones this service runs.
seasonNoA past season year to count instead of this one. Omit for the season to date.
dpop_tokenNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/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 burden and does so thoroughly: it discloses that wetness is estimated, never measured, that the estimation source is named, and that the service does not provide pathology expertise or treatment advice. This is substantial behavioral context beyond a simple summary.

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

Conciseness3/5

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

The opening sentences are well front-loadednewlinewith the result summary, but the 'dry August' and 'degree days' section is illustrative rather than essential. Woven-in metaphor adds readability but lengthens the definition; it is appropriately sized for domain complexity but not maximally concise.

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?

Given the output schema exists and schema descriptions are rich, the description covers the domain-specific caveats an agent needs: estimation uncertainty, model limited set, and non-advice boundary. It could mention authentication or billing implications, but the npub parameter already covers billing in schema.

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 80%, so the schema already documents parameters like block, models, and season. The description adds conceptual meaning but does not clarify parameter formats or edge cases beyond what the schema states. It earns the baseline 3 without pushing higher.

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 names a specific verb and resource ('Returns the estimated wet hours', 'what the disease models make of them') and clearly enumerates the outputs: infection periods, criteria met, and forecasted wet stretch. It is unmistakably distinct from siblings like frost or pest tools through its focus on leaf wetness and disease models.

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

Usage Guidelines2/5

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

The description explains what the tool does and what it does not do (no treatment recommendations), but it never states when to prefer this tool over alternatives such as goodearth_pest_threshold or goodearth_crop_suitability. No explicit exclusions or sibling routing is provided.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.