Skip to main content
Glama
rezzminator

Professor' Harvester

by rezzminator
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

fetch

Read-only

Retrieve 1–50 documents as Markdown by URL, DOI, ISBN, PMID/PMCID, or harvest handle. Returns content in input order, with per-item errors and a path to the complete artifact for truncated results.

Instructions

Retrieves 1–50 documents as Markdown, input order kept. Call fetch{sources:["https://…","doi:10.…","harvest:…"]} — a URL/path, DOI, ISBN, PMID/PMCID, or a handle from findWorks/searchCache; a title → findWorks first. Each item returns content (may be truncated), size, cache status, and the path to the COMPLETE artifact — read the path for the rest. A failing item carries its own error and the others still return; an empty extraction is reported as that item's error, never as a blank body.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
refreshNoForce a fresh fetch: bypass the cache entirely, re-download, overwrite the cached artifact, and return the NEW content.
sourcesYes1–50 things to fetch, each returned as clean Markdown in the SAME order. Each is a LOCATION or an UNAMBIGUOUS identifier of a DOCUMENT: URL / local path / file://; DOI; ISBN; PMID / PMCID; harvest: handle. Use a DIFFERENT tool for a TITLE (findWorks), an IMAGE (fetchImage), or an archive (archive). A failing item returns a descriptive per-item error and the rest still return.
size_onlyNoWhen true, fetch and cache the full content but return NO body—just {size, chars, path}; full content remains cached at path.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond readOnlyHint, the description discloses important behavioral details: content may be truncated and the path to the full artifact is provided, failing items return their own errors while others still succeed, and empty extractions are reported as errors rather than blank bodies. It also surfaces cache-related behavior, which the annotation does not convey.

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 compact and informative: four sentences cover purpose, call syntax, return shape, and failure behavior without filler. Every sentence earns its place, and core operational constraints are front-loaded.

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?

With no output schema, the description fully explains what each item returns, including truncation, size, cache status, and the path to the complete artifact. Combined with the schema's parameter documentation and the readOnlyHint annotation, an agent has all the context needed to invoke fetch correctly and interpret its results.

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 100%, so the baseline is 3. The description adds meaningful parameter semantics by showing valid source forms (URL, doi:, harvest:) and stating that results preserve input order, which goes beyond the schema's property descriptions. Refresh and size_only remain covered by the schema, so the description did not need to restate them.

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 opens with a precise verb and resource: retrieves 1–50 documents as Markdown while preserving input order. It distinguishes itself from siblings by specifying what fetch accepts (URLs, DOIs, ISBNs, PMID/PMCIDs, harvest handles) and explicitly routes titles to findWorks, images to fetchImage, and archives to archive.

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

Usage Guidelines5/5

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

The description gives concrete usage guidance: identifiers from locations or unambiguous document identifiers go to fetch, while a title should go to findWorks first, with the resulting handle then passed to fetch. The schema reinforces exclusions for titles, images, and archives, leaving no ambiguity about when this tool is the right choice.

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