Key Takeaways
- A geologic map shows which rocks lie where, in different colours. Its legend, the colour key, names each coloured area, for example “Jurassic sandstone”: a kind of rock (sandstone) plus the time it formed (the Jurassic, about 200 to 145 million years ago). AI in geology tools can turn such a name into a rock type and an age.
- The answer is broad, like sorting books only into “fiction” and “non-fiction”. The rock comes back as one of five big families, such as sedimentary (made from layers of sand or mud) or volcanic (made from lava), and the age as one huge stretch of Earth’s history, such as the Phanerozoic, roughly the last 540 million years.
- The tool matches words; it does not understand geology. It can match the wrong word, so always check which word it used.
TL;DR
Give this tool the name of one coloured area from a map’s colour key, such as “Jurassic sandstone”. It looks the words up in two fixed word lists and says roughly what kind of rock it is and how old. Treat the answer as a quick first guess, not a geologist’s reading.
What Is geomap_enrich_legend?
geomap_enrich_legend is the legend lookup tool in Stratigraphic Amenity, Eigenform’s open-source (MIT) MCP server for scanned geologic maps. It takes one non-empty label, such as “Jurassic sandstone”, and returns lithology (the rock type) and stratigraphic_age.
The tool is marked read-only and idempotent: the same label always gives the same answer. It creates no bundle or geomap:// resource; the server only keeps a small lookup cache on disk. Behind it sit two knowledge providers, rock_type and rock_age, which search K2 word lists from Microsoft’s PEACE project. They become ready once the peace-knowledge-base asset is installed. Without it, the call fails with missing_knowledge_asset.
However, the label itself has to come from somewhere. Map part detection finds legend swatches but reads no text, so labels come from the user or from a separate OCR or vision model.
How Does the Legend Lookup Work?
The lookup runs the same steps on every label.
Exact match first, then substring
The tool splits the label at commas, slashes, hyphens, the word “and” and several Chinese separators, then cleans each piece. A piece that equals a list entry wins, with match_type: "exact". Otherwise the tool picks the entry with the longest overlap, where one name contains the other, and marks it "substring". With no match, the field comes back null.
What the answers actually look like
The K2 lists are coarse. We ran the server’s own matching code on the lists it installs, from PEACE revision da99484:
| Legend label | Rock type | Age |
|---|---|---|
| Jurassic sandstone | sedimentary rocks | phanerozoic |
| Precambrian gneiss | metamorphic rocks | precambrian |
| Kgr granite | intrusive rocks | null |
| Tertiary basalt flows | volcanic rocks | null |
| Kgr | null | null |
The rock-type list has 728 entries but only nine distinct answers: five rock families in English and four in Chinese. The age list has 338 entries and five answers, all eons, so “Jurassic” becomes “phanerozoic”, not a period. Unit codes such as “Kgr” are not decoded, and “Tertiary” is not in the list at all.
Also, about half of each list is in Chinese, so a Chinese label can return a Chinese answer, such as 沉积岩 (sedimentary rock).
Check matched_name before trusting a match
Substring matching can pick the wrong entry. For “sandstone and shale”, the rock type is an exact match on “sandstone”. The age, however, comes back “precambrian”, because the age list holds a two-letter entry, “HA”, that sits inside the word “shale”.
Each result records matched_name and match_type in its provenance. So any AI in geology workflow should report a substring match as a guess and show what it matched.
Where Legend Enrichment Fits
Legend labels also feed questions about a scanned map: when a map query carries labels, the same two providers run on each one.
For AI in geology work, the result is a first sort of the legend into rock families and eons. It helps an agent group units or spot an obvious mismatch. A geologist, or the map’s own notes, still decides what each unit is and how old it is.
FAQs
What does geomap_enrich_legend return?
It returns the label, a lithology value and a stratigraphic_age value, plus one item per provider with the matched entry and match type. With the installed K2 lists, lithology is one of five broad rock families and age is an eon. A field with no match comes back as null.
Why does my legend label return null?
No list entry matched it. Map unit codes such as “Kgr” are not decoded, local formation names are rarely listed, and some common terms, such as “Tertiary”, are missing. If the K2 asset itself is not installed, the call fails with missing_knowledge_asset instead of returning null.
Why is the age so broad?
The installed age list maps every entry to an eon: Phanerozoic or Precambrian in English, or the Chinese names for the Phanerozoic, Proterozoic and Archean. So “Jurassic” returns “phanerozoic”. For a period or epoch, read the map’s legend notes or use a different stratigraphic source.
Can the tool read the legend text from the map?
No. The server ships no OCR, so it never reads words printed in the legend. Supply each label yourself, or from a separate OCR or vision model. Never let an agent guess a label from the colour of a swatch, because similar colours often mean different units.
Try It With Geocluster
Stratigraphic Amenity is one of the Geocluster tools, MCP servers that let AI agents work with geology data and maps.
Before calling this tool, an agent can check what the map server can do, including whether rock_type and rock_age are ready.
