Skip to main content
Glama
SAKURAfan1023

Scholar Library

verify_work

Cross-check a work's DOI and title against Crossref, record evidence and query timestamps, and surface retraction or update notices. No retraction found does not guarantee reliability.

Instructions

联网核对DOI与标题及Crossref更新通知,保留证据和查询时间;未查到撤稿不等于可靠。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
work_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare openWorldHint=true, readOnlyHint=false and destructiveHint=false, and the description is consistent with them, adding that evidence and query time are retained (explaining the write behavior implied by readOnlyHint=false) and that absence of a retraction does not imply reliability. That limitation caveat is genuinely useful behavior/interpretation context the annotations cannot convey.

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?

One dense sentence plus a semicolon-delimited caveat, with the core action front-loaded and zero filler. It is efficient, though the terse phrasing leaves selection criteria compressed rather than explicit.

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

Completeness3/5

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

With no output schema and a 1-param tool, the description covers the network/source behavior and a key interpretive caveat but omits parameter format and any usage routing. It is adequate but leaves real gaps for an agent deciding how to call it correctly.

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 coverage is 0% for the single required work_id, so the schema contributes nothing. The description only indirectly implies what work_id is (a DOI/title-bearing work identifier) without stating format, accepted identifier types, or whether an internal ID or DOI string is expected.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: online verification of a work's DOI and title against Crossref. The scope (DOI/title cross-check, retraction status) distinguishes it from generic siblings like resolve_identifier or search_literature. It names its external source, which sharpens the purpose further, though it does not explicitly contrast itself with any sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied – call it to verify a work's DOI/title and pick up Crossref update notices – but there is no explicit when-to-use vs. when-to-use-something-else, and no alternatives named among the many verification/search siblings. The retraction caveat is interpretive guidance, not tool-selection guidance.

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