Skip to main content
Glama

orcid-mcp-server

by io.github.cyanheads

Search ORCID Researchers

orcid_search_researchers
Read-onlyIdempotent

Search the ORCID registry using structured field parameters or raw Solr syntax. All provided structured params are ANDed together. The query field appends raw Solr syntax to the generated clause. Returns ORCID iDs with inline name and institution data — no follow-up profile fetches needed for basic disambiguation. For ranked disambiguation of an ambiguous author name, use orcid_resolve_researcher instead. The ORCID Public API caps results at 10,000 — use pagination for large result sets.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
doiNoDOI to anchor the search. Returns researchers who have linked this DOI to their ORCID record.
pmidNoPubMed ID to anchor the search. Returns researchers who have linked this PMID to their ORCID record.
rowsNoMaximum results to return (1–1000).
queryNoRaw Solr query string appended to the generated clause with AND. Supports all ORCID Solr fields and boolean operators.
startNoPagination offset (0-based), 0–10,000. The ORCID Public API rejects start > 10,000 for unauthenticated requests.
ror_idNoROR organization ID to filter by (full URL, e.g. https://ror.org/00f54p054). Returns researchers affiliated with this organization.
keywordNoKeyword to search in the researcher's keyword fields. Phrase match.
given_nameNoResearcher's given (first) name.
affiliationNoOrganization name to filter by. Phrase match.
family_nameNoResearcher's family (last) name.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsNoNumber of results returned in this response.
errorNoPresent when the call failed. Absent on success.
startNoPagination offset used for this response.
noticeNoRecovery hint when results are empty, pagination overshoots the total, or matches exceed the 10,000-offset ceiling. Absent on fully retrievable pages.
resultsNoMatching researchers with inline name and institution data.
numFoundNoTotal number of matching records in ORCID (before pagination).
nextStartNoOffset to pass as start on the next call to continue paging. Present only when more matches remain below the ORCID Public API 10,000-offset ceiling; omitted at the final reachable page and when this response already includes the last match.
truncatedNoTrue when numFound exceeds the ORCID Public API's 10,000-offset retrieval ceiling, so some matches cannot be paged to with the current query. Narrow or partition the query to reach them.
effectiveQueryNoSolr query sent to the ORCID API.

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description's added behavior around the API cap (10,000) and pagination requirement, plus the return of inline data, meaningfully extends this. No contradiction with annotations. It does not mention error cases, but given annotations, this is adequate.

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?

The description is ~120 words but every sentence carries weight: purpose, semantics, return format, alternative, and limit are all addressed. The most critical usage distinction (sibling alternative) is placed near the end but is clearly flagged. No redundant language.

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?

The tool has 10 optional parameters and an output schema, and the description covers how parameters combine, what the response shape is (inline data), and the pagination cap. It also directs to the correct sibling for a specific scenario. Nothing essential is missing for an agent to invoke it correctly.

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?

The input schema fully describes each parameter (100% coverage), but the description adds critical combination semantics: structured params are ANDed, and the query field appends raw Solr syntax. This shared behavior isn't evident from the schema alone and helps the agent construct correct queries.

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 and resource: 'Search the ORCID registry' using structured parameters or raw Solr. It clearly differentiates from sibling get_* tools by focusing on search and explicitly names orcid_resolve_researcher as an alternative for a different use case. The return value (ORCID iDs with inline name/institution) is also clarified.

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 explicitly instructs to use orcid_resolve_researcher when ranked disambiguation of an ambiguous name is needed, providing a clear when-not. It mentions pagination for large result sets, which guides the agent on handling large queries. The note about no follow-up fetches for basic disambiguation suggests this tool is the first step, with get_* tools for details.

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

All orcid-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

Each tool targets a distinct aspect of ORCID data (profile, works, affiliations, funding, peer reviews, research resources) or distinct search mode (researcher disambiguation vs. structured registry search). The relationship between orcid_get_works and orcid_get_work_detail is clearly hierarchical, and the search tools are explicitly differentiated by use case.

Naming Consistency5/5

All tool names follow the consistent pattern `orcid_<verb>_<resource>` with snake_case throughout. Verbs are limited to `get`, `resolve`, `search`, and resource nouns are descriptive and uniform, making the API predictable.

Tool Count5/5

With 9 tools, the server covers all major ORCID profile and activity sections plus two search methods, which is well-scoped for an ORCID data retrieval service. No redundant or unnecessary tools are present.

Completeness5/5

The tool surface comprehensively covers the ORCID public data model: profile, works (with summary and detail), affiliations, funding, peer reviews, and research resources. It also includes search and disambiguation capabilities, leaving no obvious gaps for read-only ORCID interactions.

Resources