Build custom research systems

Academic teams build on Consensus for a different reason than companies do. The goal isn’t to put the literature inside a product — it’s to make your own research faster and more reproducible. That usually takes one of two shapes:

In code — a Python script, a notebook, or a Claude Code or Codex project that runs many searches, keeps a log, and writes the output.
In tools you already use — Consensus connected over MCP to Claude or ChatGPT, driven by a reusable prompt or skill.

Both use the same search, and both follow the same rules that make the output something you can defend.

Build	Typical form	Worked examples
Literature-review pipeline	Script or skill	Review workflow, PRISMA corpus
Citation-grounded writing	MCP or script	Ground a manuscript, Verify citations
Evidence reports	Script, scheduled or on demand	Scheduled pipeline, Biomarker report
No-code research	MCP in Claude or ChatGPT	Connect MCP

Literature-review pipelines

A good review is many searches, not one. Decompose the question into angles, run each with the same filters, merge on DOI, and keep a log of everything you did. The log becomes your methods section.

import os, time, requests
from datetime import date

API = "https://api.consensus.app/v1/search"
HEADERS = {"x-api-key": os.environ["CONSENSUS_API_KEY"]}

ANGLES = [
    "resistance training cognitive function older adults",
    "strength training executive function aging randomized trial",
    "exercise intervention memory elderly meta-analysis",
    "resistance exercise mild cognitive impairment",
    "resistance training no effect on cognition in older adults",   # the null angle
]
FILTERS = dict(human=True, study_types=["rct", "meta-analysis", "systematic review"], year_min=2010)

corpus, log = {}, []
for query in ANGLES:
    resp = requests.get(API, headers=HEADERS, params={"query": query, **FILTERS}, timeout=30)
    resp.raise_for_status()
    results = resp.json()["results"]
    log.append({"date": date.today().isoformat(), "query": query, "filters": FILTERS, "returned": len(results)})
    for paper in results:
        key = paper.get("doi") or paper["url"]
        corpus.setdefault(key, {**paper, "found_by": []})["found_by"].append(query)
    time.sleep(1)                         # one search per second outside Enterprise

print(f"{len(ANGLES)} queries, {sum(e['returned'] for e in log)} results, {len(corpus)} unique papers")

What to get right

Vary the angle, not just the wording. Cover mechanism, population, outcome, and the contradicting finding. Five paraphrases of one idea retrieve the same papers and give false confidence in coverage.
Tighten filters one step at a time. Start broad, then add study design, population, and journal quality, recording the count at each step. See the filter ladder.
Count queries, results, and cited papers separately. They are three different numbers, and reviewers will ask for all of them.
Keep found_by. How many angles surfaced a paper is a useful relevance signal, and it documents your search.

Go deeper: Build a reusable literature-review workflow, Build a PRISMA-ready search corpus, Screen abstracts against inclusion criteria, and Write the search-strategy section of your methods.

Writing with grounded citations

The second most common system: match every claim in a draft to a real paper, or flag it as unsupported. It works in either direction — finding citations for a draft, or checking that an existing reference list says what the text claims.

Split the draft into claims

One sentence-level claim per row. Claims that bundle two findings need two rows.

Search each claim as a query

Phrase the claim itself as the query, with filters that match the strength it asserts. A claim about an effect in humans deserves human=true.

Judge support, not topic

Have the model check each candidate’s takeaway, abstract, or full-text excerpts against the claim. A paper on the right topic that doesn’t support the claim is the error that survives review.

Output a table

Claim, supporting paper with link, and a verdict: supported, partially supported, or unsupported. Unsupported is a useful result — it tells you what to soften or cut.

Go deeper: Find a real citation for every claim in a draft, Verify that every citation is real and supports its claim, and Find which journals to submit to.

Evidence reports on demand or on a schedule

Once a search strategy works, run it again. Labs use this for a weekly new-papers digest on their topic, a standing evidence report on a biomarker or intervention, or a reading list regenerated each term.

On demand: the same script, parameterized by topic, run whenever someone needs the report.
On a schedule: a cron job or GitHub Action that windows each run with year_min and month_min, diffs on DOI against the last run, and reports only what is new.

Go deeper: Track new papers across many topics on a schedule, Create a biomarker evidence report, Turn a syllabus into a reading list, and Find NIH grants for a research idea.

Use the tools you already have

You don’t need to write code. Connect Consensus over MCP to Claude, ChatGPT, or Claude Code, and the assistant runs the searches for you. The quality comes from the prompt, so write down the method once and reuse it:

Search Consensus for randomized trials and meta-analyses since 2015 on resistance
training and cognition in adults over 60. Run at least five searches from different
angles, including one looking for null results. Deduplicate the results, then give me:

1. An evidence table: study, design, sample size, main finding, link.
2. A log of every search you ran, with its filters and how many results it returned.

Cite only papers returned in this session.

To share a method across a lab, package the prompt as a skill so everyone runs it the same way. See Build a reusable literature-review workflow.

What makes it rigorous

Cite only what came back in this session

Never supplement results with the model’s memory or a paper you happen to know. Every citation needs a DOI or URL returned by a search you ran.

Log enough to reproduce it

Record each query, its filters, the date, and the result count. That is what turns a search into a methods paragraph, and what lets someone else rerun it.

Know your plan's result cap

Free accounts return 10 results per search, Pro and Teams up to 300, Deep up to 750. A thin result set can be a plan ceiling rather than a gap in the literature — say which it was.

Pace your searches

One search per second on every plan except Enterprise. Run fan-outs sequentially and retry once on failure; never silently skip a failed search.

The full set of rules, including the audit-log format, is in best practices.

Build internal research tools

The organizational counterpart: assistants, monitoring agents, and agents.

Best practices

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

Get started with the API

Your first authenticated request, in seven languages.

Use case library

30 worked examples you can filter by persona.

Overview

Guides

Use case library

Build custom research systems

Literature-review pipelines

Writing with grounded citations

Evidence reports on demand or on a schedule

Use the tools you already have

What makes it rigorous

Build internal research tools

Best practices

Get started with the API

Use case library

​Literature-review pipelines

​Writing with grounded citations

​Evidence reports on demand or on a schedule

​Use the tools you already have

​What makes it rigorous

​Related

Build internal research tools

Best practices

Get started with the API

Use case library

Literature-review pipelines

Writing with grounded citations

Evidence reports on demand or on a schedule

Use the tools you already have

What makes it rigorous

Related