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 7 of 7 tools scored.
Each tool targets a distinct ORCID data type (affiliations, funding, peer reviews, profile, works) or search/disambiguation operation. No overlap in functionality.
All tools follow a consistent 'orcid_<verb>_<noun>' pattern with clear verbs (get, resolve, search) and nouns describing the resource.
Seven tools cover the core ORCID use cases (retrieving all major data sections, resolving names, and searching) without being excessive or insufficient.
The tool set fully covers reading public ORCID data: profile, works, affiliations, funding, peer reviews, plus disambiguation and search. No obvious gaps for a read-only server.
Available Tools
7 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_worksGet ORCID Researcher WorksARead-onlyIdempotentInspect
Retrieve works associated with an ORCID iD — publications, datasets, software, preprints, and more. Returns work summaries with titles, types, publication dates, journal names, and all external identifiers (DOIs, PMIDs, arXiv IDs, ISBNs). External IDs are ready for chaining to Crossref, PubMed, or arXiv servers. The /works endpoint returns summaries only — pass DOIs to Crossref or PMIDs to PubMed to retrieve full metadata or abstracts. Works are self-reported; a researcher may not have linked all their publications.
| Name | Required | Description | Default |
|---|---|---|---|
| orcid_id | Yes | ORCID iD — bare format (0000-0001-2345-6789) or full URI (https://orcid.org/0000-0001-2345-6789). |
Output Schema
| Name | Required | Description |
|---|---|---|
| works | Yes | Works associated with this ORCID iD. |
| notice | No | Note when the works list is empty — may indicate no self-reported works or private visibility settings. |
| orcidId | Yes | Normalized ORCID iD (bare format). |
| orcidUri | Yes | Full ORCID URI. |
| workCount | Yes | Total number of works returned. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description discloses that results are summaries only, external IDs are ready for chaining, and works are self-reported (may be incomplete). No contradictions 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 concise (5 sentences), front-loaded with the core action, and each sentence adds relevant 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?
Despite the simple input (1 parameter) and presence of output schema, the description covers the return type, chaining possibilities, and data quality caveat, making it complete for effective use.
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%, and the description does not add significant meaning beyond the schema's description of the orcid_id parameter. The baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'works associated with an ORCID iD', and enumerates the specific data returned (titles, types, publication dates, journal names, external identifiers). It is distinct from sibling tools like 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use this tool (for summaries) and advises chaining to external servers (Crossref, PubMed) for full metadata. However, it does not explicitly exclude alternatives among the sibling ORCID tools, though context distinguishes them clearly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orcid_resolve_researcherResolve ORCID ResearcherARead-onlyIdempotentInspect
Disambiguate an author name to a verified ORCID iD. Returns up to 5 ranked candidates with transparent disambiguation signals: name match type (exact/partial/other-name/none), institution overlap flag, and whether a DOI or PMID anchor was used in the query. A DOI or PMID anchor is near-deterministic — it filters to researchers who have linked that specific work to their ORCID record. Use this tool (not orcid_search_researchers) when the input is an ambiguous name that needs ranked disambiguation. No synthetic scores are used — raw signals only.
| Name | Required | Description | Default |
|---|---|---|---|
| doi | No | DOI of a work authored by this researcher. Acts as a near-deterministic anchor — filters to researchers who linked this DOI to their ORCID record. | |
| name | Yes | Author name to disambiguate (full name preferred, e.g. "Jennifer Doudna" or "J. Doudna"). | |
| pmid | No | PubMed ID of a work authored by this researcher. Acts as a near-deterministic anchor — filters to researchers who linked this PMID to their ORCID record. | |
| rows | No | Maximum candidate count to return (1–20). Defaults to 5. | |
| affiliation | No | Researcher's institution or organization name. Used for institution overlap scoring and optionally as a search constraint. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Recovery hint when no candidates are found or when the anchor query failed to match. |
| queryUsed | Yes | Solr query sent to ORCID for the primary search. |
| candidates | Yes | Ranked candidates, ordered by name match quality then institution overlap. |
| totalFound | Yes | Total ORCID records matching the primary query. |
| relaxedQuery | No | Solr query used in a secondary relaxed search, if the primary returned no results. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses output details: up to 5 ranked candidates, transparent signals (name match type, institution overlap, anchor usage), and raw signals only. Annotations already provide readOnlyHint, openWorldHint, idempotentHint; description adds valuable context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise single paragraph with clear structure: purpose, output, guidance, raw signals. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, full annotations, output schema, and sibling context, the description is complete. It covers when to use, what signals are returned, and key behaviors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3. Description adds meaning by explaining DOI/PMID as near-deterministic anchors and mentioning signals returned, which is helpful beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it disambiguates an author name to a verified ORCID iD. Distinguishes from sibling orcid_search_researchers by specifying it is for ambiguous names needing ranked disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use this tool over orcid_search_researchers when input is an ambiguous name needing ranked disambiguation. Also explains the near-deterministic nature of DOI/PMID anchors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orcid_search_researchersSearch ORCID ResearchersARead-onlyIdempotentInspect
Search the ORCID registry using structured field parameters or raw Solr syntax. All provided structured params are ANDed together. The query field appends raw Solr syntax to the generated clause. Returns ORCID iDs with inline name and institution data — no follow-up profile fetches needed for basic disambiguation. For ranked disambiguation of an ambiguous author name, use orcid_resolve_researcher instead. The ORCID Public API caps results at 10,000 — use pagination for large result sets.
| Name | Required | Description | Default |
|---|---|---|---|
| doi | No | DOI to anchor the search. Returns researchers who have linked this DOI to their ORCID record. | |
| pmid | No | PubMed ID to anchor the search. Returns researchers who have linked this PMID to their ORCID record. | |
| rows | No | Maximum results to return (1–1000). | |
| query | No | Raw Solr query string appended to the generated clause with AND. Supports all ORCID Solr fields and boolean operators. | |
| start | No | Pagination offset (0-based). ORCID Public API caps at 10,000 total results. | |
| ror_id | No | ROR organization ID to filter by (full URL, e.g. https://ror.org/00f54p054). Returns researchers affiliated with this organization. | |
| keyword | No | Keyword to search in the researcher's keyword fields. Phrase match. | |
| given_name | No | Researcher's given (first) name. | |
| affiliation | No | Organization name to filter by. Phrase match. | |
| family_name | No | Researcher's family (last) name. |
Output Schema
| Name | Required | Description |
|---|---|---|
| rows | Yes | Number of results returned in this response. |
| start | Yes | Pagination offset used for this response. |
| notice | No | Recovery hint when results are empty or pagination overshoots the total. Absent on successful pages. |
| results | Yes | Matching researchers with inline name and institution data. |
| numFound | Yes | Total number of matching records in ORCID (before pagination). |
| effectiveQuery | Yes | Solr query sent to the ORCID API. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it explains the return data (inline name and institution) so no follow-up needed, describes how query appends raw Solr, and notes the API cap. This is valuable since annotations already declare readOnly, idempotent, and openWorld hints.
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 compact (5 sentences) and front-loaded with the main purpose. Every sentence serves a clear purpose with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, an output schema, and rich annotations, the description covers all key aspects: search behavior, parameter interaction, return format, alternatives, and limitations. It is complete for an AI agent to use effectively.
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?
All 10 parameters have schema descriptions (100% coverage), so baseline is 3. The description adds value by explaining that structured params are ANDed together and how the query field works, which enhances understanding beyond individual parameter 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 searches the ORCID registry using structured field parameters or raw Solr syntax. It specifies that structured params are ANDed and the query field appends raw Solr syntax. It distinguishes from sibling tool orcid_resolve_researcher by noting that this tool is for searching, not for ranked disambiguation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool and when to use an alternative (orcid_resolve_researcher for ranked disambiguation). It also mentions the 10,000 result cap and pagination, giving clear operational context.
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!