arXiv API for Paper Search: Three of Twenty Results Were Off Topic

Copy this line to your agent to search academic papers.

set up https://monid.ai/SKILL.md and use api.kadec0.xyz /v1/papers then /v1/paper-details

We asked a paper search for work on retrieval augmented generation twice on 2026-09-17, once restricted to arXiv and once across every source it carries. The arXiv-only run returned three papers about cognitive augmentation, wearable fact-checking and human performance, none of which are about retrieval augmented generation. The blended run returned twenty on-topic papers and shared only six titles with the first. Narrowing to the source everybody names made the answer worse. This guide runs through Monid, the OpenRouter for agent tools.

Is there an arXiv API you can call for paper search?

There is arXiv's own, and there is the more useful thing, which is a paper search that treats arXiv as one source among several and hands you a normalised row.

What people mean by the question

Usually one of three jobs. Find papers on a topic. Fetch one paper's metadata by identifier. Walk outward from a paper to related work. arXiv's own interface answers the first two on its own corpus and does not answer the third, because arXiv does not hold a citation graph.

What a blended paper endpoint does

Runs the query against several indexes, arXiv, OpenAlex, Crossref, Semantic Scholar and PubMed among them, and returns one row shape regardless of where a paper came from. Every row on our runs carried the same fourteen fields, with a source field naming the index it came from.

The tradeoff nobody expects

You would assume restricting to arXiv gives you a cleaner answer about machine learning preprints. On this measurement it did the opposite, and the next section is the count.

📖 See also Batch YouTube Transcripts Into Your RAG Store

Why did restricting to arXiv make the results worse?

Because the arXiv-only path matched on a word and the blended path matched on the concept.

The two runs

Same query, retrieval augmented generation, same endpoint, one parameter different:

The three that missed

On the arXiv-only run, these came back for a query about retrieval augmented generation:

Intelligent Interaction Strategies for Context-Aware Cognitive Augmentation
Factually: Exploring Wearable Fact-Checking for Augmented Truth Discernment
Designing AI Systems that Augment Human Performed vs. Demonstrated Critical …

All three are about augmenting humans. They matched the token "augment" and nothing else. The blended run produced no equivalent misses.

Why the blend was more precise

Because OpenAlex, which supplied twelve of the twenty rows, carries topic assignments and a citation graph, so its relevance model has more to work with than the words in a title and abstract. The arXiv rows in the blended run were the six that survived that stronger model.

The practical reading. If you name a source because you trust it, you are also choosing its retrieval quality, not only its corpus. On this query, six arXiv papers reached the blended results on merit and fourteen did not, which is a more useful selection than the twenty that arrived because they were on arXiv.

And only six titles were common to both runs. Two calls, same query, same endpoint, one parameter apart, seventy percent different answers. This is the same divergence measured across four web search engines in the search comparison, reproduced inside a single provider.

How do you search papers through one key?

Three calls, and the parameter that does not work is worth knowing first.

For agents

Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:

set up https://monid.ai/SKILL.md

It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.

For humans

npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main

Step 1. Search

The endpoints. api.kadec0.xyz/v1/papers, per call, takes q, source from all, arxiv, pubmed, openalex, crossref and semanticscholar, plus year_from, year_to and sort.

monid run -p api.kadec0.xyz -e /v1/papers \
  --query '{"q": "retrieval augmented generation", "source": "all"}'

What comes back. Twenty rows with title, abstract, authors, published, year, venue, url, pdfUrl, doi, citationCount, citedByCount and source.

The parameter that did nothing. We passed limit: "10" on every call and got twenty every time. Plan for twenty, page with year_from and year_to rather than by count, and do not size your budget on a limit the endpoint ignores.

Step 2. Read one paper properly

The endpoints. api.kadec0.xyz/v1/paper-details, per call, takes id.

monid run -p api.kadec0.xyz -e /v1/paper-details --query '{"id": "2506.06962"}'

What comes back. Much more than the search row, which is the subject of the next section.

Step 3. Walk outward

The endpoints. api.kadec0.xyz/v1/related-papers, per call, takes id. On our run: fifteen papers, every one from Semantic Scholar, every one carrying a citedByCount and a relatedBy field naming the graph that produced the link.

