API & MCP

The data behind every page of the Atlas, as JSON. Each relation in the pathway model comes with the claim it makes, the conditions it was measured under, how confident the curation is, and the studies that support or contradict it. No key, no sign-up, CC BY 4.0.

Current state: API 1.0.0 · dataset 2.0.1+unreleased · corpus snapshot 2026-11-09 16:23 (commit ddd2837263) · 526 studies · 172 entities · 138 relations · 18 questions.

These figures are the ones this page was built with. If they differ from meta.json, one of the two is a cached copy: compare corpus_snapshot and source_commit, and trust the later snapshot.

How it works

• Same data as the website. The JSON files are built in the same step as the HTML pages, from the same source. The API cannot show something the site does not.
• Static files. There are no query parameters and no search endpoint. Lists are small (the largest is a few hundred kB); download one and filter it locally.
• Every response says what it was computed from. The meta block carries the dataset version, the corpus snapshot date and the source commit, so an analysis can state exactly which Atlas it used.
• Live data versus an archived version. The API serves the live data, which change with every deploy. dataset_version is a plain release number such as 2.0.1 only when the live content is identical to that archived Zenodo release (live_matches_release: true, checked by a content fingerprint). Otherwise it reads like 2.0.1+unreleased: changed since that release, not archived yet. In that case the release's version DOI does not contain what you analysed; cite corpus_snapshot and source_commit, or analyse the archived file itself. See Data & Citation.
• Caching. The host sends ETag and Last-Modified; a conditional request returns 304 Not Modified when nothing has changed. The CDN keeps each file for up to 10 minutes, so in the minutes after a deploy two files can come from different builds. Compare meta.source_commit across the files you combine; if one differs, fetch it again. The MCP server does this itself.
• Stable within v1. Fields may be added. A field is never renamed or removed inside /api/v1/; a breaking change gets a new version path.

Endpoints

Base URL: https://mtor-atlas.org/api/v1 · machine-readable description: openapi.json (OpenAPI 3.1)

Evidence codes

Every study carries a code for the kind of study behind the finding. The code is not a grade: a careful molecular study is not "worse" than a human one, it answers a different question. Each response repeats this note next to the code, so the code never travels alone.

Example: one relation

Relations are the core of the API. evidence.supporting and evidence.conflicting are study IDs you can resolve with /studies/{sid}.json; source.entity and target.entity are entity IDs, or null where a pathway node has no entity record.

