> ## Documentation Index
> Fetch the complete documentation index at: https://docs.consensus.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Build custom research systems

> How academics and research groups use the Consensus API and MCP to build literature-review, writing, and reporting workflows they can reproduce.

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](#literature-review-pipelines)       | Script or skill                | [Review workflow](/use-cases/literature-review-skill), [PRISMA corpus](/use-cases/prisma-corpus)              |
| [Citation-grounded writing](#writing-with-grounded-citations)    | MCP or script                  | [Ground a manuscript](/use-cases/ground-a-manuscript), [Verify citations](/use-cases/citation-verification)   |
| [Evidence reports](#evidence-reports-on-demand-or-on-a-schedule) | Script, scheduled or on demand | [Scheduled pipeline](/use-cases/scheduled-research-pipeline), [Biomarker report](/use-cases/biomarker-report) |
| [No-code research](#use-the-tools-you-already-have)              | MCP in Claude or ChatGPT       | [Connect MCP](/consensus-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.

```python theme={null}
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](/use-cases/best-practices#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](/use-cases/literature-review-skill), [Build a PRISMA-ready search corpus](/use-cases/prisma-corpus), [Screen abstracts against inclusion criteria](/use-cases/abstract-screening), and [Write the search-strategy section of your methods](/use-cases/search-strategy-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.

<Steps>
  <Step title="Split the draft into claims">
    One sentence-level claim per row. Claims that bundle two findings need two rows.
  </Step>

  <Step title="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`.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

Go deeper: [Find a real citation for every claim in a draft](/use-cases/ground-a-manuscript), [Verify that every citation is real and supports its claim](/use-cases/citation-verification), and [Find which journals to submit to](/use-cases/where-to-submit).

## 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](/use-cases/scheduled-research-pipeline), [Create a biomarker evidence report](/use-cases/biomarker-report), [Turn a syllabus into a reading list](/use-cases/syllabus-reading-list), and [Find NIH grants for a research idea](/use-cases/grant-finder).

## Use the tools you already have

You don't need to write code. [Connect Consensus over MCP](/consensus-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:

```text theme={null}
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](/use-cases/literature-review-skill).

## What makes it rigorous

<AccordionGroup>
  <Accordion title="Cite only what came back in this session" icon="circle-check">
    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.
  </Accordion>

  <Accordion title="Log enough to reproduce it" icon="clipboard-list">
    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.
  </Accordion>

  <Accordion title="Know your plan's result cap" icon="layers">
    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.
  </Accordion>

  <Accordion title="Pace your searches" icon="gauge">
    One search per second on every plan except Enterprise. Run fan-outs sequentially and retry once on failure; never silently skip a failed search.
  </Accordion>
</AccordionGroup>

The full set of rules, including the audit-log format, is in [best practices](/use-cases/best-practices#grounding-and-auditability).

## Related

<CardGroup cols={2}>
  <Card title="Build internal research tools" icon="building" href="/use-cases/internal-tools">
    The organizational counterpart: assistants, monitoring agents, and agents.
  </Card>

  <Card title="Best practices" icon="shapes" href="/use-cases/best-practices">
    Fan-out, the filter ladder, exhaustive sweeps, and grounding rules.
  </Card>

  <Card title="Get started with the API" icon="code" href="/api-get-started">
    Your first authenticated request, in seven languages.
  </Card>

  <Card title="Use case library" icon="layout-grid" href="/use-cases/gallery">
    30 worked examples you can filter by persona.
  </Card>
</CardGroup>
