All articles

Connect your AI assistant to ScholarThread (MCP)

Give Claude Code, Claude Desktop, or any MCP-compatible assistant direct access to your ScholarThread library and concept notes — how to set up a key and what the assistant can actually do with it.

The ScholarThread team21 August 20264 min read

If you already draft notes with an AI assistant — Claude Code, Claude Desktop, or anything else that speaks MCP (the Model Context Protocol) — you can point it directly at your ScholarThread library. It searches your papers, drafts and updates concept notes, records claims, and links evidence, using the same rules the web app enforces.

This is not a chatbot bolted onto ScholarThread. It is your own assistant, running wherever you already run it, given a scoped key to your library.

Step 1 — Create an API key

Open Settings → API keys and create a key:

  • Name it something that tells you where it's used later — "Claude Code — laptop" is more useful in six months than "key 1".
  • Scope: choose Read if you only want the assistant to search and browse, or Read + write if you want it to create and update concepts, record claims, and link evidence. Read + write also covers triggering evidence extraction, which calls out to a model on ScholarThread's side — a metered operation, not a plain database write.

The key is shown to you exactly once, immediately after creation. Copy it before dismissing the dialog — ScholarThread does not store the plaintext and cannot show it to you again. If you lose it, revoke it and create a new one.

Treat the key like a password. Anyone holding it can act as you, within its scope, for as long as it's active. Revoke a key the moment you stop using it — from the same page, no confirmation email, no waiting.

Step 2 — Connect your assistant

For Claude Code, add the server from a terminal:

claude mcp add --transport http scholarthread \
  https://api.scholarthread.com/mcp \
  --header "Authorization: Bearer stk_your_key_here" \
  --scope user

(Use https://api-staging-local.scholarthread.com/mcp if you're on a staging-local deployment.) --scope user makes the connection available everywhere you run Claude Code, not just one project directory — useful since your notes and papers aren't tied to any single codebase. Run claude mcp list to confirm it connected.

For Claude Desktop or another MCP client, the shape is the same: a Streamable HTTP server at that same URL, authenticated with an Authorization: Bearer header carrying your key. Check your client's own docs for exactly where to paste the URL and header.

What the assistant can actually do

Once connected, the assistant has tools to:

  • Search your library and look up a specific paper.
  • List and read concept notes, including the standard template (Definition / Why it matters / Open questions / Related concepts).
  • Validate a draft concept body against that template before writing it.
  • Create and update concepts, record claims on them, and link a claim's evidence to a paper, passage, another note, or another claim — with a read + write key.
  • Trigger evidence extraction for a concept against papers already in your library — a longer-running, model-backed job, also read + write only.

There's also a short resource the assistant can read on its own — scholarthread://import-guide — covering a few things worth knowing up front:

  • The assistant can't add a paper to your library. Searching and reading are the only paper-facing tools; a paper has to already be in ScholarThread (via Zotero sync or the web app) before a claim can cite it. If your assistant is walking through a folder of notes that cite sources you haven't imported yet, expect claims without linked evidence until you import those papers separately.
  • [[Title]] in a note body really does create a link — writing a wikilink into a concept section, where another concept already exists under that exact title, resolves into a real link between them, the same as typing it in the ScholarThread editor.
  • The four-section template is a floor, not a ceiling. If your own notes carry more structure — a "tensions with other work" section, source annotations — there's no dedicated slot for that yet; the assistant (or you) will fold it into "Why it matters" or "Open questions" as fits.

A realistic first session

A good way to get a feel for it: point your assistant at a folder of existing notes — an Obsidian vault, a set of literature notes, whatever you already have — and ask it to draft one or two as ScholarThread concepts first, before turning it loose on the whole folder. Check what it produces against your own notes, adjust how you're prompting it, and only then let it work through more.

Scope and safety, briefly

  • A key only ever acts within your own tenant — it cannot see or touch anyone else's library, notes, or papers.
  • Read-scoped keys cannot write anything, even if the assistant tries.
  • Every write still goes through the same validation the web app uses — a malformed concept body is rejected the same way whether it came from your keyboard or your assistant.

If anything looks off — a link that shouldn't exist, a claim you didn't expect — the fix is the same as anywhere else in ScholarThread: edit or delete it directly in the app. The assistant has no more authority over your library than the scope of the key you gave it.