Skip to main content
Glama

datacite-mcp-server

by io.github.cyanheads
OverviewDiscussionsAdmin

Trace DataCite relations

datacite_trace_relations
Read-onlyIdempotent

Map the relation graph around one DOI — versions, parts, supplements, derivations, documentation, citations, references, and every other DataCite relation type — as nodes and directed edges that keep the relationType exactly as asserted and name each edge's source: the DOI's own metadata, other DataCite records that point at it, or DataCite Event Data (citation links harvested from Crossref and other sources). Accepts any DOI, including a journal article's DOI, to find the datasets and software it cites and those that cite, supplement, or derive from it. DataCite DOIs are hydrated with title, type, year, repository, and citation count; other identifiers stay leaf nodes. Depth 1 by default, at most 2, with a node cap (default 50, max 100) disclosed when it binds. An absent edge is not evidence that no relationship exists.

Input Schema

NameRequiredDescriptionDefault
doiYesThe root DOI — any agency's, e.g. a DataCite dataset 10.5061/dryad.234 or a journal article's DOI. Bare, doi:, or a doi.org URL; case-insensitive.
depthNoHops from the root: 1 (default) or 2. Depth 2 expands at most 10 DataCite neighbours through their own and reverse metadata, and runs only while max_nodes has room after the first hop.
max_nodesNoRequested node cap including the root, 1–10,000 (default 50); values above 100 apply 100 with a notice. Filled in order: own-metadata targets, records pointing at the root, Event Data endpoints, then the second hop.
event_offsetNoAbsolute zero-based Event Data position, 0–9,999. Presence, including 0, selects Event-Data-only mode: no metadata edges or depth-2 expansion. Reads one 100-event upstream page, starting within it. Continue with coverage.eventData.nextEventOffset and the same doi and filters; ordering can change between calls, so this is not a snapshot.
relation_typesNoOnly these relation types (IsVersionOf, HasPart, IsSupplementTo, IsDerivedFrom, Cites, IsCitedBy, …), any case, read from the traced DOI's side: HasPart keeps the DOI's own HasPart assertions and the records asserting IsPartOf it, each edge shown as asserted. IsPublishedIn and Other have no inverse and match on either side. A second hop reads them from each expanded neighbour's side. Omitted: all. Groups: datacite_list_reference topic relation_types.
include_event_dataNoAdd Event Data citation links (mostly harvested from Crossref). Citation relation types only.

Output Schema

