paper-preflight
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| S2_API_KEY | No | Semantic Scholar as a rescue source for references nobody else found. Optional; values are never printed or logged. | |
| OPENALEX_API_KEY | No | A larger OpenAlex budget for retraction checks. Optional; values are never printed or logged. | |
| PAPER_PREFLIGHT_EMAIL | No | Crossref's polite pool: faster, more reliable lookups. Optional; values are never printed or logged. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| preflight_checkA | 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, |
| preflight_explainA | Explain a paper-preflight rule (for example REF003 or CIT001): what it detects, its default severity, the message template and whether a fix can be applied safely. |
| preflight_bib_lookupA | Get a BibTeX entry for a DOI, an arXiv ID or a title, built from the registry record
instead of written from memory. Give
|
| preflight_bib_fixA | Propose edits to the .bib files, taken from the verified records, as a unified diff. Nothing is written: apply the diff with your own editing tools.
|
| preflight_cited_passagesA | For each sentence of the paper that cites 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 |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool has a clearly distinct action: verify references, explain a rule, look up a BibTeX entry, propose .bib diffs, and gather cited passages. The check/fix and check/cited_passages pairs are separated by verb (verify vs edit vs ground claims) and the descriptions reinforce the boundaries.
All names share the preflight_ prefix and snake_case form with a predictable verb/noun tail (check, explain, bib_lookup, bib_fix, cited_passages). Minor sub-namespacing (bib_*) does not break the pattern.
Five tools map cleanly onto the whole preflight workflow (check, explain, lookup, fix, evidence-gathering) with no redundancy. The count is well-scoped for the domain.
The surface covers verification, rule explanation, record lookup, repair diffs, and claim-to-passage grounding, which is most of a preflight lifecycle. There is no obvious way to enumerate all rules or configure/batch settings, a minor gap agents can work around.