A
licenseNot graded
qualityC
maintenanceEnables querying ORCID public records, including profiles, publications, employment, education, and search, through natural language or direct tool calls.
15
MIT
orcid-mcp-server
Server Details
Researcher profiles, works, affiliations, funding, and peer reviews from the ORCID registry.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/orcid-mcp-server
- GitHub Stars
- 2
- Server Listing
- @cyanheads/orcid-mcp-server
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Note when no affiliations were found — may indicate private visibility or no self-reported affiliations. |
| orcidId | No | Normalized ORCID iD (bare format). |
| orcidUri | No | Full ORCID URI. |
| affiliations | No | Affiliation records for the requested types. |
| requestedTypes | No | Affiliation types that were requested. |
| affiliationCount | No | Total number of affiliation records returned. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds a valuable behavioral note that affiliation data is self-reported and that absence does not imply no affiliation, which is critical for correct interpretation. It also mentions the specific fields returned (organization names, identifiers, etc.), enriching the behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each carrying weight: purpose, parameter control, and data caveat. It is front-loaded with the primary action and remains free of redundant phrasing. Every sentence earns its place without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward read operation with an output schema available. The description covers the purpose, parameter behavior, returned fields, and a crucial data-quality caveat. There is no missing information an agent needs to invoke it correctly or interpret results appropriately.
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?
Input schema covers 100% of parameters with descriptions, so the baseline is 3. The description reinforces the types parameter's meaning by listing all acceptable values and the default, and adds context on what the returned data contains. It slightly exceeds the schema by explaining the output fields, but does not add significant new param-level semantics beyond what the schema already provides.
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 uses a specific verb ('Fetch') and resource ('affiliation records for an ORCID researcher'), and clearly differentiates from sibling tools by focusing on affiliations. It states the exact scope and lists the types parameter's possible values, leaving no ambiguity about what this tool retrieves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool (to fetch affiliations) and explains the default behavior of the types parameter. However, it does not explicitly reference sibling tools or state when to choose an alternative (e.g., if needing funding or peer reviews), so the guidance is implied rather than explicit.
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Note when no funding is found — absence of records does not mean absence of funding. |
| funding | No | Funding records associated with this ORCID iD. |
| orcidId | No | Normalized ORCID iD (bare format). |
| orcidUri | No | Full ORCID URI. |
| fundingCount | No | Total number of funding records returned. |
TDQS
A3.7/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare openWorldHint=false, meaning absence of a value implies absence in the real world (closed-world). The description explicitly states the opposite: 'Absence of funding records does not imply absence of funding' — the open-world position. This directly contradicts the annotation, giving the agent conflicting guidance on how to interpret missing data.
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?
Five sentences, each earning its place: purpose, return fields, the self-reporting caveat, the absence implication, and the value statement. Purpose is front-loaded and the caveat is placed before the value claim for logical flow. No filler.
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?
For a single-parameter read-only tool with a full output schema, this is complete. It states what it returns, warns about data incompleteness, and explains when the results are valuable — an agent can invoke it and interpret the response correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single orcid_id parameter, including the pattern and accepted formats (bare or full URI). The description adds no further parameter details, so it neither raises nor lowers the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Fetch funding records for an ORCID researcher') with enumerated record types (grants, contracts, awards, salary awards) and the returned fields (funder names, org identifiers, grant numbers, funding periods). The funding focus clearly differentiates it from siblings like orcid_get_works and orcid_get_affiliations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear interpretive context: funding data is 'entirely self-reported' and 'high-value for grant tracking and funder analysis'. It tells the agent when results are meaningful, though it does not explicitly contrast with sibling tools or state when to prefer an alternative.
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Note when no peer reviews are found — coverage varies by researcher and publisher participation. |
| orcidId | No | Normalized ORCID iD (bare format). |
| orcidUri | No | Full ORCID URI. |
| peerReviews | No | Peer review records for this ORCID iD. |
| reviewCount | No | Total number of peer review records returned. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true. The description adds a meaningful behavioral caveat: 'Peer review records are self-reported or imported by participating publishers — coverage varies by researcher.' This discloses potential data incompleteness, which is not captured in annotations and is important for interpreting results. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with zero redundancy. The first sentence front-loads the core purpose and field list, the second states the use case, and the third provides an essential data-quality caveat. Every sentence adds value, and the structure is tight and scannable.
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?
For a simple getter with one fully-documented parameter and an existing output schema (which obviates the need to explain return values), the description covers all essential context: what the tool retrieves, when to use it, and a critical caveat about data coverage. Nothing an agent needs to decide whether and how to call it is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the single parameter orcid_id is fully documented in the schema (format, bare URI, pattern). The description does not add additional parameter semantics beyond what the schema already provides. Since the schema carries the full burden, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Fetch') and resource ('peer review activity for an ORCID researcher') and enumerates the exact data points returned (convening organizations, reviewer role, review type, completion dates, ISSN-keyed group identifiers). This clearly distinguishes it from sibling getters like orcid_get_works or orcid_get_affiliations, which target different record types. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use to assess editorial activity, journal affiliations, and the scope of a researcher's peer review contributions.' This tells an agent when to invoke the tool, but it does not explicitly contrast with alternatives (e.g., 'use this instead of works for review data'). Given the sibling names are self-explanatory, the lack of explicit exclusions is minor but still leaves the when-not-to-use guidance implicit.
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| emails | No | Publicly visible email addresses. |
| orcidId | No | Normalized ORCID iD (bare format without URI prefix). |
| keywords | No | Research keywords set by the researcher. |
| orcidUri | No | Full ORCID URI (https://orcid.org/{id}). |
| biography | No | Researcher biography, if publicly visible. |
| countries | No | 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 | No | Researcher-provided URLs (personal site, lab page, blog, etc.). |
| externalIdentifiers | No | External identifiers from scholarly systems (Scopus, Web of Science, Loop, etc.). |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds a valuable behavioral trait not in annotations: 'The profile contains only publicly visible data — researchers control visibility per field.' This informs the agent about data availability and privacy constraints, which is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste. The first sentence states the purpose and contents, the second provides strategic context, and the third covers input formats and visibility. All information is pertinent and effectively front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one well-documented parameter, an output schema (so return values are covered), and the description explains what data is included and its public-only nature. There are no nested objects or additional complexity, and the description fully prepares an agent to call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — the schema description already explains both accepted formats (bare ORCID iD and full URI) and the pattern enforces it. The description repeats this exact information without adding new meaning. Since the schema does the heavy lifting, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Fetch) and resource (researcher's public profile from ORCID) and enumerates the included fields (name, biography, keywords, researcher URLs, external identifiers). It also positions itself as 'the entry point for building a researcher dossier,' which clearly differentiates it from sibling tools focused on specific sections like affiliations or funding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly calls this 'the entry point for building a researcher dossier,' implying you should start here before using more specific sibling tools. However, it does not explicitly name alternatives or state when NOT to use this tool, leaving the routing logic to inference. This is a clear context but lacks explicit exclusions.
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Note when no research resources are found — this section is sparsely populated across ORCID profiles. |
| orcidId | No | Normalized ORCID iD (bare format). |
| orcidUri | No | Full ORCID URI. |
| resources | No | Research resources associated with this ORCID iD. |
| resourceCount | No | Total number of research resources returned. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description need not restate those. It adds valuable context beyond annotations: the section's newness, the likelihood of empty results, the typical deposition source, and the specific return fields (title, hosting organization, external identifiers, access period). This helps the agent set expectations without contradicting any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no redundancy. It leads with the main verb and resource, then packs useful contextual details and return fields into a compact structure. Every sentence earns its place.
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?
For a single-parameter read tool with annotations and an output schema, the description is complete: it defines the tool's purpose, the data's typical state (mostly empty), who deposits it, and what the response contains. An agent can decide whether to call it and what to expect without further inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter 'orcid_id', including format and accepted URI or bare forms. The tool description adds no additional parameter-level meaning beyond what the schema documents, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a precise resource ('research resources associated with an ORCID researcher'), and enumerates the exact types included (compute allocations, equipment access, lab facilities, data resources, clinical study registrations). It also distinguishes this from sibling tools by referencing the ORCID section, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly scopes usage to research resources and adds practical guidance: it's a newer section, most researchers have no entries, and deposits come from resource-allocation systems like ACCESS and XSEDE. It does not explicitly name alternatives or state when not to use it, but the sibling names (affiliations, funding, works) and the focused description make the usage context clear.
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| works | No | Successfully resolved work detail records. |
| errors | No | Per-record errors for put-codes that could not be resolved (not found or inaccessible). Empty when all put-codes resolved successfully. |
| orcidId | No | Normalized ORCID iD (bare format). |
| orcidUri | No | Full ORCID URI. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, which covers the safety profile. The description adds genuine behavioral value beyond that: per-record errors for not-found or inaccessible put-codes are surfaced as error entries rather than failing the whole call. It also enumerates the returned fields (abstract, CRediT contributors, external ID list, citation metadata, journal, URL). No contradiction exists — 'Fetch' aligns with readOnlyHint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single four-sentence paragraph that front-loads the core action in the first sentence and then builds detail. Every sentence earns its place: scope, input provenance, returned fields, and error behavior. It is informative without being bloated, though slightly dense in the field-enumeration sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and the input schema is fully self-describing, the description covers the essential operational context: batch limits, the dependency on orcid_get_works, per-record error handling, and the return payload composition. No critical gap prevents an agent from calling it correctly, though it could optionally name the output schema structure explicitly.
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%, so both parameters are fully documented in the schema, giving a baseline of 3. The description adds value on top by explaining that put_codes are sourced from the putCode field of orcid_get_works responses, providing provenance guidance that the schema alone lacks. This linkage helps the agent know where to retrieve the required input.
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 opens with a specific verb and resource: 'Fetch full detail records for 1–100 works by their put-codes in a single request.' It clearly scopes the tool to bulk work detail retrieval, and distinguishes it from siblings by naming the input mechanism (put-codes) and the parent tool (orcid_get_works) that supplies them. An agent can immediately tell this apart from orcid_get_works, orcid_get_affiliations, or orcid_get_funding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an implicit workflow: 'Put-codes are returned by orcid_get_works in the putCode field of each work entry,' which tells the agent that this tool depends on a prior orcid_get_works call. This provides clear contextual guidance on when to invoke the tool. However, it offers no explicit exclusions or 'use X instead of Y when' routing for the other siblings (affiliations, funding, peer reviews), so the guidance is implied rather than stated.
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| works | No | 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 | No | Zero-based offset applied to the full works list for this response. |
| orcidId | No | Normalized ORCID iD (bare format). |
| orcidUri | No | Full ORCID URI. |
| truncated | No | True when more works are available beyond this response — fetch them with nextOffset. |
| workCount | No | 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 | No | Number of works returned in this response, after applying offset and limit. |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint, openWorldHint, and idempotentHint. The description adds substantial behavioral context: default paging behavior (first 50, workCount total, nextOffset), how limit and offset interact, the option to slim payloads, chaining readiness of external IDs to Crossref/PubMed/arXiv, and the caveat that works are self-reported and may be incomplete. This goes far beyond the safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about four sentences, front-loaded with the core purpose and immediately followed by return details, paging, chaining, and a data-quality caveat. Every sentence adds distinct value; there is no fluff, redundancy, or irrelevant detail. The structure guides the agent from what it does to how to page and what to expect.
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 output schema and annotations are present, the description covers everything an agent needs to call correctly: what fields are returned, how to page with offset/limit/nextOffset, how to get full details via orcid_get_work_detail, how to chain external IDs, and the self-reporting limitation. No missing operational or safety details were identified.
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%, so each parameter is fully documented in the schema. The description adds value by clarifying the paging interaction ('the full list is sliced locally'), the default and max for limit, the purpose of include_external_ids as a payload optimization, and the two accepted formats for orcid_id. This is more than a mere restatement, justifying an elevated score above the baseline.
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 opens with a specific verb-resource pair, 'Retrieve works associated with an ORCID iD,' and enumerates content types (publications, datasets, software, preprints) along with returned fields (put-codes, titles, types, dates, journal names, external IDs). It clearly distinguishes from siblings like orcid_get_work_detail (by referencing it for full records) and other resource-specific tools (affiliations, funding, etc.) through the focus on works.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it explains default limit of 50, paging with offset and nextOffset, the option to reduce payload with include_external_ids, and explicitly routes to orcid_get_work_detail when full records including abstracts are needed. It lacks an explicit 'do not use when' statement, but the alternative path is explicit enough that an agent can choose correctly.
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| error | No | Present when the call failed. Absent on success. |
| notice | No | Recovery hint when no candidates are found or when the anchor query failed to match. |
| queryUsed | No | The Solr query that produced the returned candidates — the primary query, or the final relaxed query when a fallback ran. Paired with totalFound. |
| candidates | No | Ranked candidates, ordered by name match quality then institution overlap. |
| totalFound | No | Total ORCID records matching queryUsed (the query that produced the returned candidates). |
| primaryQuery | No | 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 | No | Total 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.
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.
ParametersJSON Schema
| 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
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| rows | No | Number of results returned in this response. |
| error | No | Present when the call failed. Absent on success. |
| start | No | 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 | No | Matching researchers with inline name and institution data. |
| numFound | No | 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 | No | 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 | No | Solr query sent to the ORCID API. |
TDQS
A4.7/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description's added behavior around the API cap (10,000) and pagination requirement, plus the return of inline data, meaningfully extends this. No contradiction with annotations. It does not mention error cases, but given annotations, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is ~120 words but every sentence carries weight: purpose, semantics, return format, alternative, and limit are all addressed. The most critical usage distinction (sibling alternative) is placed near the end but is clearly flagged. No redundant language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 optional parameters and an output schema, and the description covers how parameters combine, what the response shape is (inline data), and the pagination cap. It also directs to the correct sibling for a specific scenario. Nothing essential is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes each parameter (100% coverage), but the description adds critical combination semantics: structured params are ANDed, and the query field appends raw Solr syntax. This shared behavior isn't evident from the schema alone and helps the agent construct correct queries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Search the ORCID registry' using structured parameters or raw Solr. It clearly differentiates from sibling get_* tools by focusing on search and explicitly names orcid_resolve_researcher as an alternative for a different use case. The return value (ORCID iDs with inline name/institution) is also clarified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to use orcid_resolve_researcher when ranked disambiguation of an ambiguous name is needed, providing a clear when-not. It mentions pagination for large result sets, which guides the agent on handling large queries. The note about no follow-up fetches for basic disambiguation suggests this tool is the first step, with get_* tools for details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
9 tool updates
- Changed
orcid_get_affiliations6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "orcidId", + "orcidUri", + "affiliationCount", + "affiliations", + "requestedTypes" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `profile_not_found`: The ORCID iD does not correspond to a registered researcher. Other values are possible when a failure originates below the handler.", + "examples": [ + "profile_not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "orcidId", - "orcidUri", - "affiliationCount", - "affiliations", - "requestedTypes" -]
- Changed
orcid_get_funding6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "orcidId", + "orcidUri", + "fundingCount", + "funding" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `profile_not_found`: The ORCID iD does not correspond to a registered researcher. Other values are possible when a failure originates below the handler.", + "examples": [ + "profile_not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "orcidId", - "orcidUri", - "fundingCount", - "funding" -]
- Changed
orcid_get_peer_reviews6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "orcidId", + "orcidUri", + "reviewCount", + "peerReviews" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `profile_not_found`: The ORCID iD does not correspond to a registered researcher. Other values are possible when a failure originates below the handler.", + "examples": [ + "profile_not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "orcidId", - "orcidUri", - "reviewCount", - "peerReviews" -]
- Changed
orcid_get_profile6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "orcidId", + "orcidUri", + "keywords", + "researcherUrls", + "externalIdentifiers", + "emails", + "countries" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `profile_not_found`: The ORCID iD does not correspond to a registered researcher. Other values are possible when a failure originates below the handler.", + "examples": [ + "profile_not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "orcidId", - "orcidUri", - "keywords", - "researcherUrls", - "externalIdentifiers", - "emails", - "countries" -]
- Changed
orcid_get_research_resources6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "orcidId", + "orcidUri", + "resourceCount", + "resources" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `profile_not_found`: The ORCID iD does not correspond to a registered researcher. Other values are possible when a failure originates below the handler.", + "examples": [ + "profile_not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "orcidId", - "orcidUri", - "resourceCount", - "resources" -]
- Changed
orcid_get_work_detail6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "orcidId", + "orcidUri", + "works", + "errors" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `profile_not_found`: The ORCID iD does not correspond to a registered researcher. `fetch_failed`: The ORCID bulk works endpoint returns an unexpected error. Other values are possible when a failure originates below the handler.", + "examples": [ + "profile_not_found", + "fetch_failed" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "orcidId", - "orcidUri", - "works", - "errors" -]
- Changed
orcid_get_works6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "orcidId", + "orcidUri", + "workCount", + "returnedCount", + "offset", + "truncated", + "works" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `profile_not_found`: The ORCID iD does not correspond to a registered researcher. Other values are possible when a failure originates below the handler.", + "examples": [ + "profile_not_found" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "orcidId", - "orcidUri", - "workCount", - "returnedCount", - "offset", - "truncated", - "works" -]
- Changed
orcid_resolve_researcher6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "candidates", + "queryUsed", + "totalFound", + "primaryQuery", + "primaryTotalFound" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `query_failed`: ORCID rejects a search built from the supplied name, affiliation, or identifier anchor. Other values are possible when a failure originates below the handler.", + "examples": [ + "query_failed" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "candidates", - "queryUsed", - "totalFound", - "primaryQuery", - "primaryTotalFound" -]
- Changed
orcid_search_researchers6 fields changed- changed
Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Input schema / additionalPropertiesAdded value: +false - changed
Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema" - added
Output schema / anyOfAdded value: +[ + { + "not": { + "required": [ + "error" + ] + }, + "required": [ + "results", + "rows", + "start", + "effectiveQuery", + "numFound", + "truncated" + ] + }, + { + "required": [ + "error" + ] + } +] - added
Output schema / properties / errorAdded value: +{ + "additionalProperties": {}, + "description": "Present when the call failed. Absent on success.", + "properties": { + "code": { + "description": "JSON-RPC error code for this failure.", + "maximum": 9007199254740991, + "minimum": -9007199254740991, + "type": "integer" + }, + "data": { + "additionalProperties": {}, + "properties": { + "reason": { + "description": "Machine-readable failure mode. Declared by this tool: `query_failed`: ORCID rejects the compiled Solr query — most often malformed raw query syntax. Other values are possible when a failure originates below the handler.", + "examples": [ + "query_failed" + ], + "type": "string" + }, + "recovery": { + "additionalProperties": {}, + "description": "Actionable next step for the caller.", + "properties": { + "hint": { + "type": "string" + } + }, + "required": [ + "hint" + ], + "type": "object" + }, + "retryable": { + "description": "Whether retrying may succeed.", + "type": "boolean" + } + }, + "type": "object" + }, + "message": { + "description": "Human-readable description of what went wrong.", + "type": "string" + } + }, + "required": [ + "code", + "message" + ], + "type": "object" +} - removed
Output schema / requiredRemoved value: -[ - "results", - "rows", - "start", - "effectiveQuery", - "numFound", - "truncated" -]
1 tool update
- Changed
orcid_resolve_researcher1 field changed- changed
Output schema / properties / candidates / items / properties / institutionOverlap / descriptionPrevious value: -"True when at least one of the candidate's institutions matches tokens from the provided affiliation parameter."New value: +"True when the provided affiliation and one of the candidate's institutions are the same name, or one appears inside the other as a contiguous run of words (so an abbreviated form still matches its full name). A single shared word such as a city or surname is not enough."
2 tool updates
- Changed
orcid_get_work_detail1 field changed- changed
Input schema / properties / put_codes / descriptionPrevious value: -"Array of 1–100 work put-codes to fetch. Put-codes are available in the put_code field returned by orcid_get_works."New value: +"Array of 1–100 work put-codes to fetch. Put-codes are available in the putCode field returned by orcid_get_works."
- Changed
orcid_search_researchers5 fields changed- added
Output schema / properties / nextStartAdded value: +{ + "description": "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.", + "type": "number" +} - changed
Output schema / properties / notice / descriptionPrevious value: -"Recovery hint when results are empty or pagination overshoots the total. Absent on successful pages."New value: +"Recovery hint when results are empty, pagination overshoots the total, or matches exceed the 10,000-offset ceiling. Absent on fully retrievable pages." - changed
Output schema / properties / results / items / properties / institutionNames / descriptionPrevious value: -"Affiliated institution names returned by expanded-search."New value: +"Affiliated institution names returned inline with each search result." - added
Output schema / properties / truncatedAdded value: +{ + "description": "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.", + "type": "boolean" +} - changed
Output schema / requiredPrevious value: -[ - "results", - "rows", - "start", - "effectiveQuery", - "numFound" -]New value: +[ + "results", + "rows", + "start", + "effectiveQuery", + "numFound", + "truncated" +]
1 tool update
- Changed
orcid_resolve_researcher5 fields changed- added
Output schema / properties / primaryQueryAdded value: +{ + "description": "The primary, most-constrained Solr query attempted first (name + optional anchor + optional affiliation). Always populated; equals queryUsed when no relaxed fallback ran.", + "type": "string" +} - added
Output schema / properties / primaryTotalFoundAdded value: +{ + "description": "Total ORCID records matching primaryQuery. Zero when the primary query found nothing and a relaxed fallback produced the returned candidates.", + "type": "number" +} - changed
Output schema / properties / queryUsed / descriptionPrevious value: -"Solr query sent to ORCID for the primary search."New value: +"The Solr query that produced the returned candidates — the primary query, or the final relaxed query when a fallback ran. Paired with totalFound." - changed
Output schema / properties / totalFound / descriptionPrevious value: -"Total ORCID records matching the primary query."New value: +"Total ORCID records matching queryUsed (the query that produced the returned candidates)." - changed
Output schema / requiredPrevious value: -[ - "candidates", - "queryUsed", - "totalFound" -]New value: +[ + "candidates", + "queryUsed", + "totalFound", + "primaryQuery", + "primaryTotalFound" +]
1 tool update
- Changed
orcid_get_works12 fields changed- added
Input schema / properties / include_external_idsAdded value: +{ + "default": true, + "description": "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.", + "type": "boolean" +} - added
Input schema / properties / limitAdded value: +{ + "default": 50, + "description": "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.", + "maximum": 1000, + "minimum": 1, + "type": "integer" +} - added
Input schema / properties / offsetAdded value: +{ + "default": 0, + "description": "Zero-based index of the first work to return (default 0). Combine with limit to page through the full works list.", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +} - added
Output schema / properties / nextOffsetAdded value: +{ + "description": "Offset to pass on the next call to continue paging. Omitted when this response includes the final work.", + "type": "number" +} - added
Output schema / properties / offsetAdded value: +{ + "description": "Zero-based offset applied to the full works list for this response.", + "type": "number" +} - added
Output schema / properties / returnedCountAdded value: +{ + "description": "Number of works returned in this response, after applying offset and limit.", + "type": "number" +} - added
Output schema / properties / truncatedAdded value: +{ + "description": "True when more works are available beyond this response — fetch them with nextOffset.", + "type": "boolean" +} - changed
Output schema / properties / workCount / descriptionPrevious value: -"Total number of works returned."New value: +"Total works available for this ORCID iD, before offset and limit are applied." - changed
Output schema / properties / works / descriptionPrevious value: -"Works associated with this ORCID iD."New value: +"Works for this ORCID iD, sliced to the requested offset and limit." - changed
Output schema / properties / works / items / properties / externalIds / descriptionPrevious value: -"External identifiers (DOIs, PMIDs, arXiv IDs, ISBNs, etc.)."New value: +"External identifiers (DOIs, PMIDs, arXiv IDs, ISBNs, etc.). Omitted when include_external_ids is false." - removed
Output schema / properties / works / items / requiredRemoved value: -[ - "externalIds" -] - changed
Output schema / requiredPrevious value: -[ - "orcidId", - "orcidUri", - "workCount", - "works" -]New value: +[ + "orcidId", + "orcidUri", + "workCount", + "returnedCount", + "offset", + "truncated", + "works" +]
1 tool update
- Changed
orcid_search_researchers2 fields changed- changed
Input schema / properties / start / descriptionPrevious value: -"Pagination offset (0-based). ORCID Public API caps at 10,000 total results."New value: +"Pagination offset (0-based), 0–10,000. The ORCID Public API rejects start > 10,000 for unauthenticated requests." - changed
Input schema / properties / start / maximumPrevious value: -9007199254740991New value: +10000
1 tool update
- Changed
orcid_get_work_detail18 fields changed- removed
Input schema / properties / put_codeRemoved value: -{ - "description": "Work put-code, available in the put_code field returned by orcid_get_works. Each work group has a unique put-code.", - "exclusiveMinimum": 0, - "maximum": 9007199254740991, - "type": "integer" -} - added
Input schema / properties / put_codesAdded value: +{ + "description": "Array of 1–100 work put-codes to fetch. Put-codes are available in the put_code field returned by orcid_get_works.", + "items": { + "description": "Work put-code (positive integer).", + "exclusiveMinimum": 0, + "maximum": 9007199254740991, + "type": "integer" + }, + "maxItems": 100, + "minItems": 1, + "type": "array" +} - changed
Input schema / requiredPrevious value: -[ - "orcid_id", - "put_code" -]New value: +[ + "orcid_id", + "put_codes" +] - removed
Output schema / properties / abstractRemoved value: -{ - "description": "Abstract or short description, when provided.", - "type": "string" -} - removed
Output schema / properties / citationRemoved value: -{ - "additionalProperties": false, - "description": "Citation metadata, when provided by the depositing system.", - "properties": { - "type": { - "description": "Citation format (e.g. bibtex, formatted-unspecified).", - "type": "string" - }, - "value": { - "description": "Citation string in the specified format.", - "type": "string" - } - }, - "required": [ - "type", - "value" - ], - "type": "object" -} - removed
Output schema / properties / contributorsRemoved value: -{ - "description": "Work contributors with optional roles. May be empty if not deposited.", - "items": { - "additionalProperties": false, - "description": "Work contributor with optional role and ORCID iD.", - "properties": { - "name": { - "description": "Contributor display name or credit name.", - "type": "string" - }, - "orcidId": { - "description": "Contributor ORCID iD (bare format), if linked.", - "type": "string" - }, - "role": { - "description": "Contributor role (e.g. author, editor, conceptualization, data-curation). May be a CRediT taxonomy term.", - "type": "string" - }, - "sequence": { - "description": "Contributor sequence position (first or additional).", - "type": "string" - } - }, - "type": "object" - }, - "type": "array" -} - added
Output schema / properties / errorsAdded value: +{ + "description": "Per-record errors for put-codes that could not be resolved (not found or inaccessible). Empty when all put-codes resolved successfully.", + "items": { + "additionalProperties": false, + "description": "Error entry for a put-code that could not be resolved.", + "properties": { + "message": { + "description": "Error message from ORCID (e.g. not found or access denied).", + "type": "string" + }, + "putCode": { + "description": "Put-code that produced this error, when identifiable.", + "type": "number" + } + }, + "required": [ + "message" + ], + "type": "object" + }, + "type": "array" +} - removed
Output schema / properties / externalIdsRemoved value: -{ - "description": "All external identifiers (DOIs, PMIDs, arXiv IDs, ISBNs, etc.).", - "items": { - "additionalProperties": false, - "description": "External identifier for the work.", - "properties": { - "relationship": { - "description": "Relationship to the work (self or part-of).", - "type": "string" - }, - "type": { - "description": "Identifier type (e.g. doi, pmid, arxiv, isbn, ppr).", - "type": "string" - }, - "url": { - "description": "Resolver URL for this identifier, if available.", - "type": "string" - }, - "value": { - "description": "Identifier value.", - "type": "string" - } - }, - "required": [ - "type", - "value" - ], - "type": "object" - }, - "type": "array" -} - removed
Output schema / properties / journalTitleRemoved value: -{ - "description": "Journal or container title, when provided.", - "type": "string" -} - removed
Output schema / properties / languageCodeRemoved value: -{ - "description": "Language code of the work, when provided.", - "type": "string" -} - removed
Output schema / properties / publicationDateRemoved value: -{ - "description": "Publication date (YYYY, YYYY-MM, or YYYY-MM-DD).", - "type": "string" -} - removed
Output schema / properties / putCodeRemoved value: -{ - "description": "Put-code of this work record.", - "type": "number" -} - removed
Output schema / properties / subtitleRemoved value: -{ - "description": "Work subtitle, when provided.", - "type": "string" -} - removed
Output schema / properties / titleRemoved value: -{ - "description": "Work title.", - "type": "string" -} - removed
Output schema / properties / urlRemoved value: -{ - "description": "URL for the work, when available.", - "type": "string" -} - removed
Output schema / properties / workTypeRemoved value: -{ - "description": "Work type (e.g. journal-article, dataset, software, preprint).", - "type": "string" -} - added
Output schema / properties / worksAdded value: +{ + "description": "Successfully resolved work detail records.", + "items": { + "additionalProperties": false, + "description": "Full detail record for one work.", + "properties": { + "abstract": { + "description": "Abstract or short description, when provided.", + "type": "string" + }, + "citation": { + "additionalProperties": false, + "description": "Citation metadata, when provided by the depositing system.", + "properties": { + "type": { + "description": "Citation format (e.g. bibtex, formatted-unspecified).", + "type": "string" + }, + "value": { + "description": "Citation string in the specified format.", + "type": "string" + } + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + "contributors": { + "description": "Work contributors with optional roles. May be empty if not deposited.", + "items": { + "additionalProperties": false, + "description": "Work contributor with optional role and ORCID iD.", + "properties": { + "name": { + "description": "Contributor display name or credit name.", + "type": "string" + }, + "orcidId": { + "description": "Contributor ORCID iD (bare format), if linked.", + "type": "string" + }, + "role": { + "description": "Contributor role (e.g. author, editor, conceptualization, data-curation). May be a CRediT taxonomy term.", + "type": "string" + }, + "sequence": { + "description": "Contributor sequence position (first or additional).", + "type": "string" + } + }, + "type": "object" + }, + "type": "array" + }, + "externalIds": { + "description": "All external identifiers (DOIs, PMIDs, arXiv IDs, ISBNs, etc.).", + "items": { + "additionalProperties": false, + "description": "External identifier for the work.", + "properties": { + "relationship": { + "description": "Relationship to the work (self or part-of).", + "type": "string" + }, + "type": { + "description": "Identifier type (e.g. doi, pmid, arxiv, isbn, ppr).", + "type": "string" + }, + "url": { + "description": "Resolver URL for this identifier, if available.", + "type": "string" + }, + "value": { + "description": "Identifier value.", + "type": "string" + } + }, + "required": [ + "type", + "value" + ], + "type": "object" + }, + "type": "array" + }, + "journalTitle": { + "description": "Journal or container title, when provided.", + "type": "string" + }, + "languageCode": { + "description": "Language code of the work, when provided.", + "type": "string" + }, + "publicationDate": { + "description": "Publication date (YYYY, YYYY-MM, or YYYY-MM-DD).", + "type": "string" + }, + "putCode": { + "description": "Put-code of this work record.", + "type": "number" + }, + "subtitle": { + "description": "Work subtitle, when provided.", + "type": "string" + }, + "title": { + "description": "Work title.", + "type": "string" + }, + "url": { + "description": "URL for the work, when available.", + "type": "string" + }, + "workType": { + "description": "Work type (e.g. journal-article, dataset, software, preprint).", + "type": "string" + } + }, + "required": [ + "putCode", + "externalIds", + "contributors" + ], + "type": "object" + }, + "type": "array" +} - changed
Output schema / requiredPrevious value: -[ - "orcidId", - "orcidUri", - "putCode", - "externalIds", - "contributors" -]New value: +[ + "orcidId", + "orcidUri", + "works", + "errors" +]
3 tool updates
- Added
orcid_get_research_resources - Added
orcid_get_work_detail - Changed
orcid_get_works1 field changed- added
Output schema / properties / works / items / properties / putCodeAdded value: +{ + "description": "Work put-code — pass to orcid_get_work_detail to fetch the full record including abstract and contributors.", + "type": "number" +}
1 tool update
- Changed
orcid_search_researchers1 field changed- changed
Output schema / requiredPrevious value: -[ - "results", - "numFound", - "rows", - "start", - "effectiveQuery" -]New value: +[ + "results", + "rows", + "start", + "effectiveQuery", + "numFound" +]
7 tool updates
- First observed
orcid_get_affiliations - First observed
orcid_get_funding - First observed
orcid_get_peer_reviews - First observed
orcid_get_profile - First observed
orcid_get_works - First observed
orcid_resolve_researcher - First observed
orcid_search_researchers
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Related MCP Connectors
ORCID public researcher records (works, employment, education)
Research Organization Registry (ROR) — canonical org IDs
OpenAIRE MCP — EU research outputs (publications, datasets, software, projects)
Figshare research outputs (datasets, papers, posters)
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables searching and retrieving organization records from the Research Organization Registry, with fuzzy affiliation matching.13MIT
- AlicenseAqualityDmaintenanceFor AI agents and humans: Discover researchers, publications, datasets, and code repositories across a federated network of researcher digital twins. Compute S-Index impact metrics combining citation data from Semantic Scholar and Google Scholar with code and dataset quality scores from GitHub and Figshare.81MIT
- FlicenseNot gradedqualityFmaintenanceEnables analysis of academic author networks and research collaborations by retrieving co-authors and research keywords from sources like Semantic Scholar, OpenAlex, Crossref, and Google Scholar.2-
Try in Browser
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.