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.5/5 across 9 of 9 tools scored.
Each tool targets a distinct ORCID data section with clear boundaries. The overlap between orcid_get_works and orcid_get_work_detail is resolved by the former returning summaries and the latter requiring put-codes for full details. Similarly, orcid_resolve_researcher and orcid_search_researchers serve different search purposes.
All tools follow the consistent pattern 'orcid_<verb>_<resource>' using snake_case. Verbs are limited to get, resolve, and search, and resources are clearly named (affiliations, funding, works, etc.).
9 tools cover the main public ORCID sections (profile, works, affiliations, funding, peer reviews, research resources) plus two search variants. This is well-scoped for a read-only ORCID data server without being overwhelming.
The tool set provides complete read access to all major public ORCID record sections. No obvious gaps exist for the stated purpose of fetching researcher data. The addition of both summary and detail retrieval for works demonstrates thoroughness.
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 putCode 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 putCode 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 the read-only and idempotent annotations, the description details the returned fields (abstract, contributors, external IDs, citation metadata, journal title, URL) and explains per-record error handling. This adds useful behavioral context beyond the structured 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: first states core functionality and limits, second lists return fields and error behavior. Every sentence adds value, with no unnecessary information, and the key action is front-loaded.
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?
For a 2-parameter read-only tool with an output schema, the description covers the essential return fields and error handling. It does not mention access-level requirements (e.g., public vs. authenticated), but given the presence of an output schema, this is a minor omission.
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 both parameters with full descriptions. The description adds minimal extra context (e.g., put-codes come from orcid_get_works), but since schema coverage is 100%, the baseline is 3 and the description does not significantly enhance parameter understanding.
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 full detail records for 1-100 works using their put-codes. It distinguishes from sibling tools like orcid_get_works by specifying it retrieves detailed metadata rather than a list of 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 explains that put-codes come from orcid_get_works, implying a workflow of first fetching works then getting details. It also notes error handling for invalid put-codes, but does not explicitly state when not to use or provide alternative tools for non-bulk needs.
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). The first 50 works are returned by default; workCount reports the total available, and prolific records are paged with offset and the returned nextOffset (or raise limit). Set include_external_ids to false to omit identifier lists for a lighter payload. Pass the putCode 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 |
|---|---|---|---|
| limit | No | Maximum works to return in this response (default 50, max 1000). The full list is sliced locally — page prolific records with offset and the returned nextOffset. | |
| offset | No | Zero-based index of the first work to return (default 0). Combine with limit to page through the full works list. | |
| orcid_id | Yes | ORCID iD — bare format (0000-0001-2345-6789) or full URI (https://orcid.org/0000-0001-2345-6789). | |
| include_external_ids | No | When true (default), each work carries its external identifiers (DOIs, PMIDs, arXiv IDs, ISBNs). Set false to omit them for a lighter payload when only titles, types, and dates are needed. |
Output Schema
| Name | Required | Description |
|---|---|---|
| works | Yes | Works for this ORCID iD, sliced to the requested offset and limit. |
| notice | No | Note when the works list is empty — may indicate no self-reported works or private visibility settings. |
| offset | Yes | Zero-based offset applied to the full works list for this response. |
| orcidId | Yes | Normalized ORCID iD (bare format). |
| orcidUri | Yes | Full ORCID URI. |
| truncated | Yes | True when more works are available beyond this response — fetch them with nextOffset. |
| workCount | Yes | Total works available for this ORCID iD, before offset and limit are applied. |
| nextOffset | No | Offset to pass on the next call to continue paging. Omitted when this response includes the final work. |
| returnedCount | Yes | Number of works returned in this response, after applying offset and limit. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond annotations: default limit of 50, pagination with nextOffset, the self-reported nature of works, and external IDs ready for chaining. This complements readOnlyHint and idempotentHint with practical usage 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?
The description is somewhat long (4 sentences) but every sentence adds information. It is front-loaded with the purpose and progressively adds details. Could be slightly tighter, but overall efficient and well-structured.
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 output schema exists (not shown) and schema coverage is 100%, the description provides a comprehensive overview of returned fields (put-codes, titles, types, dates, journal names, identifiers) and mentions chaining to other services. It covers all essential aspects for an agent to use 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 description coverage, the description still adds significant value by explaining defaults (limit 50, offset 0), the meaning of workCount and nextOffset (output fields), the local slicing, and the trade-off of include_external_ids. It enriches agent understanding of parameter behavior.
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, specifying the verb 'retrieve' and the resource 'works' (publications, datasets, etc.). It implicitly distinguishes from siblings like orcid_get_work_detail, which gets full records.
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 when to use this tool (to list works) and how to page through results with offset/limit. It also mentions an alternative (orcid_get_work_detail for full records) and customization (include_external_ids). Lacks explicit when-not-to-use guidance, but sufficient for most agents.
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 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.
| 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 | The Solr query that produced the returned candidates — the primary query, or the final relaxed query when a fallback ran. Paired with totalFound. |
| candidates | Yes | Ranked candidates, ordered by name match quality then institution overlap. |
| totalFound | Yes | Total ORCID records matching queryUsed (the query that produced the returned candidates). |
| primaryQuery | Yes | The primary, most-constrained Solr query attempted first (name + optional anchor + optional affiliation). Always populated; equals queryUsed when no relaxed fallback ran. |
| relaxedQuery | No | Solr query used in a secondary relaxed search, if the primary returned no results. |
| primaryTotalFound | Yes | Total ORCID records matching primaryQuery. Zero when the primary query found nothing and a relaxed fallback produced the returned candidates. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses key behavioral traits: no synthetic scores, raw signals only, and the specific disambiguation signals (name match type, institution overlap, anchor usage). It also explains that DOI/PMID anchors near-deterministically filter to researchers who linked that work. No contradiction with 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 a single, well-structured paragraph that front-loads the purpose. Every sentence adds unique value: purpose, output description, parameter behavior, usage guidance, and transparency details. No wasted words, and the structure makes it easy for an agent 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?
Given the tool's complexity (5 parameters, ranked output, disambiguation logic) and the presence of an output schema, the description covers all essential aspects: purpose, usage conditions, parameter semantics, and output transparency. It explains the behavior of anchors, the ranking signals, and the default/max row count. The sibling distinction is covered. No gaps are apparent.
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 significant meaning beyond the schema definitions: explains how doi and pmid act as near-deterministic anchors, clarifies the rows parameter default and maximum, and describes affiliation's role in institution overlap scoring. The description also notes that multiple signals are returned, adding context 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?
The description clearly states the tool's purpose: 'Disambiguate an author name to a verified ORCID iD.' It uses a specific verb ('disambiguate') and resource ('ORCID iD'), and explicitly distinguishes from the sibling tool orcid_search_researchers by specifying the use case of ambiguous name disambiguation with ranked results.
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 explicit guidance on when to use this tool versus the sibling: 'Use this tool (not orcid_search_researchers) when the input is an ambiguous name that needs ranked disambiguation.' It also explains the near-deterministic role of DOI/PMID anchors. However, it does not explicitly mention scenarios where the tool should not be used (e.g., when the exact ORCID is already known), which would strengthen completeness.
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, pagination overshoots the total, or matches exceed the 10,000-offset ceiling. Absent on fully retrievable pages. |
| results | Yes | Matching researchers with inline name and institution data. |
| numFound | Yes | Total number of matching records in ORCID (before pagination). |
| nextStart | No | Offset 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. |
| truncated | Yes | True 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. |
| 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?
Adds significant behavioral context beyond annotations: structured params are ANDed, query appends raw Solr, return includes inline data without follow-up, and API caps results at 10,000.
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, front-loaded with purpose, and every sentence provides useful information without redundancy.
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 output schema exists and 10 parameters are fully documented in the schema, the description covers the primary concerns: search method, results format, alternative tool, and API constraints.
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. Description adds value by explaining AND logic for structured params and how the query field appends to the generated clause.
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 searches the ORCID registry with structured fields or raw Solr, and distinguishes it from the sibling tool orcid_resolve_researcher.
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 states when to use this tool (searching with structured params or Solr) and provides an alternative (orcid_resolve_researcher for ranked disambiguation). Also mentions pagination and API limits.
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!