Skip to main content
Glama

paleobiology-mcp-server: search fossil occurrences

paleobiology_search_occurrences
Read-onlyIdempotent

Search fossil occurrences filtered by taxon, geologic time, geography, and depositional environment — the flagship. Use base_name for a clade and all its descendants (what "Tyrannosaurus occurrences" usually means), base_id for that same clade by resolved taxon id, or taxon_name for an exact taxon. Bound the age by a named interval (e.g. "Maastrichtian") or a max_ma/min_ma range, and/or a lng/lat bounding box; scope to a single locality with collection_no (take it from a paleobiology_search_collections row). At least one filter is required — taxon, time, place, environment, or collection_no. Every row carries two distinct coordinate systems — modern lng/lat (where the rock is today) and paleo lng/lat (where the landmass sat at deposition) — plus the formation, age interval, and higher classification (phylum through genus); never plot a deep-time occurrence on a modern coastline. Resolve a name with paleobiology_get_taxon first if unsure. Broad queries return many rows: an inline preview answers the immediate question, and when the set outgrows that preview the matching occurrences — up to the per-call cap — stage on a DataCanvas (canvas_id + table_name, returned only then) for SQL via paleobiology_dataframe_query (count by interval, group by formation/country, map by region). The response reports how many occurrences matched in total, which rows this page covers, and the offset that reaches the next page — page through the whole match set with limit/offset.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum occurrences to pull per page (1–500). Caps the pull (further bounded by PBDB_MAX_OCCURRENCES); broad queries stage that page on the canvas for SQL. Pair with offset to walk the whole match set.
latmaxNoNorthern edge of the bounding box, decimal degrees (−90…90). Valid on its own — a lone latitude edge filters as a half-plane.
latminNoSouthern edge of the bounding box, decimal degrees (−90…90). Valid on its own — a lone latitude edge filters as a half-plane.
lngmaxNoEastern edge of the bounding box, decimal degrees (−180…180). Longitude is a closed pair — supply lngmin with it or neither.
lngminNoWestern edge of the bounding box, decimal degrees (−180…180). Longitude is a closed pair — supply lngmax with it or neither.
max_maNoOlder age bound in millions of years ago. Alternative to interval. When paired with min_ma it must be strictly greater — max_ma is the deeper-time end of the window.
min_maNoYounger age bound in millions of years ago. Alternative to interval. When paired with max_ma it must be strictly smaller — min_ma is the nearer-to-present end of the window.
offsetNoNumber of matching occurrences to skip before this page — page with limit by advancing offset. The response notice names the exact offset that reaches the next page.
base_idNoClade-inclusive taxon filter by PBDB taxon id — the taxon_no from paleobiology_get_taxon, or accepted_no on an occurrence row. Same clade-inclusive semantics as base_name, but unambiguous where a name is not (homonyms, synonyms, unresolved spellings). Supply this or base_name, never both.
intervalNoNamed geologic interval bounding the age, e.g. "Cretaceous" or "Maastrichtian". Alternative to max_ma/min_ma.
base_nameNoClade-inclusive taxon filter — this taxon and all descendants, e.g. "Dinosauria". The usual choice. Supply this or base_id, never both.
canvas_idNoCanvas id from a prior call to re-stage onto the same workspace. Reusing it REPLACES (overwrites) the prior occurrence table — each search restages the full result, it does not append to or accumulate across earlier ones. Omit to start fresh; the response returns a new id.
taxon_nameNoExact taxon filter — only this taxon, not descendants. Use instead of base_name when you want a single taxon.
environmentNoDepositional environment: "marine", "terrestrial", or "freshwater" (lacustrine + fluvial). Omit for all.
collection_noNoRestrict to one collection (locality) by its PBDB collection_no — the fauna found together at that site. Take the id from a paleobiology_search_collections row to drill from a locality into its occurrences.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance when no occurrence matched, when results spilled to the canvas, when occurrences remain past this page (naming the offset that reaches the next one), when offset ran past the end of the match set, when a filter value was not recognized and ignored, or when DataCanvas is off.
spilledNoTrue when the result exceeded the inline preview and the staged occurrence set was written to the canvas.
canvas_idNoCanvas id holding the staged occurrence set — pass to paleobiology_dataframe_query. Present only when spilled is true; a result that fit inline stages nothing, so there is no table to query.
row_countNoRows staged on the canvas when spilled; otherwise the preview length. Capped at the per-call limit (PBDB_MAX_OCCURRENCES) — compare against the totalCount enrichment for how many matched upstream.
table_nameNoCanvas table holding the staged occurrence set. Present only when spilled is true.
totalCountNoTotal occurrences matching the filters upstream — the number this call was drawn from, which may exceed the staged set.
attributionNoCC-BY data attribution for the Paleobiology Database.
occurrencesNoInline preview of matching occurrences for the requested page. The staged occurrence set is on the canvas when spilled is true — it is one page of the match set rather than every match (the notice states which rows this page covers, how many matched upstream, and the offset that reaches the next page).

