Setting Up an Academic Paper Search Agent on a VPS

The first time I asked my AI agent for "recent papers on LLM agent orchestration," it invented five plausible-sounding titles and three authors that did not exist. The citations looked real. The DOIs resolved to nothing. It was a polite, confident hallucination, and it would have been embarrassing if I had pasted the result into a real document.

I needed a tool that hit actual academic databases. The openags/paper-search-mcp project was the cleanest option I found: an MCP server that talks to arXiv, PubMed, bioRxiv, medRxiv, and Google Scholar, returning real results with real identifiers. I deployed it to my VPS, and the same query now returns papers I can actually download.

This is what the deployment looks like, what I verified along the way, and where I would push next.

The Reference Setup

The upstream README lays out five install methods. Some are runtime-only (npx -y @smithery/cli install … or uvx paper-search-mcp), some install persistently (uv tool install paper-search-mcp or pip install paper-search-mcp), and one runs from a cloned source directory.

For a server, the persistent installs are the right choice. I went with uv tool install paper-search-mcp because it gives me a clean, isolated environment per tool without polluting the system Python.

The env vars the server reads are the usual academic API mix. Some are required (Unpaywall wants an email for polite-pool access), the rest are optional and only needed if you want to hit their respective sources.

PAPER_SEARCH_MCP_UNPAYWALL_EMAIL
PAPER_SEARCH_MCP_CORE_API_KEY
PAPER_SEARCH_MCP_SEMANTIC_SCHOLAR_API_KEY
PAPER_SEARCH_MCP_ZENODO_ACCESS_TOKEN
PAPER_SEARCH_MCP_GOOGLE_SCHOLAR_PROXY_URL
PAPER_SEARCH_MCP_IEEE_API_KEY
PAPER_SEARCH_MCP_ACM_API_KEY

The upstream mcpServers JSON looks like this:

json

{
  "mcpServers": {
    "paper-search-mcp": {
      "command": "uv",
      "args": ["tool", "run", "paper-search-mcp"],
      "env": {
        "PAPER_SEARCH_MCP_UNPAYWALL_EMAIL": "<your-email>",
        "PAPER_SEARCH_MCP_CORE_API_KEY": "",
        "PAPER_SEARCH_MCP_SEMANTIC_SCHOLAR_API_KEY": "",
        "PAPER_SEARCH_MCP_ZENODO_ACCESS_TOKEN": "",
        "PAPER_SEARCH_MCP_GOOGLE_SCHOLAR_PROXY_URL": "",
        "PAPER_SEARCH_MCP_IEEE_API_KEY": "",
        "PAPER_SEARCH_MCP_ACM_API_KEY": ""
      }
    }
  }
}

What I Found on the VPS

After installation, the layout on my VPS looked like this. The skill definition lives under the OpenFang skills folder, the tool wrapper lives under tools, and the CLI entry point is on the system PATH at /usr/local/bin/paper-search.

OpenFang skill path: /root/.openfang/skills/paper-search-mcp
OpenFang tool path: /root/.openfang/tools/paper-search-mcp
CLI: /usr/local/bin/paper-search
Python package: /usr/local/lib/python3.12/dist-packages/paper_search_mcp/
Package version: 0.1.3

A quick paper-search --help confirmed the CLI worked, and paper-search sources returned the five available sources: arxiv, biorxiv, google_scholar, medrxiv, pubmed. That was the moment I stopped worrying about the install and started using it.

The .env I Wrote

The system-level env file at /root/.openfang/.env had the keys I had on hand. I masked the values in the report I wrote for myself, but the structure was:

code

PAPER_SEARCH_MCP_UNPAYWALL_EMAIL=<your-email>
PAPER_SEARCH_MCP_CORE_API_KEY=<your-core-key>
PAPER_SEARCH_MCP_IEEE_API_KEY=<your-ieee-key>

The other keys (Semantic Scholar, Zenodo, Google Scholar proxy, ACM) were not set because I did not have accounts for them yet. The tool degrades gracefully: any source whose required key is missing returns an empty result rather than failing the whole query.

The Mode Mismatch I Almost Missed

There is a subtle thing the install does not warn you about. The tool creates a local venv at /root/.openfang/tools/paper-search-mcp/.venv, but the venv's site-packages does not actually contain the paper-search-mcp distribution. The active CLI imports from the global system Python instead.

That is fine for a working CLI, but it means the per-tool venv is dead weight. If you ever need to update the package, you cannot just pip install --upgrade inside the venv and expect the CLI to pick it up. You have to update the system Python install or re-run the tool installer.

The other thing to know: openfang integrations reports 0 installed for paper-search. The tool is being used in CLI and skill mode, not as a registered MCP integration entry. For my use case (calling the search through the agent's MCP client wiring) the difference is invisible. If you are running an MCP-aware client that needs every integration registered, you will need to install it explicitly via openfang add.

A Practical Test

To confirm the whole stack worked, I ran a query that exercises the most common academic use case: find recent papers on a specific topic from a specific source.

bash

paper-search search --source arxiv --query "LLM agent orchestration" --max-results 10

The response was a JSON list of real arXiv papers, each with a title, author list, abstract snippet, and a link that actually resolved. Compared to the previous behavior of my AI agent inventing citations, this was a step-change improvement.

The Sources I Use Most

For machine learning and AI research, arXiv is the workhorse. Coverage is broad, the API is generous with rate limits, and abstracts are usually enough to decide whether a paper is worth downloading in full.

For biomedical and life sciences, PubMed is the workhorse. bioRxiv and medRxiv are the preprint servers that often have cutting-edge findings months before they appear in journals. I usually search PubMed first for established work, then bioRxiv for the newest preprints.

Google Scholar is the broadest index but also the noisiest. The results are not as structured as arXiv or PubMed, and the rate limits are aggressive. I use it as a last resort when the other sources do not turn up what I need.

What I Would Set Up Next

If I were extending this setup, the highest-leverage additions would be:

A Semantic Scholar key. Semantic Scholar's API is well-designed, the response format is rich (with citation graphs and influential-citation counts), and the free tier is generous. It is the best source for "find me papers that cite this paper" workflows.

A Google Scholar proxy. Direct Google Scholar scraping is fragile and rate-limited. Running a small proxy (a cheap VPS with a headless browser and a cache) gives reliable access without the daily block-throttle cycle.

IEEE and ACM keys. For engineering, computer science, and security research, these are the canonical sources. A few of my projects touch security topics where arXiv coverage is thin, and IEEE is where the actual papers live.

Version pinning. I am currently on 0.1.3 and the upstream is moving. Before the next major version bump, I will pin a specific version, write the install command down in my runbook, and re-test the smoke queries after upgrade. The risk of an unannounced breaking change is real.

What I Learned From This Setup

Mode matters more than install method. Whether the tool runs as a registered MCP integration, a CLI, or a callable Python module changes how you debug it. Pick a mode and stick with it.

Graceful degradation is underrated. The tool returning empty results for sources with missing keys, rather than failing the whole query, is the difference between a useful library and a frustrating one.

A real search beats a confident hallucination every time. The first time the agent returned a real arXiv link in response to a research question, I knew the setup was worth the afternoon it took.

Audit the actual runtime, not the spec. The package being installed does not mean the CLI is using the version you think. Check the import path, check the version, and document both.

If you are building an agent that does any kind of factual work, an academic paper search MCP server is one of the highest-ROI additions you can make. It pays for itself the first time it saves you from citing a paper that does not exist.