For the full text of anything open access, api.kadec0.xyz/v1/paper-fulltext takes the same identifier. Be aware that on our related set only one of fifteen carried an openAccessUrl, so the fetchable fraction is smaller than the result count suggests.

📖 See also Give Your Agent Live Web Context

What does the details call add that search does not?

A citation graph, a reference list and a generated summary, which makes it the opposite of the profile call we measured on a company database yesterday.

The added fields

Over and above the search row, paper-details returned openAlexId, referenceCount of 53, influentialCitationCount of 0, fieldsOfStudy of Computer Science, a tldr one-line generated summary, a references array of 25 entries, a citedBy array of 7 and a citationGraphSource of semanticscholar.

That is a real second product. It is worth contrasting with the Crunchbase measurement, where the profile endpoint returned the same seven fields as the search hit and the second call bought nothing. Here the second call buys the graph.

What stayed empty, and why

doi, openAlexId, citationCount and citedByCount were all null, on both the search row and the details row, for this paper. That is not a bug in the API. It is what an arXiv preprint is: no publisher, therefore no DOI, and no formal citation count because the counting happens downstream of publication.

The consequence for ranking. You cannot sort arXiv results by citations, because the field is null on the source most people ask for by name. If citation-weighted ranking matters to your pipeline, your source has to be OpenAlex or Semantic Scholar and arXiv rows will arrive unranked alongside them.

One field contradicts its own array

citedByCount came back null while citedBy held seven entries. The array knows the answer the scalar does not. Read the array length, not the count, and treat any null count on these rows as absent rather than zero, because zero and unknown are different facts and only one of them should stop a pipeline.

Which endpoint should I use for which job?

Every row was verified with monid inspect on 2026-09-17. The table gives billing shape rather than figures, because shape drives design and current numbers live on monid.ai/tools.

The last row is in the table so you do not call it by mistake. It returned no papers at all.

When should you call arXiv directly instead?

Four cases.

You want everything, not the best twenty. arXiv's own interface will page through a whole category. A blended search returns a ranked slice, twenty at a time on this endpoint, and ignores a limit parameter. For bulk corpus building, go to the source.

You need arXiv's own taxonomy. Category codes, version history, withdrawal notices and submission dates live in arXiv's metadata and did not appear on any row here. If you are filtering on cs.CL specifically, the blended row does not carry it.

Licensing or attribution requires it. If your product displays paper metadata, you may need the terms of the source you actually took it from, and a blended row abstracts that away behind a source field.

And the case against. If your query is conceptual rather than lexical, the measurement above says do not restrict at all. Three of twenty arXiv-only results matched a word instead of the idea, and the blended run had none. Restricting to arXiv is a corpus decision that quietly also becomes a relevance decision.

And one honest note about topic-search: it is not a paper search and we called it expecting one. For our query it produced a classification grounded in "Topic Modeling" at a confidence of 0.4, with candidates including speech and dialogue systems and intelligent tutoring, which is the wrong neighbourhood for retrieval augmented generation. The low confidence score is the endpoint being honest. Use it to understand what field a query belongs to, not to find anything.

Conclusion

There is an arXiv API, and on this measurement the better way to search arXiv was not to ask for arXiv. Two calls to one endpoint, one parameter apart, produced twenty results each, shared six titles, and differed in precision: three off-topic rows on the arXiv-only run against none on the blended one. The rows that arrive from arXiv carry no DOI and no citation count, so the source people name first is also the one you cannot rank by impact.

What matters more than the source is the second call. Unlike a company profile lookup, the details endpoint here is a real upgrade: fifty-three references, a reference list, a cited-by list and a generated summary that the search row does not carry. Search broad, then spend a call on the handful you will actually read, and read the arrays rather than the count fields, because one of them was null while its own array held seven entries.

Free next step: run monid inspect -p api.kadec0.xyz -e /v1/papers and look at the source enum before you decide which one to pin. It costs nothing, and on our query the default was the better choice. Start at monid.ai.

FAQ

Last updated September 2026.