Skip to main content
Glama

Extract structured fields from papers

extract_from_papers
Read-onlyIdempotent

Pull a structured table out of up to 50 papers in ONE call: you define the columns (fields: each a snake_case name, a type, and an optional description) and an instruction, and the server reads each paper's full text and returns one typed row per paper. Use this when you need the SAME facts across many papers, e.g. "dataset, model size, and reported accuracy for each of these papers": one call reads every paper and returns the table. Pass sections (case-insensitive headings, e.g. ["Results"]) to focus extraction and cut noise. The model is instructed to use only what each paper states, not to infer; a field it can't ground may be absent or null. Each row carries truncated (true when the paper's text overflowed the budget and the tail was dropped, so treat it as partial). A paper with no parsed full text, or one the model couldn't extract, is reported in papers_failed (with a reason) instead of sinking the batch, so papers_processed == rows + failures. Heavy: one model call per paper, so extract only papers you already judged relevant from a search or citation result. For the raw text of a single paper, use get_paper_fulltext instead.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "paper_ids": "<paper_ids>",
      "fields": "<fields>",
      "instruction": "<instruction>"
    },
    "name": "extract_from_papers"
  }
}

Input Schema

NameRequiredDescriptionDefault
fieldsYes1 to 12 fields to extract per paper. Each becomes a typed column on every row, keyed by its `name`.
sectionsNoRestrict extraction to these sections (case-insensitive heading match), e.g. ["Results", "Experiments"]. Omit to consider the whole paper.
paper_idsYes1 to 50 corpus paper UUIDs to extract from in ONE call, from a search_papers / search_papers_many / search_related_papers / get_paper_citations result.
instructionYesNatural-language guidance for the extraction (e.g. "Pull the primary evaluation dataset and the headline accuracy"). The model is told to use only what the paper states.

Output Schema

NameRequiredDescriptionDefault
rowsYesOne row per successfully extracted paper.
papers_failedYesPapers that yielded no row; recorded here instead of sinking the batch. Empty when every paper extracted.
papers_processedYesTotal papers attempted; equals rows.length + papers_failed.length.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds substantial non-obvious behavior: one model call per paper (cost/latency), grounding-only extraction with absent/null fields when unsupported, per-row `truncated` meaning partial text, and batch resilience via `papers_failed` with the invariant papers_processed == rows + failures. That is real context beyond structured fields, though it is presented as a dense block rather than organized under cost, failure, and output headings.

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 action and the columns/instruction/row mental model, then layers cost, grounding, truncation, and failure handling in roughly priority order. It is long for a description and repeats a few schema facts (the `sections` example, max 50 papers), but nearly every clause carries decision-relevant information for a heavyweight tool.

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 costly multi-paper extraction tool with an output schema, this covers exactly the gaps a schema cannot: cost model, grounding guarantees, partial-result signaling, and failure accounting. An agent has enough to decide whether to call it, how to shape columns and instructions, and how to interpret incomplete rows.

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, but the description goes further than the schema: it explains the purpose of `sections` as noise reduction (case-insensitive heading match), frames `fields` as the column definition that becomes row keys, and clarifies why `instruction` exists (natural-language steering with a grounding constraint). It does not add format or sizing guidance beyond what the schema already enforces (1–12 fields, 1–50 ids, 2000-char caps).

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 ("Pull a structured table out of up to 50 papers in ONE call") and immediately defines the mechanism: caller-supplied columns plus an instruction, server reads full text, returns one typed row per paper. It is clearly separable from get_paper_fulltext (raw text of one paper) and from the search tools, which it names as upstream feeders.

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?

Explicit guidance on when it fits ("when you need the SAME facts across many papers") with a concrete example, plus a when-not/alternative: "For the raw text of a single paper, use get_paper_fulltext instead." It also adds an operational precondition — only run it on papers already judged relevant from a search or citation result — which prevents wasteful use.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.