Skip to main content
Glama

paleobiology-mcp-server

by io.github.cyanheads
OverviewDiscussionsAdmin

Server Details

Search fossil occurrences, taxon ranges, diversity through deep time, and the geologic time scale.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
99.9% over 57 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
cyanheads/paleobiology-mcp-server
GitHub Stars
2
Server Listing
@cyanheads/paleobiology-mcp-server

TDQS

A4.4/5.0

Scored across 8 tools

Disambiguation5/5

Each tool targets a distinct resource or action: search_occurrences vs search_collections are clearly separated (fossil occurrences vs localities), get_taxon vs get_diversity differ (taxon resolution vs time-series), and dataframe_describe vs dataframe_query split schema discovery from SQL execution. list_intervals and get_references serve unique reference-resolution roles. An agent can reliably pick the right tool.

Naming Consistency4/5

All names use a uniform paleobiology_ prefix and snake_case with recognizable verb_noun patterns (get_taxon, list_intervals, search_occurrences, search_collections). The dataframe_describe/dataframe_query pair is noun-first, a minor deviation, but it is internally consistent and readable.

Tool Count5/5

Eight tools is well-scoped for a paleobiology data server: search, taxon resolution, diversity curves, references, interval reference, and a two-tool dataframe analysis path. Each tool earns its place with no redundant members.

Completeness4/5

The surface covers the full research lifecycle — resolve taxon, search occurrences/collections, analyze large sets via DataCanvas SQL, build diversity curves, and resolve references and geologic time. Minor gaps like dedicated mapping/export or visualization outputs exist, but core workflows have no dead ends.

Available Tools

8 tools
paleobiology_dataframe_describepaleobiology-mcp-server: describe staged canvas tablesA
Read-onlyIdempotent
Inspect

List the tables and their columns staged on a DataCanvas by paleobiology_search_occurrences. Call this before paleobiology_dataframe_query to discover the exact table_name and column names to reference in SQL.

NameRequiredDescriptionDefault
canvas_idYesCanvas id returned by paleobiology_search_occurrences when its result spilled.

Output Schema

NameRequiredDescription
errorNoPresent when the call failed. Absent on success.
tablesNoTables staged on the canvas.

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already convey readOnlyHint=true and idempotentHint=true, so the safe, non-mutating nature is covered. The description adds useful context that the tables are staged by paleobiology_search_occurrences and that this is a discovery helper, but it does not reveal additional behavioral details beyond that.

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?

Two tight sentences: the first states the core function and provenance, the second gives actionable next-step guidance. No filler or redundant restatement of the schema or annotations.

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 a single parameter, a descriptive schema, an output schema, and strong annotations, the description fully covers what an agent needs: what is listed, where it comes from, and when to invoke it. Return-value details are already present in the output 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 100% and the canvas_id parameter is already well-described as the id returned by paleobiology_search_occurrences when results spill. The main description does not need to add parameter-level meaning, so the baseline of 3 applies.

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 states a specific verb ('List') and resource ('tables and their columns staged on a DataCanvas'), and it explicitly ties the data to paleobiology_search_occurrences. It also distinguishes itself from paleobiology_dataframe_query by framing itself as the discovery step before SQL queries.

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

Usage Guidelines4/5

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

The description explicitly instructs the agent to call this before paleobiology_dataframe_query to discover table and column names, giving clear contextual usage. It does not include when-not-to-use exclusions, but for a single-sibling workflow this is sufficient.

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

paleobiology_dataframe_querypaleobiology-mcp-server: query staged occurrences with SQLA
Read-onlyIdempotent
Inspect

Run a read-only SQL SELECT against occurrence result sets staged on a DataCanvas by paleobiology_search_occurrences. This is how you analyze a large fossil set without re-fetching it: count occurrences by early_interval, group by formation, country (cc), or accepted_name, or filter by a paleo/modern coordinate range. The classification column is JSON — roll up by rank with json_extract_string(classification, '$.family') (also $.phylum, $.class, $.order, $.genus). Staged rows are occurrences, so collection-only fields such as lithology are not present. Reference tables by the table_name that paleobiology_search_occurrences returned — call paleobiology_dataframe_describe first if you do not know the table or column names. A result too large to return inline comes back as its first rows, with a notice naming the ORDER BY … LIMIT/OFFSET that reads the rest. SELECT only; writes and file-reading functions are rejected.

NameRequiredDescriptionDefault
sqlYesA read-only SQL SELECT. Reference tables by the names paleobiology_search_occurrences / paleobiology_dataframe_describe returned.
canvas_idYesCanvas id returned by paleobiology_search_occurrences when its result spilled.

Output Schema

NameRequiredDescription
rowsNoResult rows in query order, ending at a whole row where more would exceed the inline response size. Keys are the selected column names. When rows were left out, the notice says how many are shown and the LIMIT/OFFSET that reads the rest.
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance when the result was cut to fit the inline response size (rows shown, the LIMIT/OFFSET that continues, and when to stop), when a single row was too large to show, or when row_count stopped at the canvas row cap.
row_countNoRows the query produced, counted up to the canvas row cap — exact unless truncated is true, when it equals the cap and the result is larger.
truncatedNoTrue when the query produced more rows than the canvas row cap, so row_count stopped counting at the cap.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover readOnly/idempotent, and the description adds substantial extra behavior: SELECT-only enforcement (writes and file-reading functions rejected), JSON classification column handling with json_extract_string, absence of collection-only fields like lithology, and the oversized-result truncation behavior with an ORDER BY … LIMIT/OFFSET notice. This is rich, non-redundant behavioral disclosure.

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?

