Skip to main content
Glama

campus_research_verify_doi

Read-onlyIdempotent

Verify a DOI by checking Crossref, fallback to DataCite, and report correction or retraction notices. Distinguish true absence from temporary upstream errors; does not certify peer review.

Instructions

Look up an exact DOI in Crossref, then DataCite on a Crossref 404 or temporary 429/503. A temporary Crossref failure plus DataCite 404 remains an upstream error, not proof of absence. Check Crossref correction/retraction notices when available. Does not certify peer review or scientific validity.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
doiYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.1

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the provided annotations, the description discloses the fallback sequence, error interpretation rules, inclusion of correction/retraction notices, and scope limits such as not certifying peer review or scientific validity. This adds substantial behavioral context for an agent.

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 front-loaded with the core lookup behavior, then efficiently covers edge cases and scope limits. Every sentence earns its place, and there is no redundant or filler text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter lookup tool with no output schema, the description covers fallback behavior, error semantics, retraction notices, and scope boundaries. It could say more about the returned record, but the critical invocation and interpretation guidance is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 adds the key semantic that the DOI must be exact, but it does not specify format, normalization, or examples beyond what is implied by the standard DOI format.

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?

The description states a specific verb and resource: look up an exact DOI in Crossref, with DataCite as fallback. It clearly distinguishes the operation from broader research tools by specifying exact-DOI verification and describing retraction/correction checking.

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?

It gives clear conditions for when the DataCite fallback applies (Crossref 404 or 429/503) and warns that temporary Crossref failure plus DataCite 404 is still an upstream error, not absence. It does not explicitly name sibling alternatives, but the usage context is well defined.

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

Deploy Server

Other Tools