{
  "meta": {
    "api_version": "1.0.0",
    "dataset_version": "2.0.1+unreleased",
    "live_matches_release": false,
    "archived_release": {
      "version": "2.0.1",
      "version_doi": "10.5281/zenodo.23090261",
      "date": "2026-10-01",
      "studies": 428
    },
    "data_fingerprint": "902cee5f48b5ec3c7b68ab77cd461448d3b00c4f4b77f38a9e1b5affcf85f063",
    "corpus_snapshot": "2026-11-09T16:23:12+0100",
    "source_commit": "ddd2837263b4e46b1074542b3dff085b860093b3",
    "license": "CC-BY-4.0",
    "cite": "Barton O. Oliver's mTOR Atlas (live data, not an archived version; give corpus_snapshot and source_commit). doi:10.5281/zenodo.22059963",
    "docs": "https://mtor-atlas.org/api/"
  },
  "data": {
    "id": "RHEB-MTORC1",
    "claim": "Rheb activates mTORC1",
    "source": {
      "name": "Rheb",
      "entity": "rheb"
    },
    "target": {
      "name": "mTORC1",
      "entity": "mtorc1"
    },
    "effect": "activates",
    "type": "allosteric-activation",
    "directness": "direct",
    "timescale": "seconds",
    "compartment": "lyso",
    "map_band": "lyso",
    "species": [
      "mammalian cells",
      "human brain tissue (somatic RHEB variants)"
    ],
    "mechanism": "GTP-loaded Rheb binds mTORC1 at the lysosome and physically re-shapes its active site into the working conformation.",
    "mechanism_beginner": "Switched-on Rheb docks onto mTORC1 and physically reshapes it into its working form – the actual \"on\" switch.",
    "context": "Rheb must be GTP-loaded and co-located with mTORC1. Rheb is also distributed across the ER and Golgi, and which pool supplies the activating Rheb is unresolved.",
    "boundary": "Cryo-EM structures, in vitro biochemistry, Drosophila and one mouse study (INOK2003, SAU2003, YAN2017, CUI2025, DEL2011) define how Rheb activates mTORC1 in reconstituted and cellular systems. Human tissue evidence is genetic and indirect: brain-restricted somatic RHEB variants in focal cortical dysplasia and hemimegalencephaly go with strong pS6 staining in the lesions (BAL2019, a cohort of 80 children in which RHEB is one of four activator genes; LEE2021, three patients). That shows the pathway running hot when Rheb is altered; it does not measure Rheb-GTP loading or mTORC1 activity directly in human tissue.",
    "boundary_tags": [],
    "conflict": null,
    "note": "Convergence point: the amino-acid route delivers mTORC1 here, the growth-factor route delivers Rheb. Both required.",
    "consensus_contested": false,
    "curation_contested": false,
    "contested": false,
    "confidence": {
      "mechanistic": "high",
      "human_relevance": "plausible",
      "human_relevance_label": "plausible in people, not shown directly",
      "consensus": "established",
      "consensus_label": "settled in the literature"
    },
    "evidence": {
      "kind": "Structural",
      "strongest": {
        "code": "H",
        "label": "Human study"
      },
      "supporting": [
        "INOK2003",
        "SAU2003",
        "YAN2017",
        "CUI2025",
        "DEL2011",
        "BAL2019",
        "LEE2021"
      ],
      "conflicting": []
    },
    "external_refs": [],
    "reviewed": null,
    "updated": null,
    "checked": null,
    "review_status": "unreviewed",
    "reviewer": null,
    "curation_status": "Proposed",
    "url": "https://mtor-atlas.org/relation/RHEB-MTORC1/",
    "api_url": "https://mtor-atlas.org/api/v1/relations/RHEB-MTORC1.json"
  }
}

Quick start

curl

curl -s https://mtor-atlas.org/api/v1/studies/SAB1994.json | jq '.data | {sid, title, evidence, relations}'

Python

import requests

BASE = "https://mtor-atlas.org/api/v1"
rels = requests.get(f"{BASE}/relations.json").json()
print("dataset", rels["meta"]["dataset_version"], "snapshot", rels["meta"]["corpus_snapshot"])

# Every relation that touches Rheb, with the studies behind it
for r in rels["data"]:
    if "Rheb" in (r["source"]["name"], r["target"]["name"]):
        best = r["evidence"]["strongest"] or {}
        print(r["claim"], "|", best.get("code"), "|", ", ".join(r["evidence"]["supporting"]))

JavaScript

const BASE = "https://mtor-atlas.org/api/v1";
const { data } = await (await fetch(`${BASE}/entities/mtorc1.json`)).json();
const contested = data.relations.filter(r => r.consensus_contested);
console.log(data.name, data.study_count, "studies,", contested.length, "contested relations");

Use it from an AI assistant

Assistants that support the Model Context Protocol (MCP) get the Atlas as a set of tools: they search studies by evidence code, look up the evidence for a pathway claim with both the supporting and the contradicting studies, and list contested claims and open questions. Web assistants connect to a hosted server by URL; desktop and coding assistants can also run the same server on your own computer. Assistants without MCP can read the JSON API directly. Either way, every answer can carry the dataset version and snapshot date, so it can be cited.

Web assistants: connect by URL

Server URL (Streamable HTTP, no sign-in, read-only):

https://mtor-atlas-mcp.mtor-atlas.workers.dev/mcp

ChatGPT: Oliver's mTOR Atlas is available as an official plugin in the ChatGPT plugin directory. Install it there and ask for the evidence behind any mTOR pathway claim; no URL or Developer mode needed.

Other assistants, or ChatGPT without the plugin directory:

