crossref-mcp-server

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

Annotations already declare the operation read-only and idempotent, so the bar for additional disclosure is lower. The description adds useful domain context—members are organizations that register DOIs—and spells out the scope of the returned record, including deposit metadata coverage, without contradicting 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?

Three sentences each carry weight: the first defines the action and return contents, the second supplies domain context, and the third provides the chaining workflow. No filler or redundancy is present.

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?

For a single-parameter, read-only tool with an output schema and clear annotations, this description is fully sufficient. It tells the agent what the result means, what questions it answers, and how to obtain the required input via a sibling 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 100%, and the member_id parameter already includes type, positive integer constraint, examples, and a pointer to crossref_get_prefix. The description reinforces the concept of a member ID but does not add significant parameter-level meaning beyond the 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?

The description opens with a specific verb and resource: 'Resolves a Crossref member ID to its publisher/organization record', and enumerates meaningful output categories. It is clearly distinguished from siblings like crossref_get_prefix and the search tools through the member-ID focus.

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?

It explicitly states the prerequisite workflow: 'Resolve a DOI prefix... with crossref_get_prefix, then pass that ID here.' This gives direct guidance on when to use this tool versus its sibling resolver, leaving no ambiguity about sequencing.

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

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

Annotations already mark the tool as read-only and idempotent. The description goes further by disclosing that the prefix record carries only these three facts with no counts, coverage, or flags, and that the returned memberId chains into another tool. This usefully manages agent expectations about output richness.

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?

Three sentences, each earning its place: the first defines the action and output, the second captures the user question, and the third scopes expectations and links to the sibling tool. No redundant phrases 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?

The tool has a single well-documented parameter, a clear output schema, and annotations covering safety. The description completes the picture by explaining what the result means, what it does not contain, and how to chain into crossref_get_member. Nothing essential is missing for correct invocation.

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%, so the schema already fully documents the `prefix` parameter, including the format and the no-suffix requirement. The tool description reinforces this with examples but adds no new semantic information beyond the schema, matching the baseline for high coverage.

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 uses a specific verb ('resolves') and resource ('DOI prefix' to 'owning Crossref member'), and names the exact output: publisher name and numeric member ID. It also differentiates itself from the sibling crossref_get_member by explaining this tool only resolves the prefix, not the full member record.

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 frames the use case clearly with the question 'who publishes DOIs starting with 10.1038?' and explicitly points to crossref_get_member as the next step for a full publisher record. It does not state explicit negative conditions, but the context makes the appropriate invocation scenario obvious.

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

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

Annotations already declare readOnlyHint and idempotentHint, and the description does not contradict them. It adds valuable behavior beyond annotations: pagination semantics with referenceCount and nextOffset, coverage caveats for older/non-participating publishers, and the explicit statement that incoming citations are not available through Crossref.

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?

Five sentences, all information-dense and free of filler. The primary purpose is front-loaded, followed by output characteristics, pagination, caveats, and alternatives in a logical order. Every sentence earns its place.

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 rich input schema, output schema presence, and readOnly annotations, the description is complete. It covers purpose, pagination behavior, limitations, and alternative tools without needing to restate schema fields or return formats.

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 the schema carries most parameter meaning. The description adds value by tying offset to the response's nextOffset value, explaining referenceCount as the full deposited total, and noting that most works fit in one page while long bibliographies require paging.

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 states a specific verb and resource: 'Returns the outgoing reference list for a DOI — the works cited by this paper.' It clearly distinguishes the tool from crossref_get_work by saying resolved DOIs can be looked up with that sibling, and it rules out incoming citations explicitly.

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 tells the agent when to use this tool (for works cited by a paper), identifies crossref_get_work as the follow-up for resolved DOIs, and directs incoming-citation use cases to OpenAlex. It also warns about coverage variability by publisher, preventing false expectations.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses important runtime behavior: author-list pagination with authorCount, offset, limit, and nextOffset semantics; referencesCount as a count only; and isReferencedByCount as an incoming-count field whose underlying works are not available via Crossref. These are concrete behavioral details an agent needs to correctly interpret responses and continue paging.

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 dense but every sentence earns its place: purpose, pagination mechanics, reference count behavior, and citation-count limitations. It is appropriately front-loaded with the tool's main job, then covers edge cases an agent would otherwise discover only at runtime.

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 rich output schema and the read-only, idempotent annotations, the description covers all essential operational knowledge: what fields are returned, how to page through large author lists, which related data is out of scope, and which sibling tool to use for that data. An agent can invoke and interpret this 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 already covers DOI format, limit, and offset with 100% coverage, so the baseline is 3. The description adds cross-parameter meaning by explaining that only the author list is paged, that limit defaults to 25, that nextOffset should be passed back as offset, and that all other fields are returned in full on every page. This goes beyond the schema's individual field 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 opens with a specific verb and resource: 'Resolves a DOI to its full Crossref metadata record' and enumerates the concrete fields returned. It also distinguishes itself from siblings by explicitly routing reference entries to crossref_get_references and citing works to OpenAlex, so an agent cannot confuse it with the search or reference tools.

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 states when to use the tool — when you have a DOI and need the full metadata record — and gives explicit when-not guidance: outgoing references come from crossref_get_references, and citation graphs are not available through Crossref at all, pointing to OpenAlex instead. This gives clear alternatives and exclusions.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to repeat those. It adds substantial behavioral detail beyond annotations: offset paging capped at ~10K, cursor-based paging for deeper results, the rule that cursor and offset cannot be combined, the behavior of authorLimit (at most that many authors, full total in authorCount), and the signal for list exhaustion (nextCursor absent). These are non-obvious and critical for correct invocation.

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 dense but well-organized. The first sentence states the core purpose and scale. Subsequent sentences cluster related concepts: query types, filters, sort, author limits, and paging. No sentence is redundant; every clause adds operational detail an agent needs. It is long but not bloated, with front-loaded intent and clear progression.

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 13 parameters, a nested filter object, and an open-world dataset, the description covers all operational facets: multiple search modes, filter constraints, sort options, author pagination, and deep paging with cursor. It references crossref_get_work for complementary functionality. With the output schema present and annotations declaring read-only and open-world behavior, nothing essential is missing for 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.

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 significant meaning beyond the schema: it explains the purpose of queryBibliographic (whole-citation match to resolve to DOI), the string-value requirement for boolean filter keys, the rationale for authorLimit in large-collaboration papers, and the mechanics of cursor paging. This is more than just restating the schema, but some parameters (e.g., rows, sort, order) are adequately described by the schema alone, so a 4 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 opens with a precise verb and resource: 'Searches the Crossref works index (~155M records) by free text and/or structured filters.' It clearly states what the tool does and the scope of the index. The mention of structured filters and field-specific parameters distinguishes it from sibling search tools for funders and journals, and from crossref_get_work which retrieves single 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?

Provides explicit guidance on choosing among search modes (generic query vs. queryTitle, queryAuthor, queryContainerTitle, queryBibliographic) with examples. It also explains when to use crossref_get_work: when a work's author list is truncated by authorLimit. Paging behavior (offset vs. cursor) is clearly directed, including the exact mechanism to start and end cursor-based paging.

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