Front-loads the core action and use case, then unpacks column conventions and safety constraints. Dense but every sentence carries information; slightly longer than minimal but justified by the complexity of SQL-over-JSON behavior.

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?

With an output schema present, the description needn't explain returns; it instead covers the tricky parts an agent must know — table naming, JSON column extraction, missing fields, result truncation, and write rejection. Complete for a 2-param SQL tool.

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 100% and the schema documents both params, so baseline is 3. The description adds meaning beyond the schema by explaining what the canvas_id represents (staged result from a spill) and giving concrete SQL patterns/columns. Good added value.

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?

States a specific verb (run SELECT) against a specific resource (occurrence result sets staged on a DataCanvas), and names the producing sibling tool paleobiology_search_occurrences. Clearly distinguishable from siblings like dataframe_describe or get_diversity.

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?

Explicitly directs the agent to call paleobiology_dataframe_describe first if unknown table/column names, and explains the analysis-without-refetch use case. Full when-to-use guidance with sibling routing.

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

paleobiology_get_diversitypaleobiology-mcp-server: diversity through timeA
Read-onlyIdempotent
Inspect

Compute a diversity / origination / extinction curve for a clade across geologic time, binned by period, epoch, or age — answers "plot dinosaur genus diversity across the Mesozoic." Pass a clade-inclusive base_name (or base_id, the same clade by resolved taxon id — exactly one of the two) and bound the span by a named interval (e.g. "Mesozoic") or a max_ma/min_ma range; choose what to count (genera, species, or families) and the bin resolution. The full bin set returns inline — a diversity series is a bounded set of geologic intervals — so you read the curve, the turnover, and the per-bin origination/extinction directly. Counts reflect SAMPLED diversity, biased by collection effort and rock availability, not true past diversity.

NameRequiredDescriptionDefault
countNoWhat to count per bin: "genera" (default), "species", or "families".genera
max_maNoOlder bound of the span 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 span.
min_maNoYounger bound of the span 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 span.
base_idNoClade-inclusive taxon to count, by PBDB taxon id — the taxon_no from paleobiology_get_taxon, or accepted_no on an occurrence row. Same semantics as base_name, but unambiguous where a name is not (homonyms, synonyms, unresolved spellings). Supply this or base_name (exactly one is required, never both).
intervalNoNamed geologic interval bounding the span, e.g. "Mesozoic". Alternative to max_ma/min_ma.
base_nameNoClade-inclusive taxon to count, e.g. "Dinosauria" or "Ammonoidea" — this taxon and all descendants. Supply this or base_id (exactly one is required, never both).
resolutionNoBin resolution: "period" (default, coarse), "epoch", or "age" (finest).period

Output Schema

NameRequiredDescription
binsNoPer-interval diversity bins over the span, ordered oldest-first (oldest geologic interval, highest max_ma, first).
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance when the clade or span produced no bins, or when the taxon name could not be resolved and was ignored.
totalCountNoNumber of geologic-interval bins returned.
attributionNoCC-BY data attribution for the Paleobiology Database.

TDQS

A4.1/5.0
Behavior4/5

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

Annotations cover read-only and idempotency. The description adds important behavioral context: the full bin set returns inline (bounded set of geologic intervals), and critically, that counts reflect sampled diversity biased by collection effort and rock availability, not true diversity. Missing details on error handling (e.g., invalid interval) or exact auth requirements.

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?

Three sentences, front-loaded with the core operation and example, then key behavioral caveats. No filler, but slightly dense; could be more scannable with bullet points.

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?

For a read-only analytical tool with full schema and output schema present, the description covers purpose, parameter semantics, return behavior, and data interpretation caveats. Minor gaps: no mention of response size limits or pagination (though inline returns are stated), and no explicit error conditions.

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 100%, so the schema already fully documents all seven parameters. The description reiterates the same semantics (base_name/base_id, interval/max_ma/min_ma, count, resolution) without adding format syntax or edge-case constraints beyond what the schema provides. Baseline 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?

States a specific verb+resource ('Compute a diversity / origination / extinction curve for a clade across geologic time') and includes a concrete example query. Clearly distinct from siblings like get_taxon or search_occurrences.

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

Usage Guidelines4/5

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

Explains the tool's purpose and how to specify span (named interval or max_ma/min_ma) with the 'plot dinosaur genus diversity' example. Does not explicitly name alternative tools, but usage context is clear enough for an agent to select it.

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

paleobiology_get_referencespaleobiology-mcp-server: get bibliographic referencesA
Read-onlyIdempotent
Inspect

Resolve PBDB reference_no values — the source publication on every paleobiology_search_occurrences and paleobiology_search_collections row — to full citations with authors, year, title, publication, volume, pages, and DOI. Pass the ids from a page of rows in one call: the first 25 distinct ids are resolved and any beyond that come back in remaining_reference_nos for a follow-up call. Ids PBDB has no reference for are listed in not_found. Results keep the order the ids were given.

