Skip to main content
Glama
SVerITG

Metis

by SVerITG
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Metis — Verify Doi

verify_doi

Validates a DOI's existence and checks the cited author, year, and title against the record, flagging retractions and corrections to catch fabricated or retracted citations.

Instructions

Tier B — does this DOI exist, match the citation, and is it RETRACTED?

Catches the classic fabricated citation: plausible authors, plausible journal,
no such paper. And the failure nothing in Metis could see before — citing a
paper that has since been retracted, which is worse than a wrong page number
because the claim looks perfectly sourced.

Metadata only: a DOI goes out, bibliographic fields come back. Nothing of the
researcher's leaves the machine, so this stays inside the local-first rule.

A `doi_resolved` verdict means the paper is real, NOT that it supports the
claim. That distinction is the whole point of tiering.

Args:
    doi: The DOI as cited (a full https://doi.org/… URL is fine).
    expect_author: Surname as cited, to check against the record.
    expect_year: Year as cited.
    expect_title: Title as cited.
    record: Append the verdict to the citation ledger (default True).

Returns:
    The verdict, the resolved record, and any retraction or correction flags.

Input Schema

NameRequiredDescriptionDefault
doiYes
recordNo
expect_yearNo
expect_titleNo
expect_authorNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses metadata-only scope, that nothing of the researcher's leaves the machine, and that the response includes retraction/correction flags. It omits operational traits like network dependence on doi.org, behavior for unresolvable malformed DOIs, and rate limits.

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?

Front-loaded with the core question in bold, then rationale, then structured Args/Returns. A few phrases are rhetorical rather than informative ('worse than a wrong page number because the claim looks perfectly sourced'), but they do convey why retraction matters.

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 five-param verification tool with an output schema, the description covers purpose, privacy posture, parameter intent, verdict interpretation, and return shape. An agent has everything needed to call it correctly and to read the result without overclaiming.

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 0%, so the description must compensate, and it documents all five parameters including the meaning of the expect_* fields ('as cited') and the record default. The accept-format hint ('a full https://doi.org/… URL is fine') is genuinely additive, though expect_year and expect_title definitions remain terse.

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 opening line names a specific verb and resource plus three distinct checks: existence, citation match, and retraction status. That scope cleanly separates it from siblings like verify_claim or verify_text_citations, which address claim support rather than record existence.

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 concrete triggers — catching fabricated citations and flagging retracted papers — and explicitly bounds the tool's meaning: 'A doi_resolved verdict means the paper is real, NOT that it supports the claim.' It stops short of naming the sibling to use for claim support, leaving that inference to the agent.

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