Skip to main content
Most organizations don’t want another research app. They want the literature available inside what they already use — the company’s ChatGPT or Claude workspace, an in-house model, a Slack bot, a spreadsheet, or the agent they ship to customers. Consensus is the retrieval layer underneath: one search call over 220+ million papers, with filters, pagination, and full-text excerpts. This guide covers the five things enterprise teams build most, how each maps to the API, and what to get right.

Connect paper search to your internal AI assistant

This is usually the first thing a team ships, because it takes an afternoon. People already ask the company assistant research questions. Right now it answers from memory; with Consensus attached, it answers from papers and links to them. If your company uses ChatGPT or Claude, add the Consensus connector with the server URL https://mcp.consensus.app/mcp. Each employee signs in with their own Consensus account, so their own plan and limits apply. See Connect MCP for client-by-client steps. If you run your own model or agent framework, register GET /v1/search as a tool. Keep the schema small: a model chooses filters better from five well-described options than from twenty.
What to get right
  • Tell the model when to use it and how to cite. Put “cite only papers returned by search_papers, with their URL” in the system prompt, and make “the literature does not answer this” an acceptable answer.
  • Return doi and url on every result so each claim in the answer can link to its source.
  • Pick the auth model deliberately. MCP spreads load across each person’s account. A shared API key concentrates every employee’s searches on one rate limit — one search per second outside Enterprise.

Keep on top of a field

The request we hear most from corporate research and scouting teams: tell me what came out this week that matters to me. A typical example is a team tracking computer vision and robotics that wants an agent per team member, each surfacing new papers on that person’s topics and following which authors and labs are publishing where.
1

Give each person or team a watchlist

A watchlist is a handful of queries plus the filters that scope them. Use domain to hard-filter by field (cs, eng, bio, med, and so on).
2

Window every run to the last one

Set year_min and month_min to the date of the last successful run, so each run only retrieves what is new.
3

Diff on DOI and send a digest

Store every DOI you have already sent. Each digest is the set difference, ranked by relevance to the watchlist — new papers have no citations yet, so citation_count is a poor signal here.
4

Track authors and institutions over time

Every result carries authors and institutions. Count them across runs to see who is publishing on your topics, where, and when an affiliation changes.
What to get right
  • Keep preprints in for early signal. Preprints are included unless you set exclude_preprints=true, and each result’s is_preprint flag lets you label them in the digest.
  • journal_name boosts, it does not filter. It surfaces a journal higher but still returns others. To watch specific venues, pass journal_name and keep only matching results client-side, or use publisher_name, which is a hard filter.
  • Log the empty runs. A digest with nothing in it is a record worth keeping: it tells “no new papers” apart from “the job broke three weeks ago.”
For the scheduled version at scale, see Track new papers across many topics on a schedule and Monitor new research about a drug, device, or brand.

Pull an exhaustive list of papers

Landscape reviews, due diligence, and building an internal corpus all start with the same request: give me every paper on this. One search returns the most relevant page; an exhaustive list means paginating to the end, scoping with hard filters, and covering the topic with more than one phrasing.
What to get right
  • Scope with hard filters first: domain, year_min/year_max, publisher_name, country, study_types. They shrink the set before you page through it.
  • Fan out phrasings for recall. Results are ranked by relevance to one query, so a single phrasing misses papers that use different terminology. Run several phrasings, then deduplicate on doi.
  • Check the page_size echoed back. A request above your plan’s ceiling is clamped rather than rejected: 300 on Pro and Teams, 750 on Deep, 1,000+ on Enterprise.
The full method, including deduplication and flow counts, is in Build a PRISMA-ready search corpus and best practices.

Build literature tables that fill themselves

Drug discovery and R&D teams often want a table rather than a chat. Rows are entities — targets, compounds, materials, indications. Columns are the literature questions you ask of every one of them. Each cell is one filtered search, an optional pass over full-text excerpts, and a short cited summary. The table fills in when someone adds a row, or refreshes on a schedule.
What to get right
  • One template per column, not a hand-written query per cell. Templates are auditable, and when you change one you know exactly which cells to refresh.
  • Keep the papers behind every cell. Store the DOIs alongside the summary so a reader can click through from any cell to its evidence.
  • Use full-text excerpts for anything quantitative. full_text_chunks (all paid plans) lets a cell carry an effect size or a measured value instead of a paraphrase of the abstract.
  • Refresh incrementally. On each sync, window with year_min and month_min, and re-summarize only the cells whose paper set changed.
  • Budget searches before you add rows. Rows × columns is the number of searches per refresh: 300 targets × 5 columns is 1,500 searches, or about 25 minutes at one per second.
Worked examples: Build a drug target validation dossier, Screen thousands of target-disease pairs, and Extract numbers from full-text papers. Biotech and AI startups building scientific agents use Consensus as the agent’s literature tool. The agent decides what to search, Consensus returns ranked papers and excerpts, and the agent reasons over them.
phylo

Phylo — REST API, high throughput

Phylo’s agents turn each biology question into several parallel search angles, merge the evidence, and distill it into one answer. One team screens about 20,000 targets across hundreds of diseases.
owkin

Owkin — MCP, shipped in days

Owkin exposed Consensus to K Pro’s orchestrator the same way it exposes its other tools, replacing a curated PubMed-abstract corpus with full-text search.
“It’s very robust, with almost zero errors. It gives you genuinely useful results, and it embeds into a high-throughput agentic workflow easily.” Kexin Huang, Co-founder & CEO, Phylo
Choosing a surface: use MCP if your agent already consumes tools over MCP — it is a tool registration, not a new service. Use the REST API when you need pagination, batch workloads, or one shared quota across all your users. What to get right
  • Search several angles per question. One search per user question is the most common cause of thin answers. Decompose into mechanism, population, outcome, and the contradicting view, and pace the searches to your rate limit.
  • Reason over excerpts, not just abstracts. include_full_text_chunks=true gives the generation step the results paragraphs.
  • Enforce grounding at generation time. Drop any sentence that has no doi or url behind it.
  • Benchmark before you switch providers. Curate queries with known-relevant papers and measure what each provider surfaces — Phylo ranked Consensus first on its own benchmark.
Worked examples: Add a citable evidence layer to an agent, Answer one question with many parallel searches, Swap a hand-maintained paper corpus, and Benchmark literature providers.

Before you roll it out

One search per second on every plan except Enterprise, where limits are custom. Pace fan-outs and scheduled jobs, honour retry-after on a 429, and add jitter. See rate limits and result caps.
page_size caps at 300 on Pro and Teams, 750 on Deep, and 1,000+ on Enterprise. Query-relevant full-text excerpts (include_full_text_chunks) are available on all paid plans.
MCP authenticates each person with OAuth, so their own plan applies. The API uses one x-api-key for the whole integration — simpler to operate, but every user shares its limits.
Cache on the full parameter set with a short TTL so new papers still land. Log every query, its filters, and the DOIs returned — it makes answers auditable and debugging far faster.
Building something your whole organization will use? An Enterprise trial gives you the higher limits and larger result pages to build without hitting ceilings. Talk to us.

Build custom research systems

The academic counterpart: literature reviews, writing, and reports.

Best practices

Fan-out, the filter ladder, exhaustive sweeps, and grounding rules.

Search endpoint reference

Every filter and response field, with an interactive playground.

Use case library

30 worked examples you can filter by persona.