NameRequiredDescriptionDefault
reference_nosYesPBDB reference ids to resolve, from the reference_no field of paleobiology_search_occurrences or paleobiology_search_collections rows. Repeats are resolved once. Up to 500 accepted; the first 25 distinct ids are resolved per call.

Output Schema

NameRequiredDescription
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance when some ids had no PBDB reference, or when more ids remain than one call resolves.
not_foundNoRequested ids PBDB has no reference for. Empty when every id resolved.
referencesNoThe references PBDB has, in the order their ids were given.
attributionNoCC-BY data attribution for the Paleobiology Database.
remaining_reference_nosNoDistinct ids past the first 25, not resolved by this call — pass them as reference_nos to resolve the rest. Present only when the input held more than 25 distinct ids.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so safety and idempotency are covered. The description adds genuinely non-obvious behavior beyond that: a 25-distinct-id resolution cap per call, the remaining_reference_nos overflow channel, the not_found bucket for unresolvable ids, and order preservation of results.

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?

Three dense sentences, front-loaded with the core purpose before the batching caveat and the not_found/ordering notes. No filler and no repetition of the title.

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 single-parameter read tool with an output schema and full annotation coverage, the description supplies everything an agent needs: what it resolves, what to feed it, the per-call limit, and how to interpret overflow and misses.

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 100% and the parameter's description already states the source field, repeat handling, the 500 accepted cap, and the 25-distinct resolution limit. The description largely restates those same facts rather than adding syntax or format meaning, so the baseline 3 applies.

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?

States a specific verb (Resolve) and resource (PBDB reference_no values) and names the exact output (full citations with authors, year, title, publication, volume, pages, DOI). It also anchors the resource to sibling outputs — reference_no on paleobiology_search_occurrences and paleobiology_search_collections rows — so an agent can tell it apart from every other tool in the set.

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

Usage Guidelines4/5

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

Gives clear operating context: pass the ids from a page of rows in one call, and handle overflow via remaining_reference_nos in a follow-up call. It does not explicitly name a when-not condition or an alternative tool, but no sibling performs reference resolution, so the routing guidance is effectively complete.

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

paleobiology_get_taxonpaleobiology-mcp-server: get taxon record and fossil rangeA
Read-onlyIdempotent
Inspect

Resolve a taxon by name (e.g. "Tyrannosaurus") or by integer taxon_no to its accepted name, rank, higher classification, immediate parent, fossil occurrence count, and first/last appearance (FAD/LAD) range in millions of years — "when did this clade exist, and what is it." Run this first to resolve a name into the accepted name and taxon_no, then pass that id as base_id to paleobiology_search_occurrences, paleobiology_get_diversity, or paleobiology_search_collections for a clade-inclusive filter that carries no name ambiguity (the same id also appears as accepted_no on occurrence rows). Set show_children to also list immediate child taxa. PBDB taxonomy is opinionated and can differ from GBIF's backbone, so the accepted name may differ from the name you searched.

NameRequiredDescriptionDefault
nameNoTaxon name to resolve, e.g. "Tyrannosaurus" or "Ammonoidea". Provide this or taxon_no.
taxon_noNoPBDB taxon id from a prior get_taxon, or accepted_no on an occurrence row. Provide this or name, never both.
show_childrenNoWhen true, include a page of the immediate child taxa of this taxon (at most 200 per call — children_truncated says whether more remain).
children_offsetNoNumber of immediate children to skip before the returned page — used only when show_children is true. Advance it by 200 while children_truncated is true to walk the whole child list.

Output Schema

NameRequiredDescription
rankNoTaxonomic rank, e.g. "genus", "family", "order".
errorNoPresent when the call failed. Absent on success.
extantNoTrue if the clade survives to the present day; false if entirely extinct.
noticeNoGuidance when the child list was cut off at the per-page cap (naming the children_offset that reaches the next page), or when children_offset ran past the end of the child list.
childrenNoOne page of immediate child taxa, at most 200 — present only when show_children was true. A taxon with more children than that returns a page, not the full list; read children_truncated before treating it as complete.
taxon_noNoAccepted PBDB taxon id — the canonical id for this taxon. Pass it as base_id to paleobiology_search_occurrences, paleobiology_get_diversity, or paleobiology_search_collections to filter on this clade without re-sending a name.
parent_noNoPBDB taxon id of the immediate parent, when known.
attributionNoCC-BY data attribution for the Paleobiology Database.
parent_nameNoName of the immediate parent taxon, when known.
accepted_nameNoPBDB accepted name (may differ from the searched name).
classificationNoHigher classification of the taxon. Each level is present only when PBDB resolves it.
children_offsetNoPosition in the child list this page started at (0 is the first child). Present only when show_children was true.
last_appearanceNoA first- or last-appearance window. Empty when PBDB has no dated occurrences.
first_appearanceNoA first- or last-appearance window. Empty when PBDB has no dated occurrences.
occurrence_countNoNumber of fossil occurrences recorded in PBDB, when reported.
children_truncatedNoTrue when more immediate children remain past this page — re-call with children_offset advanced by 200 to read the next. False means this page runs to the end of the child list. Present only when show_children was true.

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/openWorld, so the description wisely focuses on what annotations cannot express: the PBDB-vs-GBIF backbone divergence and the caveat that accepted names may differ from the searched name. It also discloses that show_children paginates. Missing only explicit notes on auth/rate limits or error behavior for a nonexistent name.

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?

