Skip to main content
Glama
amos689

paper-preflight

Find the passages a citation rests on

preflight_cited_passages
Read-onlyIdempotent

Trace sentences that cite a citation key to ranked passages from the cited work, so you can judge whether the claim is supported.

Instructions

For each sentence of the paper that cites key: the claim it makes and the passages of the cited work ranked best for that claim, for you to judge whether the work supports it. The first call downloads the work's text (its arXiv source, an open-access full text or PDF, or else its abstract) into the local cache.

Judge each claim conservatively. Say "confirmed" only when a passage states it (quote the passage word for word) or, for a citation set right after a name such as "Adam \cite{...}", when name_in_title is true. Otherwise say "could not confirm", with the reason: no text, only the abstract, or no passage says it. Never call a citation wrong or invented on this evidence: the text may say it in other words, or be only an abstract. evidence.level is "full_text", "abstract" or "none".

Use it only after preflight_check has verified that the work exists; it answers whether a real work supports a sentence, not whether the reference is correct.

Input Schema

NameRequiredDescriptionDefault
keyYesThe citation key whose citing sentences to trace.
pathNoA LaTeX project folder or .tex file, a Markdown, Quarto or Typst manuscript (.md, .qmd, .typ), a Word manuscript (.docx), or a reference list (.bib, .bbl, .json, .ris, .yml, .txt, .pdf), relative to the workspace root (default: the root itself)..
offlineNotrue: answer only from the local cache and never touch the network (references not cached yet come back as unverified).
max_passagesNoPassages to return per citing sentence, best first (1 to 20).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.0.0
    • addedInput schema / properties / key / description
      Added value: +"The citation key whose citing sentences to trace."
    • addedInput schema / properties / max_passages / description
      Added value: +"Passages to return per citing sentence, best first (1 to 20)."
    • addedInput schema / properties / offline / description
      Added value: +"true: answer only from the local cache and never touch the network (references not cached yet come back as unverified)."
    • addedInput schema / properties / path / description
      Added value: +"A LaTeX project folder or .tex file, a Markdown, Quarto or Typst manuscript (.md, .qmd, .typ), a Word manuscript (.docx), or a reference list (.bib, .bbl, .json, .ris, .yml, .txt, .pdf), relative to the workspace root (default: the root itself)."
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (readOnly/openWorld/idempotent), it discloses a real side effect — the first call downloads the work's text into the local cache — and enumerates the fallback ordering (arXiv source, OA full text, PDF, else abstract). It also explains output semantics (`evidence.level` = full_text/abstract/none) and a behavioral rule for how to treat weak evidence, which no annotation conveys.

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?

It is three dense paragraphs rather than one, but each sentence earns its place (core output, cache behavior, judging rule, evidence levels, boundary with preflight_check). The core 'what you get back' statement is front-loaded, though the download/cache caveat interrupts before the judging guidance.

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 an output schema present, the description need not document return shapes, yet it still clarifies the judging protocol and evidence levels — exactly the ambiguous part an agent would otherwise get wrong. Combined with annotations covering the safety profile and full param coverage, nothing needed to invoke it correctly is missing.

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 description coverage is 100%, so `key`, `path`, `offline` and `max_passages` are already fully documented in the schema, and the description adds little param-level syntax beyond that baseline. The one value-add is contextual: the note that uncached references under `offline` come back unverified, which reinforces what the schema already says.

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 precise verb+resource: for each sentence citing `key`, return the claim and the ranked passages that could support it, so the agent can judge support. It also distinguishes itself from the sibling `preflight_check` by declaring what question it does *not* answer ('whether a real work supports a sentence, not whether the reference is correct'). An agent can route between the two without opening a schema.

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?

It gives an explicit precondition ('Use it only after `preflight_check` has verified that the work exists') plus a clear exclusion ('not whether the reference is correct'), and names the alternative sibling by name. When-to-use and when-not-to-use are both spelled out.

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