• Claude (claude.ai, desktop and mobile apps): Settings → Connectors → Add custom connector. Name mtor-atlas, paste the URL.
• ChatGPT (manual setup): Settings → Apps → Advanced settings → turn on Developer mode, then Create app. Paste the URL, authentication: No authentication. Availability depends on the ChatGPT plan.
• Grok: grok.com/connectors → New Connector → Custom, paste the URL.
• Other clients that accept a remote MCP server: the same URL.

Menu names in these apps change often; if a step is not where described, look for “connectors”, “apps” or “MCP” in the settings.

Desktop and coding assistants: run it locally

The local server needs Node.js 18 or newer. Package: mtor-atlas-mcp · source: GitHub (MIT) · listed in the MCP Registry as io.github.open-mtor-atlas/mtor-atlas.

Claude Desktop

Settings → Developer → Edit Config. Add this to claude_desktop_config.json and restart Claude:

{
  "mcpServers": {
    "mtor-atlas": {
      "command": "npx",
      "args": [
        "-y",
        "mtor-atlas-mcp"
      ]
    }
  }
}

Claude Code

As a plugin (connects to the hosted server, nothing to install locally):

/plugin marketplace add open-mtor-atlas/mtor-atlas-plugins
/plugin install mtor-atlas@mtor-atlas

Or add the server directly:

claude mcp add mtor-atlas -- npx -y mtor-atlas-mcp

Gemini CLI

gemini extensions install https://github.com/open-mtor-atlas/mtor-atlas-plugins

Both packages live in open-mtor-atlas/mtor-atlas-plugins.

Cursor, Windsurf and other MCP clients

Use the same mcpServers block as for Claude Desktop (in Cursor: ~/.cursor/mcp.json, or Settings → MCP → Add new server).

VS Code (Copilot agent mode)

Add to .vscode/mcp.json in your project, or run MCP: Add Server from the command palette:

{
  "servers": {
    "mtor-atlas": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "mtor-atlas-mcp"
      ]
    }
  }
}

OpenAI Codex CLI

codex mcp add mtor-atlas -- npx -y mtor-atlas-mcp

Perplexity (Mac app)

Settings → Connectors. Install the PerplexityXPC helper when asked, then Add Connector, name it mtor-atlas and enter the command npx -y mtor-atlas-mcp. When it shows Running, switch it on under Sources.

Assistants without MCP connectors

Gemini and assistants on plans without custom connectors can still use the Atlas:

• Give them the API. With web access switched on, paste a prompt like this and add your question. Check that the answer cites study IDs from the Atlas; if it does not, the assistant did not read the API.

  Use the open, read-only JSON API of Oliver's mTOR Atlas.
  Start with https://mtor-atlas.org/api/v1/meta.json (the endpoint list is inside),
  the schema is at https://mtor-atlas.org/api/openapi.json.
  For every claim, give the study IDs and evidence codes from the API
  and the dataset version from the "meta" block.
  Question: <your question>

• A custom GPT in ChatGPT. Explore GPTs → Create → Configure → Create new action → Import from URL: https://mtor-atlas.org/api/openapi.json, authentication None. The GPT can then call every endpoint itself.

What is deliberately not here

• Full abstracts. A study record carries the same abstract excerpt as its page, plus DOI and PMID. The full abstract is on PubMed.
• Unreviewed extraction as fact. extracted_findings holds the AI-assisted extraction shown on study pages under "Extracted findings". Curated fields (finding, model_system, evidence) take precedence where they differ. Each study record says how far its extraction has been checked in extracted_findings_review.status (unreviewed, reviewed or corrected; a check is only reported with the reviewer's name). At this snapshot a person has checked the extraction for 1 of 526 studies, so a conclusion should rest on the status of the specific record, not on its presence in the API. Curated fields are written by a single curator and are not independently reviewed either; see Evidence audit.
• Search and filtering. These would need a server; the lists are small enough to filter where you use them.
• Write access. The API is read-only. The corpus is curated, and every record enters it through review, not through an upload.

Bulk data and citation

Complete CSV/JSON exports and versioned snapshots are on Data & citation. If you use the Atlas in published work, cite the dataset (concept DOI 10.5281/zenodo.22059963) and give the dataset version and corpus snapshot date from the meta block.