NameRequiredDescriptionDefault
capNoThe max_nodes applied.
rootNoThe root DOI. For another agency's DOI, title, type, and year come from DataCite's linking copy when it holds one.
edgesNoEdges between returned nodes, at most 1,000, the first found; identical edges from several sources are merged.
errorNoPresent when the call failed. Absent on success.
nodesNoNodes, root first.
shownNoNodes returned, root included.
noticeNoCoverage caveats: non-DataCite root, no relations found, Event Data unavailable, records pointing at a DOI too large to read 100 of, Event Data objects left out and nodes left unhydrated because DataCite did not answer in time, node cap, unexpanded second hop, neighbours past the second-hop limit, edge cap, uncounted citations.
coverageNoWhat each source contributed and how much of it was read.
truncatedNoTrue when max_nodes or the 1,000-edge cap bound.
edgesFoundNoEdges between the returned nodes before the 1,000-edge cap; present only when the cap bound.
rootCountsNoDataCite's own counts for the root (DataCite roots only), to compare with the edges shown.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed16 schema fields changed
    • addedInput schema / properties / event_offset
      Added value: +{
+  "description": "Absolute zero-based Event Data position, 0–9,999. Presence, including 0, selects Event-Data-only mode: no metadata edges or depth-2 expansion. Reads one 100-event upstream page, starting within it. Continue with coverage.eventData.nextEventOffset and the same doi and filters; ordering can change between calls, so this is not a snapshot.",
+  "maximum": 9999,
+  "minimum": 0,
+  "type": "integer"
+}
    • changedInput schema / properties / max_nodes / description
      Previous value: -"Node cap including the root, 1–100 (default 50). Filled in order: own-metadata targets, records pointing at the root, Event Data endpoints, then the second hop."New value: +"Requested node cap including the root, 1–10,000 (default 50); values above 100 apply 100 with a notice. Filled in order: own-metadata targets, records pointing at the root, Event Data endpoints, then the second hop."
    • changedInput schema / properties / max_nodes / maximum
      Previous value: -100New value: +10000
    • addedOutput schema / properties / coverage / properties / eventData / properties / hasNextPage
      Added value: +{
+  "description": "Whether the returned upstream links contain next; does not override totals or the ranked ceiling.",
+  "type": "boolean"
+}
    • changedOutput schema / properties / coverage / properties / eventData / properties / kept / description
      Previous value: -"Events kept as edges before max_nodes applies; for a non-DataCite root, only events whose object is a DataCite DOI are kept."New value: +"Default mode: qualifying events before max_nodes applies. Event-Data-only mode: raw events represented in returned edges, duplicates included. For a non-DataCite root, only confirmed DataCite objects are kept."
    • addedOutput schema / properties / coverage / properties / eventData / properties / nextEventOffset
      Added value: +{
+  "description": "Next raw event to examine with the same DOI and filters. A blocked position retries here; max_nodes=1 requires raising max_nodes first. Absent on exhaustion, a skipped/unavailable page, or the 10,000-result ceiling.",
+  "type": "number"
+}
    • addedOutput schema / properties / coverage / properties / eventData / properties / offset
      Added value: +{
+  "description": "Requested absolute raw-event offset, present in Event-Data-only mode.",
+  "type": "number"
+}
    • addedOutput schema / properties / coverage / properties / eventData / properties / page
      Added value: +{
+  "description": "Upstream page returned, or requested when upstream omits it.",
+  "type": "number"
+}
    • addedOutput schema / properties / coverage / properties / eventData / properties / progress
      Added value: +{
+  "description": "Continuation state: more raw events, exhausted matching results, the 10,000-ranked-result ceiling, or an uncertain endpoint lookup that must be retried.",
+  "enum": [
+    "more",
+    "exhausted",
+    "ceiling",
+    "blocked"
+  ],
+  "type": "string"
+}
    • addedOutput schema / properties / coverage / properties / eventData / properties / totalPages
      Added value: +{
+  "description": "Upstream total-pages when provided.",
+  "type": "number"
+}
    • changedOutput schema / properties / coverage / properties / ownMetadata / properties / status / description
      Previous value: -"not_datacite when DataCite holds no record for the root."New value: +"not_datacite when DataCite holds no record for the root; skipped in event_offset mode."
    • changedOutput schema / properties / coverage / properties / ownMetadata / properties / status / enum
      Previous value: -[
-  "ok",
-  "not_datacite"
-]New value: +[
+  "ok",
+  "not_datacite",
+  "skipped"
+]
    • removedOutput schema / properties / coverage / properties / reverseMetadata / properties / status / const
      Removed value: -"ok"
    • changedOutput schema / properties / coverage / properties / reverseMetadata / properties / status / description
      Previous value: -"Always ok: a reverse query that does not answer fails the whole call."New value: +"skipped in event_offset mode; otherwise a reverse query that does not answer fails the whole call."
    • addedOutput schema / properties / coverage / properties / reverseMetadata / properties / status / enum
      Added value: +[
+  "ok",
+  "skipped"
+]
    • changedOutput schema / properties / edges / items / properties / sources / description
      Previous value: -"How the edge was reached. metadata and reverse_metadata both read from's own relatedIdentifiers — metadata by reading that record, reverse_metadata by querying for records that point at to — so an edge listing both is one assertion reached twice, not two confirmations; event_data is a link harvested by Event Data, independent of either."New value: +"How the edge was reached. metadata and reverse_metadata both read from's own relatedIdentifiers and relatedItems — metadata by reading that record, reverse_metadata by querying for records that point at to — so an edge listing both is one assertion reached twice, not two confirmations; event_data is a link harvested by Event Data, independent of either."
  2. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Despite annotations already declaring readOnly/openWorld/idempotent, the description adds real behavioral context: depth cap of 2, node-cap default and ceiling with a notice when it binds, hydration rules for DataCite vs non-DataCite identifiers, single-page event reads with ordering that can change, and the caution that an absent edge is not evidence of no relationship. That is disclosure beyond the structured fields.

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 the core action and organized as purpose → DOI acceptance → hydration/caps → caveat. It is dense but not padded, though it re-states depth and node-cap defaults that the schema already carries and lists relation categories at unnecessary length in the opening sentence.

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 six-parameter, multi-mode graph tool with an output schema, the description covers the node/edge model, truncation disclosure, second-hop behavior, pagination continuation, and the key epistemics caveat. Nothing an agent needs to invoke it correctly is missing.

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%, so the schema already explains doi, depth, max_nodes, event_offset, relation_types and include_event_data in detail. The description largely restates the depth and node-cap defaults rather than adding syntax or semantics the schema lacks; 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 and resource — 'Map the relation graph around one DOI' — and enumerates the scope (versions, parts, supplements, derivations, citations, references). An agent can tell this multi-hop graph tool apart from singular-record siblings like datacite_get_work and datacite_get_citation without opening a schema.

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

Usage Guidelines3/5

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

Use cases are implied ('find the datasets and software it cites and those that cite, supplement, or derive from it') and the event-data-only mode trigger is explained, but no sibling is ever named as an alternative and no when-not-to-use condition is given. Usage must be inferred from the described behavior.

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

All datacite-mcp-server toolsInspect
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