Skip to main content
Glama
SAKURAfan1023

Scholar Library

search_literature

Search Crossref, OpenAlex, arXiv, and PubMed for a project, report source successes and failures, and save queries/results without auto-including or downloading; uses project request budget.

Instructions

在crossref/openalex/arxiv/pubmed检索,分别报告失败及成功。保存检索式与结果,不自动纳入或下载;会消耗项目请求预算。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
sourcesYes
project_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 readOnlyHint=false, openWorldHint=true, destructiveHint=false; the non-readOnly hint is consistent with the stated 'saves query and results'. The description adds genuinely new behavioral context beyond the annotations: per-source failure reporting, no automatic inclusion/download, and that the call '会消耗项目请求预算' (consumes the project request budget) — a cost/rate signal 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?

Three tight clauses, front-loaded with the sources and the search action, followed by output behavior and cost. No filler, though the clauses are compressed to the point of terseness.

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?

For a 4-parameter, 0%-coverage tool with no output schema, the description covers source values, side effects, and budget cost, but omits what the return payload actually looks like (per-source result lists? stored record IDs?) and the meaning of limit/project_id. Adequate but with clear gaps.

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% with no enums, so the description carries extra weight. It usefully enumerates the valid source identifiers (crossref/openalex/arxiv/pubmed) that the 'sources' array accepts, which the schema does not. It says nothing about limit, query, or project_id, leaving half the parameters unexplained.

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?

The description states a specific verb (检索/search) and enumerates the four external resources searched (crossref/openalex/arxiv/pubmed), making it distinguishable from the local-library sibling search_library. It also specifies the reporting shape (per-source success/failure). Strong, though it never explicitly contrasts itself with search_library.

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?

It implies a discovery-only role by stating '不自动纳入或下载' (does not auto-include or download), which tells the agent this is not import_references or download_fulltext. However, it never names those alternatives or states the prerequisite/context for choosing this tool, leaving the routing to inference.

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