Your assistant and the record

An AI assistant such as Claude can ask the record for you through the Model Context Protocol, an open standard for giving an assistant tools. The site's tools find people, walk lineages, trace the routes between people and say where the record stops, and one reports a missing advisor or work. Every call is made under your own account and passes the same rules as a page: a person who asked not to be shown is never answered.

A tool call goes from your assistant through the connector, signed in as you, to the same answers the site's pages get, and on to the record. On the way back, a person who asked not to be shown is cut from the answer before it leaves.

What the Model Context Protocol is

An assistant such as Claude or ChatGPT is a language model in a conversation (where AI is used says what such a model does well and badly). On its own it answers from what its training left in it. A tool lets it ask something outside itself: a calendar, a library's catalogue, a record like this one. The Model Context Protocol, MCP for short, is an open standard for offering an assistant such tools, introduced by Anthropic in 2024 and now supported by assistants and programs from several companies.

It has two sides. The client is the assistant, or the program it runs in. The server is the service that offers the tools: here, the site's own MCP server, at the site's own address, built with FastMCP, an open-source library for writing one in Python. When the two connect, the server sends the list of its tools, each with a name, a description in words and the inputs it takes. The description is written for the model to read: it says what the tool answers and how to read the answer. The one for a lineage, for instance, ends by saying that a link's absence is the record stopping, never evidence of no students.

Then, in the conversation, the model decides for itself when a tool would help. Asked whether a reviewer is the academic sibling of an author, it may call the tool that finds each person by name, then the one that gives the routes between two people, filling in the inputs from what it has learned. The server answers each call; the model reads the answer and writes its reply. The tool gives the model facts to answer from, but the words of the reply are still the model's.

You ask your assistant a question. Its model, told when it connected which tools the site offers and what each takes, calls a tool with inputs it fills in itself; the site's server asks the record's answers, as a page does, and sends the answer back; the model reads it and writes its reply in its own words.

How it differs from browsing the web

An assistant that browses searches the web, opens pages written for people, and makes what it can of them. For a question about who supervised whom, that means a faculty page here, a genealogy's entry there, a thesis's acknowledgements somewhere else. It may read a namesake's page, an old one, or none, and its answer is its reading of whatever it found. Nothing on a page tells it where a list is incomplete.

A tool answers from the record instead, in a shape made for a program: the people with their ids, every link with its kind of evidence, cited, stated, extracted or inferred (where every link comes from), and where the record stops, said in so many words. The tool that traces the routes between two people answers in one of three ways: related, with the routes; not related within the record, both people being in it; or not covered, one of them having no record in any source the site reads, which is no evidence that the two are unrelated. A browsing assistant cannot tell those last two apart.

The assistant can still misread an answer, or say more than it holds. Ask it to name the kind of each link and the thesis it rests on, and look at what matters on the person's page or the thesis's, which are drawn from the same record.

The tools

The site's server offers 14 tools. A scholar rarely names one: the assistant picks them as a question needs. Grouped by what they answer, with the line the page for developers gives each:

Finding a person: find_person: ranked candidates for a name, with the facts that tell them apart; person: one person whole: theses, roles held, Wikidata's facts
Advisors, students and the people beside them: lineage: advisors up, students down, each link with its kind and run; students_of: a person's own doctoral students, with the year of each thesis; around: everyone beside the lineage: committees, coauthors, teachers
How people are related: relation_between: the shortest routes between two people, or where the record stops; ties: the fewest routes that tie two to six people together
Schools: schools: the schools the record follows doctors from, counted and filtered; school: one school's flows: where its doctors went on to supervise
Where the record stops, and why a link stands: coverage: where the record stops for a person; sources: the sources read and the ones known and not read; evidence: the line a model read off a thesis for an extracted link
Finding a reviewer or opponent: find_reviewers: who could review or oppose a work: no coauthor, advisor or student of its authors, their work fitting its key words, by rank
The one that writes: report_missing: a missing advisor or a missing work reported, the one tool that writes

A typical question takes several: a name is found first, since the tools about a person take the id the search gives, and the lineage, the routes or the coverage are asked of that id after.

Signing in, and keys

A connector is added to an assistant at the address of the provider you sign in with: ORCID, Google or GitHub. ORCID is the one to pick, the identity academics already hold. Signing in uses OAuth, the standard by which one service lets another act for you: the assistant sends you to the provider's own page, you sign in there, and the assistant is given a token for this site alone. It never sees your password, and the account the site makes holds the identifier the provider gives, with your name and email where the provider gives them.

Your first sign in makes your account, the same one you sign in to on the site itself. A program that cannot sign in through a browser, such as a command-line assistant or a script, carries a key instead, made on your account page and shown once; an account holds 5 live keys at once.

Each account has a daily allowance, counted to midnight UTC: on the free plan 1,000 answers and 100 searches of OpenAlex's authors, a search the site pays for, and on the institution plan 10,000 answers and 1,000 searches. The addresses to add, and the one line that adds the connector to Claude Code, are on the page for developers.

The same rules as a page

Every tool but one is a call to the same answers the site's pages are drawn from, made in your name. So what holds for a page holds for an assistant. A person who asked not to be shown is cut from every answer before it leaves the record, however it was asked. A person asked for by an id the record has since moved is answered under the id they are under now. And an account gets 120 answers a minute, as a reader does, counted under the account and not the address assistants share.

Every call is counted under your account: which tool, what was asked, whether it answered. The privacy notice says what is kept and for how long, and the terms what an account may be used for: asking questions, not copying the record whole.

The tools read the record and never change it. The one that writes, report_missing, sends what the form at /missing sends, a missing advisor or a missing work. It is checked against Wikidata and the record when it comes, and kept for the project to read; it is never drawn or counted, and it is a note, not a link.

What your assistant does with an answer is its own. The answers go into your conversation, which your assistant's provider, Anthropic for Claude or another company for another assistant, holds under its own terms.