Skip to main content
Glama

Good Earth

Goodearth Wildlife Catalog

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.

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.
speciesNoOptional. A scientific name from a previous catalogue answer, e.g. 'Strix varia'. Given one, this returns that animal's life-cycle phenophases instead of the regional list.
dpop_tokenNo
with_eventsNoInclude each species' known phenophases as `habit_events`, so a roster can be written from the published vocabulary rather than from memory. Costs one upstream call per species.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it excels. It discloses that the search widens to surrounding country when observations are sparse, that the response reports the footprint width, that counts reflect observer effort, that phenophases come from USA-NPN and are not written into the service, that untracked species return an empty list rather than a guess, and that the event name is not load-bearing. It even warns that the service does not publish natural history and that it times events the user sets. This is exemplary transparency.

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 long but every paragraph earns its place: it explains the ranking philosophy, the widening footprint, the phenophase source, the `with_events` cost, and the non-load-bearing nature of event names. It is front-loaded with the core purpose and then layers detail. It could be tightened slightly, but the length is justified by the conceptual complexity of the tool. The bolded warning about event names is a high-value addition.

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

Completeness5/5

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

Given the tool's complexity, the output schema presence, and the absence of annotations, the description is remarkably complete. It covers what the tool returns, how the ranking works, how the footprint is reported, what the phenophase mode does, what the `with_events` flag costs, and what the service does not do. An agent has everything needed to decide when to call it and how to interpret the response. The only minor gap is not describing the exact output shape, but the output schema exists and the description explicitly says the response reports the footprint width.

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

Parameters4/5

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

Schema coverage is 80%, so the baseline is 3. The description adds significant meaning beyond the schema: it explains the `species` parameter's behavior (returns phenophases instead of the list), the `with_events` parameter's cost and purpose, and the `block` parameter's matching semantics (partial names, ambiguity errors, overlap). The only parameter not enriched is `npub`, which the schema already describes as required for billing. The description compensates well for the 20% gap and adds context that the schema alone does not provide.

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 clearly states the tool's core function: listing animals actually recorded around a given ground, ranked by frequency, with a distinct mode for species phenophases. It distinguishes itself from siblings like goodearth_nearby_species and goodearth_wildlife_calendar by emphasizing that this is a catalog of observed species, not a calendar or a simple nearby-species lookup. The verb 'recorded' and the explicit contrast with 'a roster someone typed' make the purpose unmistakable.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: pass a scientific name as `species` to get phenophases, set `with_events` to get phenophases for every species, and save a block first with block_save. It also warns against using the tool for events not in the published vocabulary, and explains the cost tradeoff of `with_events`. This is far beyond typical usage guidance.

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.