TDQS

A5/5.0
Behavior5/5

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

Beyond the readOnly and idempotent hints, the description discloses important behavioral traits: the two distinct coordinate systems and the warning never to plot deep-time occurrences on a modern coastline, the staging of large result sets onto a DataCanvas, the per-call cap, and the fact that reusing a canvas_id replaces the prior table. It also explains pagination behavior with total counts, covered rows, and next-page offsets, adding real context the annotations alone do not provide.

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

Conciseness5/5

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

Though long, the description is dense and every clause earns its place; there is no filler or restatement of the schema. It is front-loaded with the core purpose, then flows naturally from filter choices to output behavior to related tools, making the complexity navigable for an agent.

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 15-parameter flagship search tool with many siblings, the description is unusually complete: it covers required filters, taxon resolution, age/geography/collection constraints, coordinate-system pitfalls, large-result staging, downstream SQL access, and pagination. The output schema can carry the return-value details, so the description need not restate them; nothing essential for correct invocation is missing.

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

Parameters5/5

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

The input schema already documents all 15 parameters at 100% coverage, but the description adds cross-parameter semantics that the schema cannot convey: the clade-inclusive meaning of base_name vs exact taxon_name, the mutual exclusivity of base_name and base_id, the relationship between max_ma/min_ma and named intervals, and the rule that longitude must be supplied as a closed pair. It also explains that location and time filters can work together and that a lone latitude edge is valid.

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 — 'Search fossil occurrences' — and enumerates the filter dimensions (taxon, time, geography, environment), so an agent immediately knows what the tool does. It also distinguishes itself from sibling tools like paleobiology_search_collections and paleobiology_get_taxon by positioning this as the occurrence-level search and referencing the others only for supporting steps.

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: resolve names with paleobiology_get_taxon first, take collection_no from paleobiology_search_collections rows, and route SQL-style analysis to paleobiology_dataframe_query. It also clarifies choice points among alternatives such as base_name vs base_id vs taxon_name and interval vs max_ma/min_ma, and states the hard requirement that at least one filter is supplied.

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.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool targets a clearly distinct resource or workflow: taxa, intervals, occurrences, collections, diversity curves, and staged dataframe inspection. Even the two analysis-oriented tools (get_diversity and dataframe_query) are separated by whether the user needs a precomputed curve or arbitrary SQL over staged results.

Naming Consistency4/5

All tools share the paleobiology_ prefix and use clear snake_case names, so the set is predictable overall. The minor deviation is that dataframe_describe and dataframe_query place the object before the verb, while the other five tools use verb_object ordering (get_diversity, get_taxon, list_intervals, search_collections, search_occurrences).

Tool Count5/5

Seven tools is a well-scoped size for a Paleobiology Database client: two search tools, two lookup tools, two dataframe-analysis tools, and a diversity-curve tool. Each tool earns its place without redundancy or bloat.

Completeness5/5

The surface covers the full read-only workflow: resolve taxa, look up time intervals, search occurrences and collections, compute diversity curves, and run SQL analysis over large staged occurrence sets. No obvious gaps exist for the stated domain; pagination and staging hand-offs create no dead ends.