paper-preflight

Overview Schema Source Related Servers Discussions Admin

Check a paper's references

preflight_check

Read-onlyIdempotent

Verify every cited reference in a LaTeX project or .bib file against real scholarly records, checking citation keys, metadata, and retractions.

Instructions

Verify every cited reference of a LaTeX project (or a .bib file) against real scholarly records, and check citation keys and the bibliography.

Returns a summary (error/warning counts, one verdict per reference, whether the run was complete) and the findings, most severe first, max_findings at a time; call again with offset=next_offset for more. complete: false means a source was unavailable, so the paper cannot be declared clean yet. offline: true answers from the local cache only. The first run of a paper may take a minute or two (progress is reported while the references are searched); later runs are served from the cache.

Use this first, on the whole paper. Use preflight_explain to understand a finding, preflight_bib_fix to get the corrections as a diff, and preflight_bib_lookup to get a single entry.

Input Schema

Name	Required	Description	Default
`lang`	No	Language of the messages: English or Chinese.	en
`path`	No	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).	.
`offset`	No	Where to start in the findings: 0 first, then `next_offset`.
`offline`	No	true: answer only from the local cache and never touch the network (references not cached yet come back as unverified).
`include_info`	No	Also return info findings (suggestions), not only errors.
`max_findings`	No	How many findings to return in this call (at least 1).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv1.0.0Oct 16, 2026

addedInput schema / properties / include_info / description

Added value: +"Also return info findings (suggestions), not only errors."

addedInput schema / properties / lang / description

Added value: +"Language of the messages: English or Chinese."

addedInput schema / properties / max_findings / description

Added value: +"How many findings to return in this call (at least 1)."

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 / offset / description

Added value: +"Where to start in the findings: 0 first, then `next_offset`."

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)."

First observedv0.1.0Oct 7, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly/idempotent/openWorld); the description adds the operational traits an agent needs -- findings ordered most-severe-first, max_findings paging, complete:false meaning a source was unavailable, offline:true serving cache-only, and first-run latency of a minute or two with progress reporting. This is behavior well beyond what the annotations declare.

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?

Front-loaded with purpose, then returns semantics, then paging/caching caveats, then sibling routing -- a natural read order with no filler sentences. The only slight overlap is the offline/cache explanation, which also appears in the schema, but it earns its place as a run-level caveat.

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 6-parameter, zero-required tool with an output schema, the description covers everything an agent must know to call it correctly and to interpret a partial result: paging loop, cache/offline tradeoff, latency expectations, and the meaning of complete:false.

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 description coverage is 100%, so the baseline is 3. The description additionally supplies the orchestration semantics for pagination (offset=next_offset to continue), the caching/offline interaction, and what a partial run means, which goes modestly beyond the schema text.

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?

States a specific verb and resource -- verifying every cited reference of a LaTeX project or .bib file against real scholarly records, plus citation-key and bibliography checks. It is clearly distinguishable from siblings preflight_bib_lookup (single entry), preflight_bib_fix (diff) and preflight_explain (finding explanation).

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?

Explicitly says "Use this first, on the whole paper" and then routes to each sibling with the condition that selects it (explain a finding, get corrections as a diff, get a single entry). Pagination usage is also given ("call again with offset=next_offset").

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

Deploy Server