
Bibverify
io.github.Hylouis233由 GitHub 帳號 Hylouis233 發布v0.3.0更新於 Nov 3, 2026
Verify and repair BibTeX references with DOI-first MCP tools.
概覽
Bibverify 依學術中介資料 API 核驗並修復 BibTeX 參考文獻,讓助理能檢查條目、把 DOI 轉成 BibTeX。
- 可以做什麼
- 把 DOI 轉成可指定引用鍵的 BibTeX 條目
- 排序並說明某筆參考文獻會查詢哪些中介資料來源
- 說明建議的欄位變更及其依據,供套用前審閱
- 核驗整份 .bib 檔案,產出報告、備份與待複核清單,預設不覆寫原始檔
- 適用情境
- 適合助理處理參考文獻的情境:確認條目是否真實存在,以及標題、作者、年份、出處與頁碼是否與 Crossref、OpenAlex、PubMed、arXiv 等來源一致,或把識別碼轉成 BibTeX 條目。
- 執行需求
- 以本機 Python 套件執行(Python 3.11–3.14),可用 uvx、pipx 或 pip 安裝,也可透過 npm 啟動器、原生套件或容器執行。需要能連線至已啟用的中介資料 API,並需要設定檔;選用的 API 金鑰與聯絡信箱可透過 BIBVERIFY_EMAIL、BIBVERIFY_OPENALEX_API_KEY、BIBVERIFY_SEMANTIC_SCHOLAR_API_KEY、BIBVERIFY_PUBMED_API_KEY、BIBVERIFY_CORE_API_KEY 等環境變數提供。
安裝
在 SourceWeft 中
- 開啟 儀表板中的 Bibverify,將其新增到工作區。
- 為需要使用其工具的對話啟用該服務。
Desktop only,透過 STDIO。 STDIO 服務會啟動本機處理程序,因此需要 SourceWeft 桌面主機。
其他 MCP 客戶端
參照 儲存庫 中的啟動說明。
README
Bibverify
Verify bibliographic existence and metadata consistency without destructive edits.
Chinese · Install · Quick start · MCP · Development
[PyPI] [Python versions] [MIT License] [CI]
Bibverify is a BibTeX metadata verification tool for researchers, editors, automation, and AI assistants. It starts with exact DOI, PMID, PMCID, or arXiv identifiers and then scores candidates from title, author, year, venue, and pagination evidence.
Bibverify evaluates whether a bibliographic record can be located in the queried sources and whether its metadata agrees. It does not prove that research findings are true, data is authentic, or a venue is reputable. A missing database record is not evidence that a reference is fabricated. By default, the source .bib file is never overwritten.
Highlights
- Identifier-first lookup for DOI, PMID, PMCID, and arXiv IDs.
- Crossref, OpenAlex, Semantic Scholar, PubMed, Europe PMC, CORE, DBLP, arXiv, bioRxiv, and more.
- Explainable multi-signal matching across identifiers, title, authors, year, venue, and pages. A resolvable DOI with a materially different title becomes
identifier_conflictinstead of being hidden by title search. - Structured provider outcomes distinguish a genuine no-match from rate limiting, authentication, network, parsing, and provider failures.
- Non-destructive merging preserves
abstract,keywords,file,note, and custom fields that providers do not return; conflicting persistent identifiers are never overwritten automatically. - A shared connection pool with retries, exponential backoff, and
Retry-Aftersupport for429/5xxresponses. - An expiring SQLite cache for successful GET responses; failures are never cached.
- Cross-platform path, encoding, Unicode filename, UTF-8 BOM, and CRLF handling.
- JSON output, stable exit codes, a Python API, and an MCP server built on the official SDK.
- Atomic output writes and byte-preserving backups.
Requirements
- Windows, macOS, or Linux
- Network access to the enabled metadata APIs
- Python 3.11–3.14 when using the Python distribution; npm, containers, and native packages bundle their runtime
GitHub Actions tests all three operating systems across all four supported Python versions.
Install
The current published release is v0.3.0. This branch prepares v0.4.0; commands marked v0.4.0 become usable only after their linked npm, GHCR, or GitHub Release artifact has been published.
Run without a permanent installation:
Starting with v0.4.0, Node.js users can use the zero-dependency npm launcher. It downloads the
matching native release, verifies SHA256SUMS, and forwards every argument and exit code:
For a persistent CLI in an isolated Python environment, use uv tool or pipx:
Inside a virtual environment, regular pip also works:
Each release also provides smoke-tested native packages on GitHub Releases. Beginning with v0.4.0, the release matrix covers Windows x64 plus macOS and glibc 2.28+ Linux on both x64 and ARM64. musl-based Linux users should use the Python package or container image. Windows ARM64 is not published natively yet because an MCP runtime dependency does not currently provide Windows ARM64 wheels; npm automatically uses the tested x64 build under Windows 11 emulation, or you can use the ARM64 container instead.
The same release publishes a multi-architecture container:
Package-manager manifests are generated from the final release bytes, not from unverified build inputs. Homebrew, Scoop, and WinGet are not live catalog entries yet: v0.4.0 will attach submission- ready manifests to GitHub Release, after which each external catalog still requires onboarding or review. See Distribution channels for rollout status.
Quick start
Convert a DOI to BibTeX
For a machine-readable response:
Verify a .bib file
Create a starter configuration:
Place references.bib next to the configuration and run:
You can override the input and output paths from the command line:
Inspect results without writing any file:
After reviewing the report, explicitly apply high-confidence field updates. Bibverify creates a byte-for-byte backup first:
PowerShell example:
The v0.2 forms remain available for compatibility, although new scripts should use subcommands:
Configuration
A minimal configuration looks like this:
See config_template.json for every commonly used option.
Path behavior is intentionally predictable:
- Relative
bib_fileandoutput_dirvalues are resolved from the directory containingconfig.json, not the shell's current directory. - If
output_diris omitted, output is written next to the input bibliography. encoding: "auto"tries UTF-8 with BOM, UTF-8, and GB18030. It does not fall back to Latin-1 and silently turn unknown bytes into mojibake.
API keys and email
Keys can be stored in a local configuration, but environment variables are safer and harder to commit accidentally:
PowerShell:
Bash or Zsh:
Query and matching settings
connect_timeout and read_timeout separately bound connection setup and response reads; the compatibility timeout field remains available. match_threshold controls automatic candidate acceptance, ambiguous_threshold controls which plausible candidates enter review, and auto_update_threshold is an additional gate for field changes. Higher values are more conservative. Relative cache paths are resolved from the config directory.
The official bioRxiv details route does not provide arbitrary title search. Bibverify therefore calls bioRxiv only for an exact 10.1101/... DOI and leaves title-only discovery to providers whose contracts support it, such as Crossref and Europe PMC.
CLI reference
Exit codes:
With --json, stdout contains JSON only. Diagnostics go to stderr, which keeps the command safe for CI and scripts.
Output files
For an input named references.bib, Bibverify may create:
bibverify_report_<timestamp>.<format>: complete states, candidates, provider errors, confidence, and field provenance intxt,json,jsonl, orcsv.references_backup_<timestamp>.bib: byte-for-byte copy of the source.references_updated_<timestamp>.bib: complete bibliography after non-destructive merging; omitted when nothing changes.references_review_<timestamp>.bib: ambiguous, not-found, unavailable-source, identifier-conflict, or invalid entries; omitted when nothing needs review.
The report-level complete value is true only when every entry completed verification. A rate-limited or unreachable provider makes it false even if another source found a candidate. Each field_diffs record includes original/suggested values, source, confidence, normalized equivalence, action, and reason.
Each output can be disabled independently through output_settings. --dry-run overrides those settings and performs zero writes. The default command only writes proposals; only --apply changes the source after a backup.
Provider ranking
Static priority is only the starting point:
- A DOI promotes Crossref and uses its exact endpoint first. A resolvable DOI with a materially different title stops as
identifier_conflict. - PMID, PMCID, or biomedical hints promote PubMed and Europe PMC.
- An arXiv identifier promotes arXiv.
- Computer-science venue hints promote DBLP.
Unpaywall is currently treated as open-access enrichment, not as a primary bibliographic metadata provider. Provider states distinguish matched, no_match, ambiguous, rate_limited, auth_error, network_error, parse_error, provider_error, and skipped.
MCP and AI assistants
Bibverify uses the official MCP Python SDK and supports local stdio and Streamable HTTP transports.
Start a stdio server:
MCP client configuration:
The npm launcher can be used directly by Node-oriented MCP clients:
Containerized stdio MCP keeps the current directory as the only writable workspace:
Start Streamable HTTP:
MCP treats the configuration directory as its workspace root by default. It rejects config or .bib reads outside that root and blocks report, cache, or update writes outside it. Broaden access only by explicitly setting --workspace-root when starting the server. The official MCP SDK handles protocol negotiation, schemas, structured results, progress, and cancellation.
Available tools:
doi_to_bibtexrank_lookup_sourcesexplain_update_diffverify_bib_file
Generate setup files for Codex, Claude, Cursor, or a generic MCP client:
Distribution channels
The npm package is a small launcher rather than a second implementation. The verification engine
remains the same Python codebase across PyPI, npm, native packages, and containers. Release assets
include SHA256SUMS; npm verifies the selected binary before execution, and Homebrew, Scoop, and
WinGet manifests pin the same release hashes.
Python API
from bib_check import BibTeXChecker remains compatible during the 0.3 release line, but new code should use the package import above.
Development
After activating the environment:
Before pushing, run python tools/fix.py. It applies ruff format and import sorting to
exactly the paths CI checks, then runs CI's ruff check and ruff format --check commands
and fails on anything that needs a manual fix. pre-commit install runs the same command
as a commit hook (see .pre-commit-config.yaml).
CI tests Windows, macOS, and Linux on Python 3.11–3.14, including provider fixtures, golden write-safety tests, lint, typing, coverage, the offline benchmark, dependency auditing, Python and npm package builds, a container smoke test, and a CycloneDX SBOM. GitHub Actions are pinned to commit SHAs, while the MCP Publisher is version-pinned and SHA-256 verified. PyPI and npm use Trusted Publishing with provenance attestations, and GHCR publishes multi-architecture images with an SBOM and build provenance.
benchmarks/cases.json is a small offline regression set covering short-title false positives, DOI conflicts, preprint title variants, Unicode/LaTeX, and fabricated author combinations. It is not a complete scientific evaluation and its scores must not be interpreted as real-world performance ceilings. Contributions of broader, redistributable, human-labeled cases are welcome.
Citation
If Bibverify supports your research, please cite:
License
來源:README.md,提交 21009b3
工具
0版本歷史
1- v0.3.0最新Sep 16, 2026
評分
已滿足適用檢查項的 50%
該評分衡量此收錄條目的完整程度,依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價,也不表示伺服器安全或目前可用:可連通性是帶日期的檢查結果,評分也不包含安裝量或使用者評價。
- 近 30 天內可連通25 分
請保持端點能夠回應 MCP 握手;SourceWeft 每 30 天探測一次。
- 已宣告認證方式10 分
請在註冊中心條目中宣告憑證請求標頭,或保持端點能夠回應探測,以便判定其認證方式。
- 已列出工具15 分
請讓伺服器在無憑證時回應 tools/list,或發布可在沙箱中無憑證啟動的軟體包。
- 描述必需15 分
- 圖示10 分
- 文件15 分
- 授權條款10 分