Front-loads the purpose with a quoted example, then the workflow guidance. Some density in the parenthetical FAD/LAD gloss is justified, but the sentence stack is long and could be slightly tighter.

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?

With a 4-param read-only lookup that has a full output schema and complete schema coverage, the description supplies the missing conceptual layer—when to run it, what the id is for, and the taxonomic-backbone caveat—so an agent can act correctly without further information.

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 100%, so baseline is 3; the description adds real value by explaining the show_children intent and the base_id reuse pattern, tying taxon_no to occurrence-row accepted_no. It does not re-explain the exclusive or-taxon_no/name constraint that the schema already enforces, which is fine.

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?

Names a specific verb (resolve) and resource (taxon), and enumerates exactly what is returned: accepted name, rank, classification, parent, occurrence count, FAD/LAD. It is clearly distinguishable from the sibling search/diversity/collection tools.

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?

Explicitly says 'Run this first' to resolve a name into accepted name + taxon_no, then names three specific siblings to pass base_id to, including the idempotent nature of the filter and its ambiguity-free benefit. Exclusions and sequencing are fully specified.

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

paleobiology_list_intervalspaleobiology-mcp-server: list geologic intervalsA
Read-onlyIdempotent
Inspect

Look up the geologic time scale — eons, eras, periods, epochs, and ages with their absolute-age boundaries in millions of years (Ma) and nesting. This is the reference that grounds every temporal filter on the other tools and translates a named interval like "Late Cretaceous" to its 100.5–66.0 Ma boundaries (and back). Filter by a name substring, a Ma range (overlap match), and/or a level; call with no filters to browse the full scale. Browsing and every name on the bundled ICS international-scale snapshot are answered offline. A name the snapshot does not carry — the sub-stage and regional names that occurrence and collection rows report, such as "Late Maastrichtian" or "Lancian" — costs one PBDB lookup across its other time scales; the response names which source answered and which scale the interval belongs to.

NameRequiredDescriptionDefault
nameNoCase-insensitive substring of the interval name, e.g. "cretaceous" or "Jurassic". A name the bundled international scale does not carry is matched exactly against PBDB's other time scales.
levelNoRestrict to one rank of the international scale: eon, era, period, epoch, or age (finest). Browsing is bounded to that scale, so the sub-stage and regional ranks are not selectable here.
max_maNoOlder bound of an age window (Ma); intervals overlapping [min_ma, max_ma] match. When paired with min_ma it must be greater than or equal to it — equal bounds name a single point in time.
min_maNoYounger bound of an age window (Ma); intervals overlapping [min_ma, max_ma] match.

Output Schema

NameRequiredDescription
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance when no interval matched the filters.
sourceNoWhich source answered: "bundled_ics" for the offline international-scale snapshot, "pbdb_upstream" for a name resolved live against PBDB's other time scales.
intervalsNoMatching geologic intervals, sorted oldest-first.
totalCountNoNumber of intervals matched by the filters.
snapshot_versionNoICS chart version and generation date of the bundled time scale, for citation.

TDQS

A4.5/5.0
Behavior5/5

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

Annotations cover only safety/idempotency; the description adds substantial behavioral context beyond them: bundled ICS snapshot names are answered offline, non-snapshot names cost one PBDB lookup across other time scales, and the response discloses which source answered and which scale the interval belongs to. This is exactly the kind of provenance/latency detail annotations cannot carry.

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?

Purpose and routing are front-loaded in the first two sentences, and the offline-vs-PBDB caveat follows logically. It runs long and repeats some schema phrasing about sub-stage/regional names, but nearly every clause carries usable information.

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?

With an output schema present, return-shape explanation isn't required, and the description covers filters, offline/lookup behavior, and source provenance. It omits result ordering and whether a full-scale browse is paginated, which would matter for the 'no filters' case.

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 100%, so the baseline is 3, but the description adds genuine meaning: Ma filters are overlap matches over [min_ma, max_ma], equal bounds denote a single point in time, and the level enum is bounded to the international scale so sub-stage/regional ranks are not selectable. Minor redundancy with schema text keeps it from a 5.

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?

States a specific verb and resource (look up the geologic time scale: eons through ages with Ma boundaries and nesting) and its role as the reference grounding temporal filters on other tools. It is clearly distinct from the sibling search/diversity/reference tools.

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

Usage Guidelines4/5

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

Explicitly describes the three filter modes (name substring, Ma overlap range, level) and that calling with no filters browses the full scale, plus the fallback behavior for names not in the snapshot. It doesn't name sibling tools or exclusions, but no alternative is really needed here since the lookup routing is handled internally.

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

paleobiology_search_collectionspaleobiology-mcp-server: search fossil collectionsA
Read-onlyIdempotent
Inspect

