Skip to main content
Glama

crossref-mcp-server

Search Funders

crossref_search_funders
Read-only

Finds funders registered in the Crossref Funder Registry by name or funder DOI. Provide funder_doi for an exact single-funder lookup — the full DOI ("10.13039/100000001"), the bare registry ID ("100000001"), or either behind a doi: or https://doi.org/ prefix — or query for name-based search. Name-query results page with offset — the nextOffset enrichment carries the value for the following page, up to offset + rows = 100000. Set include_works to true to also return a page of works funded by the matched funder; that list pages two ways. works_offset is the simple one and is capped ten times lower at works_offset + rows = 10000. works_cursor has no ceiling and reaches the whole funded-works list: pass works_cursor="*" on the first call, then chain the nextWorksCursor token from each response. The two cannot be combined, and a cursor walk always starts at the newest work — it cannot resume from an offset. This list also counts works funded by the funder's registry descendants, which a crossref_search_works filter on {"funder": "10.13039/"} does not. Returns funder name, registry ID, country, and alternate names. The Funder Registry supersedes entries, and a deprecated one answers to the same names as its successor while carrying only a fraction of its works: such a record carries replacedBy with the superseding registry ID and the response carries a notice naming it. The replacement is never followed automatically — re-run with funder_doi set to that ID to get the current entry.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsNoMaximum funders to return for name queries, or works when include_works is true (1–100, default 10)
queryNoFunder name search query, e.g. "National Science Foundation" or "Wellcome Trust"
offsetNoZero-based offset into the name-query funder list. Pass the nextOffset value from the previous response to continue. Ignored when funder_doi is set, which resolves exactly one record.
funder_doiNoFunder DOI for exact lookup — the full DOI "10.13039/100000001" (NSF) or the bare registry ID "100000001". Supersedes query when provided.
works_cursorNoCursor token for deep paging of the funded-works list when include_works is true. Pass "*" to start the walk at the newest work, then pass the nextWorksCursor value from each response. Has no offset ceiling and cannot be combined with works_offset. Each token runs about 1500 characters and is returned on both result surfaces, a fixed cost per page — raise rows to spread it across more works on a long walk.
works_offsetNoZero-based offset into the funded-works list when include_works is true. Pass the nextWorksOffset value from the previous response to continue. Capped at works_offset + rows = 10000; use works_cursor to read the whole list. Cannot be combined with works_cursor.
include_worksNoWhen true, also return a page of works funded by the matched funder. Requires an unambiguous funder — pass funder_doi when a name query matches more than one.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
noticeNoGuidance on a page that needs a caveat: a query nothing matched, an offset past the end of a list that did match, a page that stops at one of the route offset ceilings with records still unretrieved, or a returned funder that the Funder Registry has deprecated in favor of another entry. Absent otherwise. A page needing more than one caveat carries them all in this one string.
fundersNoMatching funder records
nextOffsetNoValue to pass as offset on the next call for the following page of funders. Absent when this page ends the matches or the next page would breach the 100000-record offset ceiling.
fundedWorksNoPage of works funded by the matched funder, ordered by publication date (newest first). Only present when include_works is true.
funderCountNoNumber of funder records returned in this page
fundersTotalNoTotal funder records matching the query in Crossref
nextWorksCursorNoValue to pass as works_cursor on the next call for the following page of funded works. Present only on a page requested with works_cursor, and absent once the walk reaches the end of the works list.
nextWorksOffsetNoValue to pass as works_offset on the next call for the following page of funded works. Absent when this page ends the works list, the next page would breach the 10000-record offset ceiling, or the page was requested with works_cursor.
fundedWorksTotalNoTotal count of funded works for the matched funder, when include_works is true

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Even with readOnlyHint=true and openWorldHint=true, the description adds rich behavioral detail: pagination ceilings, cursor walk semantics, the inability to combine offset and cursor, descendant work counting, and deprecated-record replacement behavior. It clearly states what the tool does and does not do automatically.

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 dense but every clause earns its place: purpose first, then lookup modes, pagination, works inclusion, and edge-case behavior. No filler or repetition; the ordering follows the natural call flow.

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 7-parameter tool with no required parameters, the description covers accepted ID forms, both pagination mechanisms and their caps, ambiguity requirements, return fields, and the deprecated-registry edge case. With an output schema also present, an agent has everything needed 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.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, but the description goes beyond it by explaining accepted funder_doi formats, nextOffset and nextWorksCursor chaining, the works_cursor='*' start token, the 10000-row offset cap, and the requirement that include_works needs an unambiguous funder. These are operational details not inferable from the schema alone.

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?

Opens with a specific verb and resource: 'Finds funders registered in the Crossref Funder Registry by name or funder DOI.' It immediately distinguishes the two lookup modes and the tool's primary focus from sibling search/get tools.

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?

The description gives explicit when-to-use guidance: use funder_doi for exact lookup, use name query for search, and use include_works for funded works. It also contrasts descendant-inclusive counting with a crossref_search_works filter and tells the agent to re-run with funder_doi after a deprecated entry rather than following the replacement automatically.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.