orcid-mcp-server
Server Details
Researcher profiles, works, affiliations, funding, and peer reviews from the ORCID registry.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/orcid-mcp-server
- GitHub Stars
- 1
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 9 of 9 tools scored.
Each tool targets a distinct ORCID data category (affiliations, funding, works, profile, etc.) with clear boundaries. The two search tools are explicitly differentiated: orcid_resolve_researcher for ranked name disambiguation and orcid_search_researchers for structured queries. No overlapping purposes.
All tools follow the pattern 'orcid_<verb>_<noun>' using lowercase snake_case. Verbs are consistently 'get' for data retrieval, with 'resolve' and 'search' for disambiguation and search respectively. No deviations.
Nine tools cover the major ORCID record types and operations without bloat. The count is well-matched to the server's purpose of reading researcher data from ORCID.
The server provides comprehensive read coverage for all commonly needed ORCID sections: profile, affiliations, funding, peer reviews, research resources, works (summary and detail), and two search/disambiguation tools. While write operations are absent, that aligns with the read-only design implied by tool names.
Available Tools
9 toolsorcid_get_affiliationsGet ORCID Researcher AffiliationsARead-onlyIdempotentInspect
Fetch affiliation records for an ORCID researcher. The types parameter controls which affiliation sections to return: employment, education, invited-positions, distinctions, memberships, qualifications, services, or all. Default is employment and education. Returns organization names, disambiguated organization identifiers (ROR/GRID/Ringgold), departments, roles, and date ranges. Affiliation data is self-reported; absence does not mean no affiliation.
| Name | Required | Description | Default |
|---|---|---|---|
| types | No | Which affiliation types to return. Defaults to employment and education. Use ["all"] to get every section. | |
| orcid_id | Yes | ORCID iD — bare format (0000-0001-2345-6789) or full URI (https://orcid.org/0000-0001-2345-6789). |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Note when no affiliations were found — may indicate private visibility or no self-reported affiliations. |
| orcidId | Yes | Normalized ORCID iD (bare format). |
| orcidUri | Yes | Full ORCID URI. |
| affiliations | Yes | Affiliation records for the requested types. |
| requestedTypes | Yes | Affiliation types that were requested. |
| affiliationCount | Yes | Total number of affiliation records returned. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds valuable behavioral context: affiliation data is self-reported and absence indicates nothing. This goes beyond the annotations and helps agents interpret results correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It starts with the primary purpose, explains the parameter, and ends with an important caveat. Every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (2 parameters, 1 required, output schema present), the description covers all necessary aspects: purpose, parameter usage, default behavior, and data quality caveat. It also specifies what the response contains. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 the default list and the critical caveat that data is self-reported, which enhances understanding beyond the schema's enum and default descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches affiliation records for an ORCID researcher, specifying the resource and verb. While it distinguishes from siblings by its focus on affiliations, it does not explicitly contrast with other ORCID tools like orcid_get_works or orcid_get_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the types parameter and defaults, but lacks explicit guidance on when to use this tool versus its siblings (e.g., when to prefer affiliations over works or funding). It does not specify prerequisites or scenarios where this tool is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orcid_get_fundingGet ORCID Researcher FundingARead-onlyIdempotentInspect
Fetch funding records for an ORCID researcher: grants, contracts, awards, and salary awards. Returns funder names, funder organization identifiers, grant numbers, and funding periods. Funding data is entirely self-reported — most researchers do not enter funding even when they have grants. Absence of funding records does not imply absence of funding. When records exist they are high-value for grant tracking and funder analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| orcid_id | Yes | ORCID iD — bare format (0000-0001-2345-6789) or full URI (https://orcid.org/0000-0001-2345-6789). |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Note when no funding is found — absence of records does not mean absence of funding. |
| funding | Yes | Funding records associated with this ORCID iD. |
| orcidId | Yes | Normalized ORCID iD (bare format). |
| orcidUri | Yes | Full ORCID URI. |
| fundingCount | Yes | Total number of funding records returned. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint. The description adds critical behavioral context: funding data is self-reported, often incomplete, and absence is not evidence. This goes beyond annotations to manage expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, followed by specifics and a caveat. Every sentence adds value; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single parameter, output schema present), the description is complete. It covers purpose, data characteristics, and limitations. No missing information for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter (orcid_id) with 100% schema coverage and a clear description in the schema. The tool description does not add additional parameter semantics, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action ('Fetch funding records'), the resource ('ORCID researcher'), and details what is returned (funder names, grant numbers, etc.). It clearly distinguishes from sibling tools like orcid_get_affiliations or orcid_get_works by focusing on funding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides important context about data completeness: funding is self-reported and absence does not imply absence. This helps the agent decide when to trust results. However, it does not explicitly state when to use this tool over siblings, though that is clear from the tool name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orcid_get_peer_reviewsGet ORCID Researcher Peer ReviewsARead-onlyIdempotentInspect
Fetch peer review activity for an ORCID researcher: convening organizations (journals and publishers), reviewer role (reviewer, editor, chair, etc.), review type, completion dates, and ISSN-keyed group identifiers. Use to assess editorial activity, journal affiliations, and the scope of a researcher's peer review contributions. Peer review records are self-reported or imported by participating publishers — coverage varies by researcher.
| Name | Required | Description | Default |
|---|---|---|---|
| orcid_id | Yes | ORCID iD — bare format (0000-0001-2345-6789) or full URI (https://orcid.org/0000-0001-2345-6789). |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Note when no peer reviews are found — coverage varies by researcher and publisher participation. |
| orcidId | Yes | Normalized ORCID iD (bare format). |
| orcidUri | Yes | Full ORCID URI. |
| peerReviews | Yes | Peer review records for this ORCID iD. |
| reviewCount | Yes | Total number of peer review records returned. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context by stating that peer review records are 'self-reported or imported by participating publishers — coverage varies by researcher,' which informs the agent about data completeness beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and resource, and contains no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple input (one parameter) and an output schema is present. The description explains the purpose, data details, and coverage caveat. This is sufficient for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter (orcid_id) with a description and pattern, so schema_description_coverage is 100%. The description does not add additional semantic detail beyond what the schema provides, hence baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch peer review activity for an ORCID researcher' and lists specific data elements (organizations, roles, types, dates), distinguishing it from sibling tools like orcid_get_affiliations or orcid_get_works.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use to assess editorial activity, journal affiliations, and the scope of a researcher's peer review contributions,' providing clear context. While it doesn't mention when not to use it or directly compare to siblings, the sibling tools are distinct enough that the usage guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orcid_get_profileGet ORCID Researcher ProfileARead-onlyIdempotentInspect
Fetch a researcher's public profile from ORCID: name, biography, keywords, researcher URLs, and external identifiers such as Scopus Author ID, ResearcherID, and Loop profile. This is the entry point for building a researcher dossier. Pass a bare ORCID iD (0000-0001-2345-6789) or a full URI (https://orcid.org/0000-0001-2345-6789). The profile contains only publicly visible data — researchers control visibility per field.
| Name | Required | Description | Default |
|---|---|---|---|
| orcid_id | Yes | ORCID iD — bare format (0000-0001-2345-6789) or full URI (https://orcid.org/0000-0001-2345-6789). |
Output Schema
| Name | Required | Description |
|---|---|---|
| emails | Yes | Publicly visible email addresses. |
| orcidId | Yes | Normalized ORCID iD (bare format without URI prefix). |
| keywords | Yes | Research keywords set by the researcher. |
| orcidUri | Yes | Full ORCID URI (https://orcid.org/{id}). |
| biography | No | Researcher biography, if publicly visible. |
| countries | Yes | Countries listed in the researcher's address section. |
| creditName | No | Published credit name, if set. |
| familyName | No | Family (last) name, if publicly visible. |
| givenNames | No | Given (first) name, if publicly visible. |
| researcherUrls | Yes | Researcher-provided URLs (personal site, lab page, blog, etc.). |
| externalIdentifiers | Yes | External identifiers from scholarly systems (Scopus, Web of Science, Loop, etc.). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds value by clarifying that the data is publicly visible and that researchers control visibility per field. This provides useful context beyond the annotations, though the safety profile is already clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
All four sentences in the description are informative and free of unnecessary words. The information is front-loaded with the main purpose, followed by context and parameter details, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, typical usage scenario, parameter format, data contents, and visibility constraints. Since there is a single required parameter and an output schema exists (though not detailed), the description is sufficiently complete for the agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds examples of both bare ORCID iD and full URI formats, reinforcing the schema's pattern and helping the agent understand acceptable input formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a researcher's public profile, listing specific data fields (name, biography, keywords, URLs, external IDs). It also positions the tool as the entry point, distinguishing it from sibling tools that retrieve specific sections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance by labeling this tool as 'the entry point for building a researcher dossier', implying it should be used first. It does not explicitly state when not to use it or mention alternatives, but the context from sibling names suggests other tools are for specific sections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orcid_get_research_resourcesGet ORCID Research ResourcesARead-onlyIdempotentInspect
List research resources associated with an ORCID researcher — compute allocations, equipment access, lab facilities, data resources, and clinical study registrations. This is a newer ORCID section; most researchers have no entries. Returns the resource title, hosting organization, external identifiers (often a URI to the allocation portal), and access period. Most entries are deposited by resource-allocation systems (e.g. ACCESS, XSEDE) rather than researchers themselves.
| Name | Required | Description | Default |
|---|---|---|---|
| orcid_id | Yes | ORCID iD — bare format (0000-0001-2345-6789) or full URI (https://orcid.org/0000-0001-2345-6789). |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Note when no research resources are found — this section is sparsely populated across ORCID profiles. |
| orcidId | Yes | Normalized ORCID iD (bare format). |
| orcidUri | Yes | Full ORCID URI. |
| resources | Yes | Research resources associated with this ORCID iD. |
| resourceCount | Yes | Total number of research resources returned. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint and idempotentHint. The description adds context about the section being newer and entries typically deposited by allocation systems, which is helpful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-load the core purpose, then add usage context and return data details. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, annotations, and an output schema, the description covers purpose, data sparsity, and typical fields returned, fully contextualizing the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter has 100% schema coverage with pattern and description. The description adds clarity on acceptable ORCID iD formats (bare or full URI), slightly improving semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists research resources associated with an ORCID researcher, specifying types like compute allocations and equipment access. It distinguishes from sibling tools (e.g., works, funding) by focusing on a distinct ORCID section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit guidance by noting 'most researchers have no entries' and that entries are deposited by systems, but does not explicitly contrast with alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orcid_get_work_detailGet ORCID Work Details (Bulk)ARead-onlyIdempotentInspect
Fetch full detail records for 1–100 works by their put-codes in a single request. Put-codes are returned by orcid_get_works in the put_code field of each work entry. Returns the abstract (short-description), all contributors with CRediT roles, the complete external ID list (DOI, PMID, arXiv, ISBN, etc.), citation metadata (BibTeX or other formats when provided), journal title, and URL for each work. Per-record errors (not-found or inaccessible put-codes) are surfaced as error entries rather than failing the whole call.
| Name | Required | Description | Default |
|---|---|---|---|
| orcid_id | Yes | ORCID iD — bare format (0000-0001-2345-6789) or full URI (https://orcid.org/0000-0001-2345-6789). | |
| put_codes | Yes | Array of 1–100 work put-codes to fetch. Put-codes are available in the put_code field returned by orcid_get_works. |
Output Schema
| Name | Required | Description |
|---|---|---|
| works | Yes | Successfully resolved work detail records. |
| errors | Yes | Per-record errors for put-codes that could not be resolved (not found or inaccessible). Empty when all put-codes resolved successfully. |
| orcidId | Yes | Normalized ORCID iD (bare format). |
| orcidUri | Yes | Full ORCID URI. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description details return fields (abstract, contributors, external IDs, citation metadata, journal title, URL) and importantly explains that per-record errors are handled gracefully as error entries rather than failing the whole call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that efficiently cover the core action, constraints, return fields, and error behavior. No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 adequately covers the most relevant return fields and error handling, making it complete for a bulk fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline 3. The description adds relational context by stating put-codes are from orcid_get_works and reinforces the range and format of parameters, providing value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies Fetch full detail records for 1-100 works by put-codes, clearly identifying the verb, resource, and constraints. It distinguishes from sibling tools by focusing on work details and referencing orcid_get_works for put-codes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool (to fetch detail records by put-codes) and provides context by mentioning put-codes come from orcid_get_works. It lacks explicit when-not-to-use statements, but the sibling tools are for different entities, so usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orcid_get_worksGet ORCID Researcher WorksARead-onlyIdempotentInspect
Retrieve works associated with an ORCID iD — publications, datasets, software, preprints, and more. Returns work summaries with put-codes, titles, types, publication dates, journal names, and all external identifiers (DOIs, PMIDs, arXiv IDs, ISBNs). Pass the put_code from each work to orcid_get_work_detail to retrieve the full record including abstract and contributors. External IDs are ready for chaining to Crossref, PubMed, or arXiv servers. Works are self-reported; a researcher may not have linked all their publications.
| Name | Required | Description | Default |
|---|---|---|---|
| orcid_id | Yes | ORCID iD — bare format (0000-0001-2345-6789) or full URI (https://orcid.org/0000-0001-2345-6789). |
Output Schema
| Name | Required | Description |
|---|---|---|
| works | Yes | Works associated with this ORCID iD. |
| notice | No | Note when the works list is empty — may indicate no self-reported works or private visibility settings. |
| orcidId | Yes | Normalized ORCID iD (bare format). |
| orcidUri | Yes | Full ORCID URI. |
| workCount | Yes | Total number of works returned. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds useful behavioral context: works are self-reported and may not be complete, and external IDs are ready for chaining. This adds value beyond the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (four sentences) and front-loaded with the main purpose. Every sentence adds value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, comprehensive annotations, and an output schema (implied by context signal), the description is complete. It explains what is returned, how to use the outputs, and mentions data quality caveats. No gaps remain for an agent to effectively use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter (orcid_id) is fully described in the input schema (100% coverage) with pattern and description. The description does not add additional semantics beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves works associated with an ORCID iD, listing specific types (publications, datasets, etc.) and what is returned (put-codes, titles, types, publication dates, journal names, external identifiers). It distinguishes from siblings by mentioning the put_code for detail retrieval and chaining to other services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it tells when to use it (to get a researcher's works), how to use the results (pass put_code to orcid_get_work_detail), and how to chain external IDs. It does not explicitly state when not to use it or name alternatives among siblings, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orcid_resolve_researcherResolve ORCID ResearcherARead-onlyIdempotentInspect
Disambiguate an author name to a verified ORCID iD. Returns up to 5 ranked candidates 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.
| Name | Required | Description | Default |
|---|---|---|---|
| doi | No | DOI of a work authored by this researcher. Acts as a near-deterministic anchor — filters to researchers who linked this DOI to their ORCID record. | |
| name | Yes | Author name to disambiguate (full name preferred, e.g. "Jennifer Doudna" or "J. Doudna"). | |
| pmid | No | PubMed 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. | |
| rows | No | Maximum candidate count to return (1–20). Defaults to 5. | |
| affiliation | No | Researcher's institution or organization name. Used for institution overlap scoring and optionally as a search constraint. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Recovery hint when no candidates are found or when the anchor query failed to match. |
| queryUsed | Yes | Solr query sent to ORCID for the primary search. |
| candidates | Yes | Ranked candidates, ordered by name match quality then institution overlap. |
| totalFound | Yes | Total ORCID records matching the primary query. |
| relaxedQuery | No | Solr query used in a secondary relaxed search, if the primary returned no results. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses output details: up to 5 ranked candidates, transparent signals (name match type, institution overlap, anchor usage), and raw signals only. Annotations already provide readOnlyHint, openWorldHint, idempotentHint; description adds valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise single paragraph with clear structure: purpose, output, guidance, raw signals. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, full annotations, output schema, and sibling context, the description is complete. It covers when to use, what signals are returned, and key behaviors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3. Description adds meaning by explaining DOI/PMID as near-deterministic anchors and mentioning signals returned, which is helpful beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it disambiguates an author name to a verified ORCID iD. Distinguishes from sibling orcid_search_researchers by specifying it is for ambiguous names needing ranked disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use this tool over orcid_search_researchers when input is an ambiguous name needing ranked disambiguation. Also explains the near-deterministic nature of DOI/PMID anchors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orcid_search_researchersSearch ORCID ResearchersARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| doi | No | DOI to anchor the search. Returns researchers who have linked this DOI to their ORCID record. | |
| pmid | No | PubMed ID to anchor the search. Returns researchers who have linked this PMID to their ORCID record. | |
| rows | No | Maximum results to return (1–1000). | |
| query | No | Raw Solr query string appended to the generated clause with AND. Supports all ORCID Solr fields and boolean operators. | |
| start | No | Pagination offset (0-based), 0–10,000. The ORCID Public API rejects start > 10,000 for unauthenticated requests. | |
| ror_id | No | ROR organization ID to filter by (full URL, e.g. https://ror.org/00f54p054). Returns researchers affiliated with this organization. | |
| keyword | No | Keyword to search in the researcher's keyword fields. Phrase match. | |
| given_name | No | Researcher's given (first) name. | |
| affiliation | No | Organization name to filter by. Phrase match. | |
| family_name | No | Researcher's family (last) name. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rows | Yes | Number of results returned in this response. |
| start | Yes | Pagination offset used for this response. |
| notice | No | Recovery hint when results are empty or pagination overshoots the total. Absent on successful pages. |
| results | Yes | Matching researchers with inline name and institution data. |
| numFound | Yes | Total number of matching records in ORCID (before pagination). |
| effectiveQuery | Yes | Solr query sent to the ORCID API. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint. Description adds that structured params are ANDed, query appends raw Solr, and the API caps at 10,000 results, providing useful operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences packed with essential information: purpose, behavior, return data, and alternative. No redundancy, but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters all described in schema and output schema exists, description explains search logic, pagination limits, and return completeness. No major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 10 parameters with descriptions (100% coverage). Description adds that all structured params are ANDed and the 'query' field appends raw Solr to the generated clause, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it searches the ORCID registry using structured field parameters or raw Solr syntax, and distinguishes from sibling 'orcid_resolve_researcher' for ranked disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (basic disambiguation) and when not (use orcid_resolve_researcher for ambiguous names), plus pagination hint for large results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!