Skip to main content
Glama

orcid-mcp-server

by io.github.cyanheads

Resolve ORCID Researcher

orcid_resolve_researcher
Read-onlyIdempotent

Disambiguate an author name to a verified ORCID iD. Returns ranked candidates (5 by default, up to 20 via the rows parameter) with transparent disambiguation signals: name match type (exact/partial/other-name/none), institution overlap flag, and whether a DOI or PMID anchor was used in the query. A DOI or PMID anchor is near-deterministic — it filters to researchers who have linked that specific work to their ORCID record. Use this tool (not orcid_search_researchers) when the input is an ambiguous name that needs ranked disambiguation. No synthetic scores are used — raw signals only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
doiNoDOI of a work authored by this researcher. Acts as a near-deterministic anchor — filters to researchers who linked this DOI to their ORCID record.
nameYesAuthor name to disambiguate (full name preferred, e.g. "Jennifer Doudna" or "J. Doudna").
pmidNoPubMed ID of a work authored by this researcher. Acts as a near-deterministic anchor — filters to researchers who linked this PMID to their ORCID record.
rowsNoMaximum candidate count to return (1–20). Defaults to 5.
affiliationNoResearcher's institution or organization name. Used for institution overlap scoring and optionally as a search constraint.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
noticeNoRecovery hint when no candidates are found or when the anchor query failed to match.
queryUsedNoThe Solr query that produced the returned candidates — the primary query, or the final relaxed query when a fallback ran. Paired with totalFound.
candidatesNoRanked candidates, ordered by name match quality then institution overlap.
totalFoundNoTotal ORCID records matching queryUsed (the query that produced the returned candidates).
primaryQueryNoThe primary, most-constrained Solr query attempted first (name + optional anchor + optional affiliation). Always populated; equals queryUsed when no relaxed fallback ran.
relaxedQueryNoSolr query used in a secondary relaxed search, if the primary returned no results.
primaryTotalFoundNoTotal ORCID records matching primaryQuery. Zero when the primary query found nothing and a relaxed fallback produced the returned candidates.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations (readOnlyHint, openWorldHint, idempotentHint) already signal safety, but the description adds substantial behavioral context: ranked results, disambiguation signals (name match type, institution overlap, DOI/PMID anchor), and 'No synthetic scores are used — raw signals only.' This goes well beyond the annotation hints and fully discloses internal logic.

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 sentences, each earning its place: the first defines the core action and output, the second explains the return signals, the third gives usage guidance and disambiguation philosophy. No filler, front-loaded with the primary purpose.

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 the presence of an output schema, the description doesn't need to detail return format beyond what it already provides. It covers all necessary call context: when to use, what parameters matter (DOI/PMID anchors), and what results contain. Nothing an agent needs to invoke the tool 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% and each parameter has a description, so baseline is 3. The description adds meaningful extra semantics: explains the near-deterministic anchor behavior for doi/pmid, the default and max for rows, and preference for full names in the name parameter. This elevates it above baseline but doesn't reinvent 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?

The description states a clear verb and resource: 'Disambiguate an author name to a verified ORCID iD.' It also explicitly distinguishes itself from the sibling orcid_search_researchers by stating when to use it instead, which makes the purpose unambiguous.

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?

Provides explicit when-to-use guidance: 'Use this tool (not orcid_search_researchers) when the input is an ambiguous name that needs ranked disambiguation.' Also clarifies the near-deterministic nature of DOI/PMID anchors, giving concrete selection criteria beyond basic alternatives.

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