Find fossil collections (localities) by area and geologic time — "what has been dug up here, and from what rock." Each locality returns its location, age (named interval and Ma), formation and strata, lithology, depositional environment, and the count of co-occurring fossils. Filter by a clade-inclusive base_name (or base_id, the same clade by resolved taxon id), a named interval or max_ma/min_ma range, a lng/lat bounding box, a formation or lithology name, and/or an environment. Results page inline via limit/offset (the response discloses when more remain). Take a collection_no from a row and pass it — or the same bbox+interval — to paleobiology_search_occurrences to see the actual fauna found together.

NameRequiredDescriptionDefault
limitNoMaximum localities to return per page. Up to 500 are pulled per call; a larger value is served at 500, and the paging notice names that cap when more matches remain. A page can show fewer rows than it pulled when more would exceed the inline response size — the notice then names the offset that continues.
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. 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. When paired with max_ma it must be strictly smaller — min_ma is the nearer-to-present end of the window.
offsetNoNumber of localities to skip — page with limit by advancing offset.
base_idNoClade-inclusive taxon filter by PBDB taxon id — the taxon_no from paleobiology_get_taxon, or accepted_no on an occurrence row. Same 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. "Maastrichtian". Alternative to max_ma/min_ma.
base_nameNoClade-inclusive taxon filter — localities yielding this taxon or its descendants, e.g. "Dinosauria". Supply this or base_id, never both.
formationNoGeologic formation name to filter by, e.g. "Hell Creek".
lithologyNoLithology (rock type) to filter by, e.g. "sandstone".
environmentNoDepositional environment: "marine", "terrestrial", or "freshwater" (lacustrine + fluvial). Omit for all.

Output Schema

NameRequiredDescription
capNoThe per-page limit that was applied (set when truncated).
errorNoPresent when the call failed. Absent on success.
shownNoNumber of localities returned in this page (set when truncated).
noticeNoGuidance when no locality matched, when localities remain past this page or it was cut to fit the inline response size (naming the offset that reaches the next one), when offset ran past the end of the match set, or when a filter value was not recognized and ignored.
truncatedNoTrue when localities remain past this page — advance offset for more.
totalCountNoTotal localities matching the filters upstream, across all pages.
attributionNoCC-BY data attribution for the Paleobiology Database.
collectionsNoMatching localities for this page.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, openWorld), and the description adds real behavioral context beyond them: the 500-row pull cap, that pages can show fewer rows than pulled when the inline response size would be exceeded, and that the paging notice names the continuing offset. That pagination/truncation behavior is not derivable from the annotations.

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?

Dense but front-loaded: what it finds, then returned fields, then filters, then paging, then the handoff to the sibling tool. For a 14-parameter tool the length is justified, though the em-dash-laden prose could be trimmed slightly.

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?

With an output schema present and annotations carrying the safety profile, the description needn't explain return shape — yet it still covers filtering, paging caps, and cross-tool routing. Nothing an agent needs to call this correctly is missing.

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 100%, so the baseline is 3. The description goes slightly beyond by grouping the filters (base_name vs base_id as "the same clade by resolved taxon id", named interval vs max_ma/min_ma, bbox lng/lat, formation, lithology, environment) and clarifying the taxon-filter alternatives, though most per-parameter detail still lives in the schema.

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?

States a specific verb and resource ("Find fossil collections (localities)") and immediately anchors it with the framing "what has been dug up here, and from what rock." It enumerates returned fields and names the sibling (paleobiology_search_occurrences) it is distinct from, so an agent can separate the two without opening schemas.

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?

Explicitly routes the agent: "Take a collection_no from a row and pass it — or the same bbox+interval — to paleobiology_search_occurrences to see the actual fauna found together." It names the alternative tool and the exact condition/inputs that select it, leaving nothing to inference.

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

paleobiology_search_occurrencespaleobiology-mcp-server: search fossil occurrencesA
Read-onlyIdempotent
Inspect

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. When this deployment has DataCanvas enabled, a set that outgrows the inline preview stages on a canvas (canvas_id + table_name, returned only then): list its columns with paleobiology_dataframe_describe, then run SQL with 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.

NameRequiredDescriptionDefault
limitNoMaximum occurrences to pull per page. Up to 500 are pulled per call; a larger value is served at 500, and the paging notice names that cap when more matches remain. A page can show fewer rows than it pulled when more would exceed the inline response size — the notice then names the offset that continues. 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. Used only when this page spills: reusing it REPLACES (overwrites) the prior occurrence table — each search restages the full result, it does not append to or accumulate across earlier ones — while a page that fits inline leaves that canvas untouched. Omit to start fresh; a spilled 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

NameRequiredDescription
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 a page cut to the inline response size could not be staged because this deployment has no DataCanvas.
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 it to paleobiology_dataframe_describe for the table and column names, then to paleobiology_dataframe_query to run SQL against them. 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 number of occurrences shown inline. At most 500 per call — compare against the totalCount enrichment for how many matched upstream.
table_nameNoCanvas table holding the staged occurrence set — the FROM target in paleobiology_dataframe_query SQL, and the table paleobiology_dataframe_describe reports columns for. 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, ending at a whole row where more would exceed the inline response size. 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

A4.8/5.0
Behavior5/5

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

