crossref-mcp-server

Search Journals

crossref_search_journals

Read-only

Finds Crossref journal records by ISSN or title query. Provide issn for an exact single-journal lookup, or query for title-based search returning up to rows results. Title-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 the matched journal's most recent works by publication date; 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 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. Returns journal metadata: title, publisher, ISSN-L, subject areas, and total DOI count.

Input Schema

TableJSON Schema

Name	Required	Description
`issn`	No	ISSN for exact single-journal lookup (print or electronic, with or without hyphen). Example: "1234-5678".
`rows`	No	Maximum number of journals to return for title queries, or works when include_works is true (1–100, default 10)
`query`	No	Journal title search query, e.g. "Nature" or "Journal of Machine Learning Research"
`offset`	No	Zero-based offset into the title-query journal list. Pass the nextOffset value from the previous response to continue. Ignored when issn is set, which resolves exactly one record.
`works_cursor`	No	Cursor token for deep paging of the journal 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_offset`	No	Zero-based offset into the journal 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_works`	No	When true, also return a page of the journal's most recent works by publication date. Requires an unambiguous journal — pass issn when a title query matches more than one. A journal with no ISSN registered has no addressable works list; the works lookup is then skipped and the notice enrichment says so.

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Present when the call failed. Absent on success.
`notice`	No	Guidance 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 an include_works request that was skipped because the matched journal has no registered ISSN to address its works list by. Absent otherwise.
`journals`	No	Matching journal records
`nextOffset`	No	Value to pass as offset on the next call for the following page of journals. Absent when this page ends the matches or the next page would breach the 100000-record offset ceiling.
`worksTotal`	No	Total works count for the journal, when include_works is true
`recentWorks`	No	Page of works from the matched journal, ordered by publication date (newest first). Requires include_works, and absent even then when the matched journal has no registered ISSN — the works list is addressable by ISSN alone, and the notice enrichment says so.
`journalCount`	No	Number of journal records returned in this page
`journalsTotal`	No	Total journal records matching the query in Crossref
`nextWorksCursor`	No	Value to pass as works_cursor on the next call for the following page of works. Present only on a page requested with works_cursor, and absent once the walk reaches the end of the works list.
`nextWorksOffset`	No	Value to pass as works_offset on the next call for the following page of 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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 19, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds substantial behavior beyond that: pagination ceilings (offset + rows = 100000, works_offset + rows = 10000), cursor semantics (no ceiling, starts at the newest work, cannot resume from an offset, chaining via nextWorksCursor), cursor token size and the rows cost tradeoff, and the failure mode when a journal has no registered ISSN. No contradiction with annotations; the open-world hints (enrichments like nextOffset, notice) are even reinforced.

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?

Information-dense with the core purpose front-loaded in the first sentence; every sentence carries distinct facts with no filler. The ~170-word length is justified by two independent paging systems, though the dense prose would benefit from paragraph breaks to aid scanning.

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?

Complete for a complex 7-parameter tool with dual paging mechanisms: exact and fuzzy lookup, both paging modes with ceilings, the cursor walk protocol, mutual exclusions, prerequisites, a documented skip/failure mode, and the returned metadata fields. An output schema covers return values, so nothing an agent needs to call it 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%, establishing a baseline of 3. The description adds genuine interplay semantics the schema lacks: the offset + rows ceiling arithmetic, the '*' start token protocol for works_cursor, the offset/cursor mutual exclusion, and the include_works prerequisite of an unambiguous journal. This goes beyond what the per-parameter schema descriptions provide.

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?

'Finds Crossref journal records by ISSN or title query' states a specific verb, resource, and the two lookup modes in one sentence. The journal-record scope clearly distinguishes it from sibling tools like crossref_search_works, crossref_search_funders, and crossref_get_member without needing to name them.

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 is dense with explicit when/when-not decision rules: issn for exact lookup vs query for title search, works_offset for simple paging capped at 10000 vs works_cursor for full walks, mutual exclusion of the two, and the directive to pass issn when a title query matches more than one journal. However, it never names sibling tools (e.g., crossref_search_works) as alternatives for cross-tool routing, leaving that to inference from tool names.

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

All crossref-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.