Provides tools to search and retrieve metadata for works, journals, funders, members, types, and licenses via the Crossref REST API, which is a DOI registration agency.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@crossref-mcp search for papers on quantum computing"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Crossref REST API MCP server. Wraps the public Crossref REST API (works, journals, funders, members, types, licenses) — no API key required.
Related MCP server: paper-search-mcp
Tool | Parameters | Description |
|
| Search Crossref works (publications) |
|
| Full metadata for a single work by DOI |
|
| Registration agency for a DOI |
|
| List or search journals |
|
| Journal metadata by ISSN |
|
| Works published in a journal |
|
| List or search funding bodies |
|
| Funder metadata by Funder Registry ID |
|
| List or search Crossref members (publishers) |
| none | Available work types and licenses |
Variable | Required | Description |
| no | Email address for Crossref's "polite pool" — higher rate limits, faster responses |
Only requirement: uv (https://docs.astral.sh/uv/). Nothing else to install.
claude mcp add crossref-mcp -- uvx --from git+https://github.com/dam2452/crossref-mcp.git crossref-mcpWith the polite pool email set:
claude mcp add crossref-mcp -e CROSSREF_MCP_MAILTO=you@example.com -- uvx --from git+https://github.com/dam2452/crossref-mcp.git crossref-mcp{
"mcpServers": {
"crossref-mcp": {
"command": "uvx",
"args": ["--from", "git+https://github.com/dam2452/crossref-mcp.git", "crossref-mcp"],
"env": { "CROSSREF_MCP_MAILTO": "you@example.com" }
}
}
}After pushing a new version: uv cache clean and restart the client.
uv run --directory . crossref-mcpTests (manual):
uv run --directory . --with pytest pytest test/Get metadata for a single funder identified by its Funder Registry ID.
Examples: get_funder(funder_id="100000001")
| Name | Required | Description | Default |
|---|---|---|---|
| funder_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Get metadata', omitting key behavioral traits such as idempotency, read-only nature, potential errors, or authentication requirements. This is insufficient for a tool with zero annotation coverage.
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 with two sentences and a concrete example. It is front-loaded with the purpose. However, it could slightly expand on parameter details without losing conciseness, justifying a 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (context signal), the description need not detail return values. For a simple get tool with one parameter, the description is minimally adequate but lacks guidance on usage context relative to siblings and behavioral expectations, leaving it at a baseline 3.
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 0% schema description coverage, the description should compensate. It adds 'Funder Registry ID' via example but does not elaborate on the expected format, constraints, or valid values for 'funder_id', providing little additional meaning beyond the schema's type declaration.
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 'Get metadata for a single funder', specifying the verb (Get), resource (metadata for a funder), and scope (single). It distinguishes from the sibling 'list_funders' which retrieves multiple funders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates use with a specific Funder Registry ID via the example. While it doesn't explicitly state when not to use or mention alternatives, the contrasting sibling 'list_funders' implies this is for individual lookups, providing adequate context for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata for a single journal identified by its ISSN.
Examples: get_journal(issn="0028-0836")
| Name | Required | Description | Default |
|---|---|---|---|
| issn | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'get metadata' without disclosing read-only nature, error behavior, rate limits, or what happens for invalid ISSN. Minimal transparency.
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 short and front-loaded with purpose. The example is helpful. It is appropriately sized for a simple tool, though slightly brief.
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?
With an output schema present, return values are covered. However, the description lacks details about error cases, format of metadata, or any prerequisites. Sufficient for a simple get-by-id tool but could be more complete.
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 0%, and the description only mentions 'issn' in the example. While this adds marginal value, it does not provide additional semantics beyond what the schema gives. For a single required parameter, more detail could be given.
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 it retrieves metadata for a single journal using ISSN. It specifies the resource and identifier, distinguishing it from sibling tools like list_journals (list multiple) or get_journal_works (different resource).
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 implicitly tells when to use (single journal by ISSN), but does not explicitly state when not to use or mention alternatives. The sibling tool list provides context, but the description itself lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List works published in a journal identified by its ISSN.
Examples: get_journal_works(issn="0028-0836", rows=10) get_journal_works(issn="0028-0836", query="crispr", cursor="*")
| Name | Required | Description | Default |
|---|---|---|---|
| issn | Yes | ||
| rows | No | ||
| query | No | ||
| cursor | No | ||
| filter | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states the basic function without disclosing behavior such as error handling, pagination limits, or side effects. Examples hint at cursor for pagination but do not explain it fully.
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 extremely concise with a single sentence and two examples. There is no filler or redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks details on parameter semantics, pagination, and response handling. The examples provide some context but are insufficient for full understanding of tool behavior.
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 0%, and the description does not explain parameters beyond the examples. Semantics for 'query', 'filter', 'cursor', and 'offset' are not clarified, leaving the agent to infer from examples.
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 'List' and resource 'works' with the required identifier 'ISSN'. It distinguishes from siblings like search_works (general search) and get_journal (journal metadata), making the purpose specific.
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?
No guidance on when to use this tool vs alternatives like search_works. The description does not provide exclusions, prerequisites, or contextual cues for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full metadata for a single work identified by its DOI.
Examples: get_work(doi="10.1038/nature12373") get_work(doi="10.1001/jama.2020.7681")
| Name | Required | Description | Default |
|---|---|---|---|
| doi | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It describes a read-only operation ('Get') but does not disclose any additional behavioral aspects like authentication, rate limits, or error handling.
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 brief (two sentences) with clear examples, front-loading the core purpose. Every part is useful with no wasted 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?
The description states it gets 'full metadata', and an output schema exists, so return values are covered. However, it lacks context on safety, authentication, or error conditions, which would be helpful for a complete picture.
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 schema has no description for the 'doi' parameter (0% coverage), but the description and examples explain it is a DOI string. This adds meaning beyond the schema, though more detail about format or validation could be beneficial.
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 'Get' and the resource 'full metadata for a single work' identified by DOI, which distinguishes it from sibling tools like search_works (for searching multiple works) and get_work_agency (for agency info).
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 implies usage when you have a DOI and want full metadata, with examples. It does not explicitly exclude alternative tools or state when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the registration agency responsible for a given DOI.
Examples: get_work_agency(doi="10.1038/nature12373")
| Name | Required | Description | Default |
|---|---|---|---|
| doi | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lacks any behavioral details such as error handling, permissions, rate limits, or response characteristics beyond the basic action.
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?
Description is very concise (one sentence plus example) and front-loaded. However, it is perhaps too brief given the lack of behavioral details.
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?
Tool is simple (one parameter, output schema exists). Description is adequate for basic understanding but lacks mention of error scenarios or additional constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaning by clarifying the parameter is a DOI and provides an example, going beyond the bare schema which only specifies type string.
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 'Get' and the resource 'registration agency responsible for a given DOI'. It specifies the input (DOI) and distinguishes from siblings like get_funder or get_work.
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 does not explicitly state when to use vs alternatives, only implies by naming the resource. No when-not-to-use or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or search funding bodies in the Crossref Funder Registry.
Examples: list_funders(query="national science", rows=10) list_funders(filter="location:United States", rows=5)
| Name | Required | Description | Default |
|---|---|---|---|
| rows | No | ||
| query | No | ||
| filter | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full burden for behavioral disclosure. It does not address important traits like read-only nature, pagination behavior (rows default is 20, but no max), authentication needs, or rate limits. The brief description fails to adequately warn or inform the agent about side effects or constraints.
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?
Description is very concise (two lines plus examples) with no wasted words. However, it could be slightly expanded to cover missing parameter details without losing conciseness. Front-loads the core purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, description does not need to detail return values. However, it lacks context on pagination limits, default behavior, and scope (e.g., registry coverage). The examples provide partial context but are not sufficient for a complete understanding. A moderately adequate description for a straightforward listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides examples for 'query' and 'rows', but does not explain 'filter' or 'offset' parameters. The meaning of 'filter' (e.g., location:United States) is shown in an example but not formally described. Overall, the description adds limited semantic value beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List or search funding bodies in the Crossref Funder Registry', providing a specific verb ('list or search') and resource ('funding bodies'). It distinguishes from siblings like 'get_funder' (single funder) and 'get_journal' (different resource).
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?
No explicit guidance on when to use this tool vs. alternatives. Examples show usage patterns but lack criteria for choosing this over sibling tools like 'search_works' or 'list_members'. No when-not-to-use or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or search Crossref journals by free-text query.
Examples: list_journals(query="nature", rows=5) list_journals(cursor="*", rows=50)
| Name | Required | Description | Default |
|---|---|---|---|
| rows | No | ||
| query | No | ||
| cursor | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It does not disclose pagination behavior (e.g., cursor-based vs offset), rate limits, or what happens with empty queries. The presence of an output schema partially mitigates but the description itself is silent.
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 (one line plus examples) and front-loaded with the core purpose. However, it could be restructured to include parameter explanations without increasing length significantly.
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 4 parameters with no descriptions and an output schema, the description is insufficient. It omits details on pagination (cursor vs offset), query syntax, and default behavior. The examples are helpful but do not provide complete guidance for an agent to use the tool correctly without additional context.
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 has 0% description coverage, and the description does not explain each parameter beyond the examples. The examples show usage but do not define semantics for cursor, offset, or query format. The description adds minimal meaning beyond what schema provides.
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 that the tool lists or searches Crossref journals by free-text query, distinguishing it from sibling tools like get_journal (specific journal) and search_works (works search). Examples further reinforce the purpose.
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 no guidance on when to use this tool vs alternatives, such as get_journal or search_works. It also does not explain when to use cursor vs offset for pagination. Examples show usage but lack explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List or search Crossref members (publishers).
Examples: list_members(query="elsevier", rows=5) list_members(filter="has-public-references:true", rows=10)
| Name | Required | Description | Default |
|---|---|---|---|
| rows | No | ||
| query | No | ||
| filter | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'list or search' and gives examples, but does not disclose pagination behavior, default return size, or any safety/mutation characteristics. The agent gains minimal behavioral insight.
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: one sentence plus two relevant examples. It efficiently conveys purpose and usage patterns with no wasted words. However, it could be slightly improved by front-loading a brief parameter explanation.
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?
With 4 parameters, 0% schema coverage, and an output schema, the description is insufficient. It lacks explanation of pagination, default behaviors, filter syntax, and offset usage. Despite having an output schema, the description fails to provide a complete understanding for an agent.
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 0%, so the description must compensate. The examples illustrate query and filter usage, giving some context for rows and the search string. However, offset is not mentioned at all, and the full semantics of filter values are unclear.
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 'List or search Crossref members (publishers),' which specifies the verb and resource. It distinguishes from sibling tools like get_funder and list_funders, but does not explicitly differentiate from list_funders, so it lacks full sibling differentiation.
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 examples but no explicit guidance on when to use this tool vs alternatives. There is no mention of when-not-to-use or context for choosing this over sibling tools like list_funders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Crossref work types and the licenses seen in the corpus.
Examples: list_types_and_licenses()
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not reveal any behavioral traits (e.g., no pagination, filtering, or data freshness information). With no params, the behavior is trivial but still lacks any 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?
Very short and includes a code example. Each sentence is concise, but could be front-loaded with the key action.
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 zero parameters and an output schema exists, the description is adequate but lacks any extra context about output structure or data scope.
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?
No parameters exist, so schema coverage is 100%. Description adds no parameter info, but baseline of 4 is appropriate as there is nothing to explain.
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 lists 'available Crossref work types and the licenses seen in the corpus', using specific verb and resource. Distinguishes from siblings (e.g., list_funders, list_journals) by its unique combination.
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?
No guidance on when to use this tool versus alternatives. No context on typical use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Crossref works (publications) by free-text query and/or filters.
Use cursor="*" for deep pagination beyond 10 000 results; the response
includes next-cursor for subsequent pages. Mixing cursor with offset
is not supported — when cursor is set, offset is dropped automatically.
Examples: search_works(query="machine learning", rows=5) search_works(filter="from-pub-date:2024-01-01,until-pub-date:2024-12-31", sort="published", order="desc") search_works(query="crispr", select="DOI,title,author,published", cursor="*")
| Name | Required | Description | Default |
|---|---|---|---|
| rows | No | ||
| sort | No | ||
| order | No | ||
| query | No | ||
| cursor | No | ||
| filter | No | ||
| offset | No | ||
| select | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses pagination behavior (cursor vs offset, automatic offset drop). No annotations provided, so description should cover more behavioral traits like rate limits, authentication, or response side effects; these are missing.
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, well-structured with explanation and three clear examples. No unnecessary 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?
Explains core functionality and pagination. With output schema present, return values are covered. Could mention default sort order behavior, but overall sufficient for an 8-parameter 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?
Description explains cursor, offset, filter, sort, order, query, rows, select with examples and conflict behavior. Compensates for 0% schema coverage by adding meaning beyond type/defaults.
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 searches Crossref works (publications) by free-text query and/or filters. Distinguishes from sibling tools like get_work (DOI lookup) and list_funders.
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?
Provides guidance on deep pagination with cursor, warns against mixing cursor and offset, and offers examples. Lacks explicit exclusion scenarios (e.g., when to use get_work instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_funderget_journalget_journal_worksget_workget_work_agencylist_funderslist_journalslist_memberslist_types_and_licensessearch_worksEach tool targets a unique entity or operation (funder, journal, work, member, license), with clear boundaries between general search and entity-specific lookups.
All tools follow a consistent verb_noun pattern using snake_case (e.g., get_funder, list_journals, search_works), making the action and target immediately clear.
10 tools is well-scoped for the domain of querying Crossref metadata, covering all major entity types without unnecessary redundancy.
The tool set provides get and list/search for all core entities (works, journals, funders, members) plus additional utilities (work agency, types/licenses), leaving no obvious gaps for a read-only API.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search 150M+ academic works, journals, and funders via Crossref API.
Crossref MCP — wraps the Crossref REST API (academic papers, free, no auth)
Scholarly search: OpenAlex, Crossref, arXiv, OpenCitations and PubMed in one endpoint.
Access the OpenAlex academic research catalog — 270M+ publications.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dam2452/crossref-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server