Annotations already carry readOnly/openWorld/idempotent, yet the description adds genuinely new behavior: the at-least-one-filter constraint, paging via limit/offset, the dual modern-vs-paleo coordinate systems with a warning against plotting deep-time occurrences on modern coastlines, and the canvas overwrite semantics (each search restages, does not append). These are concrete traits not derivable from annotations.

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?

Front-loaded with purpose and highly information-dense, but the single long paragraph duplicates some schema content (paging mechanics are explained in both the description and the limit/offset descriptions). Nearly every sentence earns its place, though a little tightening would help.

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, zero-required filter tool with an output schema, the description covers the required-filter rule, filter-vs-filter alternatives, pagination, return-set staging, and coordinate interpretation. Nothing an agent needs to invoke it correctly appears to be missing.

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 description coverage is 100%, so the baseline would be 3, but the description adds decision-level meaning: which of the three taxon filters to pick, the age-window alternative (named interval vs numeric bounds), and where to source collection_no. It largely restates fields the schema already documents in detail, which caps it below 5.

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?

States a specific verb (search) and resource (fossil occurrences) with the filter dimensions (taxon, time, geography, depositional environment) front-loaded. It self-identifies as "the flagship" and clearly occupies a different niche than sibling paleobiology_search_collections.

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?

Explicitly resolves the ambiguous cases: base_name vs base_id vs taxon_name (with the "what 'Tyrannosaurus occurrences' usually means" framing), interval vs max_ma/min_ma, and points to paleobiology_get_taxon to resolve names and paleobiology_search_collections to source collection_no. It also states the hard requirement that at least one filter is needed and routes oversized results to the dataframe siblings.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 7 tool updates
    • Changedpaleobiology_dataframe_query5 fields changed
      • changedInput schema / properties / sql / description
        Previous value: -"A read-only SQL SELECT. Reference tables by the names paleobiology_search_occurrences / _describe returned."New value: +"A read-only SQL SELECT. Reference tables by the names paleobiology_search_occurrences / paleobiology_dataframe_describe returned."
      • addedOutput schema / properties / notice
        Added value: +{
+  "description": "Guidance when the result was cut to fit the inline response size (rows shown, the LIMIT/OFFSET that continues, and when to stop), when a single row was too large to show, or when row_count stopped at the canvas row cap.",
+  "type": "string"
+}
      • changedOutput schema / properties / row_count / description
        Previous value: -"Number of rows in the full result before any row cap."New value: +"Rows the query produced, counted up to the canvas row cap — exact unless truncated is true, when it equals the cap and the result is larger."
      • changedOutput schema / properties / rows / description
        Previous value: -"Result rows (capped at the canvas row limit). Keys are the selected column names."New value: +"Result rows in query order, ending at a whole row where more would exceed the inline response size. Keys are the selected column names. When rows were left out, the notice says how many are shown and the LIMIT/OFFSET that reads the rest."
      • changedOutput schema / properties / truncated / description
        Previous value: -"True when the result exceeded the canvas row cap and rows were trimmed."New value: +"True when the query produced more rows than the canvas row cap, so row_count stopped counting at the cap."
    • Changedpaleobiology_get_diversity2 fields changed
      • changedOutput schema / properties / error / properties / data / properties / reason / description
        Previous value: -"Machine-readable failure mode. Declared by this tool: `missing_filter`: Neither base_name nor base_id was supplied — a diversity curve needs a clade to count. `conflicting_taxon_filter`: Both base_name and base_id were supplied — PBDB accepts only one clade selector. `inverted_ma_range`: min_ma was greater than or equal to max_ma — the span is inverted or empty. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `missing_filter`: Neither base_name nor base_id was supplied — a diversity curve needs a clade to count. `conflicting_taxon_filter`: Both base_name and base_id were supplied — PBDB accepts only one clade selector. `inverted_ma_range`: min_ma was greater than or equal to max_ma — the span is inverted or empty. `pbdb_invalid_parameter`: PBDB refused a filter value it could not use, such as an unknown interval name — the message quotes its reason. Other values are possible when a failure originates below the handler."
      • changedOutput schema / properties / error / properties / data / properties / reason / examples
        Previous value: -[
-  "missing_filter",
-  "conflicting_taxon_filter",
-  "inverted_ma_range"
-]New value: +[
+  "missing_filter",
+  "conflicting_taxon_filter",
+  "inverted_ma_range",
+  "pbdb_invalid_parameter"
+]
    • Addedpaleobiology_get_references
    • Changedpaleobiology_get_taxon3 fields changed
      • changedInput schema / properties / taxon_no / description
        Previous value: -"PBDB taxon id from a prior get_taxon, or accepted_no on an occurrence row. Provide this or name."New value: +"PBDB taxon id from a prior get_taxon, or accepted_no on an occurrence row. Provide this or name, never both."
      • changedOutput schema / properties / error / properties / data / properties / reason / description
        Previous value: -"Machine-readable failure mode. Declared by this tool: `taxon_not_found`: The name or taxon_no resolved to no PBDB taxon. `missing_selector`: Neither name nor taxon_no was provided. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `taxon_not_found`: The name or taxon_no resolved to no PBDB taxon. `missing_selector`: Neither name nor taxon_no was provided. `conflicting_selector`: Both name and taxon_no were provided — the lookup takes exactly one selector. Other values are possible when a failure originates below the handler."
      • changedOutput schema / properties / error / properties / data / properties / reason / examples
        Previous value: -[
-  "taxon_not_found",
-  "missing_selector"
-]New value: +[
+  "taxon_not_found",
+  "missing_selector",
+  "conflicting_selector"
+]
    • Changedpaleobiology_list_intervals3 fields changed
      • changedInput schema / properties / max_ma / description
        Previous value: -"Older bound of an age window (Ma); intervals overlapping [min_ma, max_ma] match."New value: +"Older bound of an age window (Ma); intervals overlapping [min_ma, max_ma] match. When paired with min_ma it must be greater than or equal to it — equal bounds name a single point in time."
      • changedOutput schema / properties / error / properties / data / properties / reason / description
        Previous value: -"Machine-readable failure mode. Declared by this tool: `interval_not_found`: A named interval filter matched nothing — neither the bundled international scale (after any level or Ma filters) nor a PBDB lookup across its other time scales. `interval_lookup_unavailable`: The name is outside the bundled international scale and the PBDB lookup that covers the other time scales could not be reached. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `interval_not_found`: A named interval filter matched nothing — neither the bundled international scale (after any level or Ma filters) nor a PBDB lookup across its other time scales. `interval_lookup_unavailable`: The name is outside the bundled international scale and the PBDB lookup that covers the other time scales could not be reached. `inverted_ma_range`: max_ma was smaller than min_ma — the age window is inverted. Other values are possible when a failure originates below the handler."
      • changedOutput schema / properties / error / properties / data / properties / reason / examples
        Previous value: -[
-  "interval_not_found",
-  "interval_lookup_unavailable"
-]New value: +[
+  "interval_not_found",
+  "interval_lookup_unavailable",
+  "inverted_ma_range"
+]
    • Changedpaleobiology_search_collections6 fields changed
      • changedInput schema / properties / limit / description
        Previous value: -"Maximum localities to return per page (1–500)."New value: +"Maximum localities to return per page. Up to 500 are pulled per call; a larger value is served at 500, and the paging notice names that cap when more matches remain. A page can show fewer rows than it pulled when more would exceed the inline response size — the notice then names the offset that continues."
      • changedInput schema / properties / limit / maximum
        Previous value: -500New value: +10000
      • changedOutput schema / properties / collections / items / properties / reference_no / description
        Previous value: -"PBDB bibliographic reference id for provenance."New value: +"PBDB bibliographic reference id — the publication this collection was entered from. Resolve it to a full citation with paleobiology_get_references."
      • changedOutput schema / properties / error / properties / data / properties / reason / description
        Previous value: -"Machine-readable failure mode. Declared by this tool: `missing_filter`: The call carried only pagination fields — no taxon, time, place, formation, lithology, or environment filter. `conflicting_taxon_filter`: Both base_name and base_id were supplied — PBDB accepts only one clade selector. `incomplete_bbox`: Exactly one of lngmin/lngmax was supplied — a longitude box needs both edges. `inverted_ma_range`: min_ma was greater than or equal to max_ma — the age window is inverted or empty. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `missing_filter`: The call carried only pagination fields — no taxon, time, place, formation, lithology, or environment filter. `conflicting_taxon_filter`: Both base_name and base_id were supplied — PBDB accepts only one clade selector. `incomplete_bbox`: Exactly one of lngmin/lngmax was supplied — a longitude box needs both edges. `inverted_ma_range`: min_ma was greater than or equal to max_ma — the age window is inverted or empty. `pbdb_invalid_parameter`: PBDB refused a filter value it could not use, such as an unknown interval or lithology name — the message quotes its reason. Other values are possible when a failure originates below the handler."
      • changedOutput schema / properties / error / properties / data / properties / reason / examples
        Previous value: -[
-  "missing_filter",
-  "conflicting_taxon_filter",
-  "incomplete_bbox",
-  "inverted_ma_range"
-]New value: +[
+  "missing_filter",
+  "conflicting_taxon_filter",
+  "incomplete_bbox",
+  "inverted_ma_range",
+  "pbdb_invalid_parameter"
+]
      • changedOutput schema / properties / notice / description
        Previous value: -"Guidance when no locality matched, when localities remain past this page, or when a filter value was not recognized and ignored."New value: +"Guidance when no locality matched, when localities remain past this page or it was cut to fit the inline response size (naming the offset that reaches the next one), when offset ran past the end of the match set, or when a filter value was not recognized and ignored."
    • Changedpaleobiology_search_occurrences11 fields changed
      • changedInput schema / properties / canvas_id / description
        Previous value: -"Canvas 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."New value: +"Canvas id from a prior call to re-stage onto the same workspace. Used only when this page spills: reusing it REPLACES (overwrites) the prior occurrence table — each search restages the full result, it does not append to or accumulate across earlier ones — while a page that fits inline leaves that canvas untouched. Omit to start fresh; a spilled response returns a new id."
      • changedInput schema / properties / limit / description
        Previous value: -"Maximum 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."New value: +"Maximum occurrences to pull per page. Up to 500 are pulled per call; a larger value is served at 500, and the paging notice names that cap when more matches remain. A page can show fewer rows than it pulled when more would exceed the inline response size — the notice then names the offset that continues. Pair with offset to walk the whole match set."
      • changedInput schema / properties / limit / maximum
        Previous value: -500New value: +10000
      • changedOutput schema / properties / canvas_id / description
        Previous value: -"Canvas 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."New value: +"Canvas id holding the staged occurrence set — pass it to paleobiology_dataframe_describe for the table and column names, then to paleobiology_dataframe_query to run SQL against them. Present only when spilled is true; a result that fit inline stages nothing, so there is no table to query."
      • changedOutput schema / properties / error / properties / data / properties / reason / description
        Previous value: -"Machine-readable failure mode. Declared by this tool: `missing_filter`: The call carried only pagination fields — no taxon, time, place, environment, or collection filter. `conflicting_taxon_filter`: Both base_name and base_id were supplied — PBDB accepts only one clade selector. `incomplete_bbox`: Exactly one of lngmin/lngmax was supplied — a longitude box needs both edges. `inverted_ma_range`: min_ma was greater than or equal to max_ma — the age window is inverted or empty. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `missing_filter`: The call carried only pagination fields — no taxon, time, place, environment, or collection filter. `conflicting_taxon_filter`: Both base_name and base_id were supplied — PBDB accepts only one clade selector. `incomplete_bbox`: Exactly one of lngmin/lngmax was supplied — a longitude box needs both edges. `inverted_ma_range`: min_ma was greater than or equal to max_ma — the age window is inverted or empty. `pbdb_invalid_parameter`: PBDB refused a filter value it could not use, such as an unknown interval name — the message quotes its reason. `canvas_capacity_exhausted`: The page outgrew the inline response size and no canvas_id was passed, but every canvas slot open to this caller is already taken. Other values are possible when a failure originates below the handler."
      • changedOutput schema / properties / error / properties / data / properties / reason / examples
        Previous value: -[
-  "missing_filter",
-  "conflicting_taxon_filter",
-  "incomplete_bbox",
-  "inverted_ma_range"
-]New value: +[
+  "missing_filter",
+  "conflicting_taxon_filter",
+  "incomplete_bbox",
+  "inverted_ma_range",
+  "pbdb_invalid_parameter",
+  "canvas_capacity_exhausted"
+]
      • changedOutput schema / properties / notice / description
        Previous value: -"Guidance 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."New value: +"Guidance 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 a page cut to the inline response size could not be staged because this deployment has no DataCanvas."
      • changedOutput schema / properties / occurrences / description
        Previous value: -"Inline 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)."New value: +"Inline preview of matching occurrences for the requested page, ending at a whole row where more would exceed the inline response size. 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)."
      • changedOutput schema / properties / occurrences / items / properties / reference_no / description
        Previous value: -"PBDB bibliographic reference id for provenance."New value: +"PBDB bibliographic reference id — the publication this occurrence was entered from. Resolve it to a full citation with paleobiology_get_references."
      • changedOutput schema / properties / row_count / description
        Previous value: -"Rows 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."New value: +"Rows staged on the canvas when spilled; otherwise the number of occurrences shown inline. At most 500 per call — compare against the totalCount enrichment for how many matched upstream."
      • changedOutput schema / properties / table_name / description
        Previous value: -"Canvas table holding the staged occurrence set. Present only when spilled is true."New value: +"Canvas table holding the staged occurrence set — the FROM target in paleobiology_dataframe_query SQL, and the table paleobiology_dataframe_describe reports columns for. Present only when spilled is true."
  2. 3 tool updates
    • Changedpaleobiology_dataframe_describe1 field changed
      • addedInput schema / properties / canvas_id / pattern
        Added value: +"^[A-Za-z0-9_-]{10}$"
    • Changedpaleobiology_dataframe_query1 field changed
      • addedInput schema / properties / canvas_id / pattern
        Added value: +"^[A-Za-z0-9_-]{10}$"
    • Changedpaleobiology_search_occurrences1 field changed
      • addedInput schema / properties / canvas_id / pattern
        Added value: +"^[A-Za-z0-9_-]{10}$"
  3. 7 tool updates
    • First observedpaleobiology_dataframe_describe
    • First observedpaleobiology_dataframe_query
    • First observedpaleobiology_get_diversity
    • First observedpaleobiology_get_taxon
    • First observedpaleobiology_list_intervals
    • First observedpaleobiology_search_collections
    • First observedpaleobiology_search_occurrences

Related MCP Connectors

Related MCP Servers

  • gbif-mcp

    tyson-swetnam
    A
    license
    B
    quality
    B
    maintenance
    Enables AI assistants to query and retrieve biodiversity data from the Global Biodiversity Information Facility (GBIF), including species, occurrences, datasets, and literature.
    58
    51 npm
    MIT

  • lacewing-digital-library

    Gyoungwe
    A
    license
    B
    quality
    B
    maintenance
    Enables researchers to query and reconcile taxonomic data from the Lacewing Digital Library and Neuropterida Species of the World, including accepted names, type localities, distributions, references, and phylogeny records.
    21
    MIT
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.

Resources