datacite-mcp-server

Search DataCite repositories

datacite_search_repositories

Read-onlyIdempotent

Find DataCite repository accounts by name or description text, field of science, repository type, certification (e.g. CoreTrustSeal), software platform, client type, or parent provider, or look up known repository IDs. Returns each repository's repositoryId — the value datacite_search_works takes in repository_ids — with its providerId, name, type, certificates, software, subjects, homepage, and re3data link. To rank repositories by how many works they hold on a topic, run datacite_search_works with that topic and include_facets: true; its repositories facet lists the top ten with counts.

Input Schema

Name	Required	Description
`page`	No	Page number. Past the last page the list is empty.
`limit`	No	Requested repositories per page, 1–10,000; values above 100 apply 100 with a notice.
`query`	No	Text matched against repository names, alternate names, and descriptions. Query-string syntax is accepted.
`software`	No	Software platform slug, lowercased: dataverse, dspace, invenio, ckan, open_journal_systems_ojs, … (free-form upstream; see datacite_list_reference topic software_platforms).
`client_type`	No	Account type: repository, periodical, igsnCatalog, or raidRegistry. Omitted: all.
`provider_id`	No	Parent provider id, e.g. dryad — the providerId a repository carries. Any case.
`certificates`	No	Certificates (any match): CoreTrustSeal, WDS, DSA, DINI, RatSWD, CLARIN, DIN 31644; any case.
`repository_ids`	No	Known repository ids, shaped provider.repository (e.g. dryad.dryad); any case. Up to 1,000 inputs; queries the first 25 distinct normalized ids and names omitted ids. Use alone — an id lookup ignores query and filters.
`field_of_science`	No	An OECD Fields of Science id or label the repository lists among its subjects, e.g. earth_and_related_environmental_sciences. List: datacite_list_reference topic fields_of_science.
`repository_types`	No	Repository types (any match): institutional, disciplinary, multidisciplinary, project-related, governmental, other.

Output Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Guidance when nothing matched, the page is past the end, or a requested repository id matched no account.
`nextPage`	No	Next page number, when more repositories match.
`totalCount`	No	Total repositories matching.
`orderApplied`	No	Result order — always by name, as the registry returns it.
`repositories`	No	Repositories on this page, ordered by name.
`appliedFilters`	No	Every applied filter as sent upstream; {} when none.
`effectiveQuery`	No	The composed search query, or * for an unfiltered search; absent for repository_ids lookup.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 26, 2026

addedOutput schema / properties / effectiveQuery

Added value: +{
+  "description": "The composed search query, or * for an unfiltered search; absent for repository_ids lookup.",
+  "type": "string"
+}

Changed4 schema fields changedOct 18, 2026

changedInput schema / properties / limit / description

Previous value: -"Repositories per page, 1–100."New value: +"Requested repositories per page, 1–10,000; values above 100 apply 100 with a notice."

changedInput schema / properties / limit / maximum
```
Previous value: -100New value: +10000
```

changedInput schema / properties / repository_ids / description

Previous value: -"Known repository ids to look up in one batch, shaped provider.repository (e.g. dryad.dryad); any case. Use alone — an id lookup ignores query and filters."New value: +"Known repository ids, shaped provider.repository (e.g. dryad.dryad); any case. Up to 1,000 inputs; queries the first 25 distinct normalized ids and names omitted ids. Use alone — an id lookup ignores query and filters."

changedInput schema / properties / repository_ids / maxItems
```
Previous value: -25New value: +1000
```

First observedOct 9, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, open-world behavior, so the safety bar is low. The description adds the valuable cross-tool contract — the returned repositoryId is exactly the value datacite_search_works accepts in repository_ids — plus a summary of the payload fields. Pagination caps and the >100 limit behavior are left to the schema.

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?

Two sentences, front-loaded with the capabilities and ending with the routing tip. The second sentence is long but every clause — facet ranking, top ten, counts — carries actionable 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 and full annotation coverage, the description only needs to cover purpose, alternatives, and cross-tool wiring, all of which it does. Return-shape details are partially restated but the mode-switching caveats live in the schema rather than the prose.

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 parameters are thoroughly documented there, including the rule that ID lookup ignores query and filters. The description's filter list and ID-lookup mention largely mirror the schema, so it clears the baseline but adds little parameter-level meaning beyond it.

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 (find/look up) and resource (DataCite repository accounts) and enumerates the filter dimensions, so an agent immediately knows the surface. It is clearly distinct from datacite_search_works, whose repository_ids parameter it feeds the repositoryId into.

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

Usage Guidelines5/5

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

It names both modes (filter search vs. ID lookup) and gives an explicit alternative-with-condition: to rank repositories by work counts on a topic run datacite_search_works with include_facets: true and read the repositories facet. Nothing is left to inference about which sibling to call.

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 tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.