Good Earth

Goodearth Nearby Species

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.

Input Schema

TableJSON Schema

Name	Required	Description
`q`	No	Narrow by name — 'bumble', 'maple', 'Bombus'. Empty returns the most-observed first.
`npub`	No	Required. Your Nostr public key (npub1...) for credit billing.
`page`	No	Which page. 20 to a page.
`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.
`kingdom`	Yes	What to look for: 'plants', 'insects' (which includes spiders), 'wildlife' (birds, mammals, amphibians, reptiles) or 'fungi'.
`dpop_token`	No
`with_lifecycle`	No	Only the ones USA-NPN publishes a life cycle for. The count then counts those, not everything recorded here — thirty-nine of 2,416 insects around one block have one.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the transparency burden and reveals the non-obvious behaviors: 20-per-page results with the true total shown, search expansion beyond the block with a reported search width, counts reflecting observer presence rather than abundance, and zero added judgement. It also names iNaturalist as the source, adding useful context.

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 core sentence is front-loaded and bold lead-ins group related caveats, making the long description scannable. The illustrative Vermont/hayfield/roadside examples are useful for understanding the results, but they make the description more narrative than strictly necessary.

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?

For a search tool with an output schema and high-coverage input schema, the description explains everything an agent needs to know beyond the schemas: pagination, true total, geographic widening, observer-bias caveat, and non-judgmental output. The absence of annotations is fully compensated on the points that matter for calling and interpreting this tool.

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 coverage is high (86%) and the schema already gives strong descriptions for block, kingdom, q, page, npub, and with_lifecycle. The prose mainly reinforces page size and the meaning of the totals; it does not add new meaning or syntax for individual parameters, so the baseline 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 opening sentence states the exact action and resource: 'Search what is actually recorded near this ground, a page at a time.' It also distinguishes the tool from its siblings by explicitly saying that every other tool answers only for the drawn ground, while this one widens to the surrounding country.

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?

It tells an agent when to choose it: 'This replaces asking for a whole catalogue' and instructs 'search, twenty to a page.' It also gives a when-not by stating that every other tool answers strictly for the drawn ground and warning that no pest, weed, planting suitability, etc. judgement is made, which prevents misrouting and misinterpretation.

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.