iReading Room
Try it free

Blog

MCP Server for Research Papers: Claude Code, Codex and Any AI Agent

Connect Claude Code, OpenAI Codex or any MCP agent to an MCP server for research papers, and give it this week's arXiv papers that fit your project.

Your AI coding agent can read your whole repository in seconds.

Ask it what was published on arXiv this week about the problem you're working on, and it has nothing to say. Or worse, it searches the web and comes back with the same two-year-old papers everyone else already knows.

This post shows how to fix that in about five minutes. You'll connect your AI agent to the iReading Room MCP server for research papers, so it can fetch the new arXiv papers that match your project and turn them into a plan for your code.

We'll use Claude Code and OpenAI Codex as the worked examples. The same server works with Cursor, GitHub Copilot, Gemini CLI, Cline, OpenCode, Claude Desktop and any other agent that speaks MCP.

Why your AI coding agent doesn't know this week's research

An AI model learns from what was written before its training ended. When it searches the web, it finds what the web has already noticed: papers with citations, blog posts and threads.

A paper published on Tuesday has none of those yet. For a few weeks, sometimes months, it sits on arXiv where almost nobody reads it. We wrote about that window in Why We Look Forward, Not Backward.

There's a second problem. Even if your agent could read every new paper, it doesn't know which ones matter to you. It knows your code. It doesn't know where your team is going.

What the iReading Room MCP server gives your agent

MCP, the Model Context Protocol, is the open standard AI agents use to call outside tools. Because it's a standard, one server works with every agent that supports it.

Every day, iReading Room reads the new arXiv papers in the categories you follow against a plain description of what you're building. The strongest matches go through a closer review and get a short summary checked against the paper itself. Those are your recommended papers.

The iReading Room MCP server opens that work to your agent: which new papers fit your project, what each one is about, why it was picked and where to read it.

So your agent starts from the few papers that already fit your project, not from a search engine's idea of what's popular. It also uses far fewer tokens than having the agent read arXiv itself.

We keep adding to what the server can do as our customers tell us how they work. You don't need to change anything when we do: an MCP agent asks the server what it offers each time it connects, so new tools simply show up.

Create a personal access token

In the iReading Room app, open Settings → MCP → Agent access.

  1. Give the token a name you'll recognise later, for example Codex on my laptop.
  2. Choose when it expires: after 30, 90 or 365 days.
  3. Press Create token and copy it straight away. You won't see it again.

Keep the token in an environment variable, not in a file you commit:

export RR_TOKEN=<paste the token>

Make one token per agent or machine. If one leaks, revoke just that one in the same screen; changing your password revokes them all.

Connect any AI agent to the MCP server

Whichever agent you use, it needs the same two things:

  • The server URL: https://app.ireadingroom.com/api/mcp (MCP over HTTP)
  • One header: Authorization: Bearer <your token>

That's all. Every MCP client that lets you add a header can connect. Here's what it looks like in the most popular ones.

Example: Claude Code

Claude Code adds remote MCP servers with one command:

claude mcp add --transport http reading-room \
  https://app.ireadingroom.com/api/mcp \
  --header "Authorization: Bearer ${RR_TOKEN}"

Start Claude Code and run /mcp. You should see reading-room connected, with its tools listed.

Example: OpenAI Codex

Codex keeps its MCP servers in ~/.codex/config.toml. Add:

[mcp_servers.reading-room]
url = "https://app.ireadingroom.com/api/mcp"
bearer_token_env_var = "RR_TOKEN"

bearer_token_env_var tells Codex to read the token from your environment and send it as the Authorization header, so the file holds no secret. Start Codex from the same terminal and run /mcp to check the server is there.

Cursor

Add the server to ~/.cursor/mcp.json (all projects) or .cursor/mcp.json (one project):

{
  "mcpServers": {
    "reading-room": {
      "url": "https://app.ireadingroom.com/api/mcp",
      "headers": { "Authorization": "Bearer ${env:RR_TOKEN}" }
    }
  }
}

Restart Cursor, then open the MCP section of its settings: reading-room should show a green dot.

GitHub Copilot in VS Code

Copilot's agent mode reads .vscode/mcp.json. This version asks for the token once and stores it securely, instead of keeping it in the file:

{
  "inputs": [
    { "type": "promptString", "id": "rr-token", "description": "iReading Room token", "password": true }
  ],
  "servers": {
    "reading-room": {
      "type": "http",
      "url": "https://app.ireadingroom.com/api/mcp",
      "headers": { "Authorization": "Bearer ${input:rr-token}" }
    }
  }
}

If you use Copilot through work, your organisation has to allow MCP servers.

Gemini CLI

Gemini CLI adds a remote server with one command:

gemini mcp add --transport http reading-room \
  https://app.ireadingroom.com/api/mcp \
  --header "Authorization: Bearer ${RR_TOKEN}"

OpenCode

In opencode.json, add a remote server and read the token from your environment:

{
  "mcp": {
    "reading-room": {
      "type": "remote",
      "url": "https://app.ireadingroom.com/api/mcp",
      "oauth": false,
      "headers": { "Authorization": "Bearer {env:RR_TOKEN}" }
    }
  }
}

Cline, Claude Desktop and other MCP clients

In Cline, open the MCP Servers panel and add a remote server with the same URL and Authorization header.

Claude Desktop connects to a remote server with a token through a small bridge, mcp-remote, which runs with npx (so you need Node.js). Open Settings → Developer → Edit Config and add:

{
  "mcpServers": {
    "reading-room": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://app.ireadingroom.com/api/mcp", "--header", "Authorization:${AUTH_HEADER}"],
      "env": { "AUTH_HEADER": "Bearer <paste the token>" }
    }
  }
}

The header has no space after the colon on purpose: some setups split arguments at spaces.

For any other client, look for "remote MCP server", "HTTP" or "streamable HTTP" in its settings and add the URL and header above. One exception to know: the custom connectors on the claude.ai website need a different sign-in method and aren't supported.

Prompts that turn a paper into a plan

Once it's connected, you don't call any tool yourself, and you don't need to learn their names. You ask in plain words, in whichever agent you use, and it picks the right tool when it needs one.

Start simple:

"Get today's matches from reading-room. For each paper, tell me in two sentences whether it applies to this codebase."

Then point it at your code:

"Look at my reading-room matches from the last three days. Pick the one most relevant to our retrieval code in src/search/. Read the paper, then write a plan: what we'd change, how we'd measure it, and what the paper says about where the method breaks."

Or ask about one part of your work:

"Which of this week's reading-room papers could change how we rank search results? Compare each method with what we do today."

This is the loop from Your Code Only Knows Where You've Been: your team writes the goal, iReading Room finds the new research, and your agent connects it to the code it can already read.

What your agent's AI model sees

What your agent fetches from iReading Room, such as your recommended papers and the names of your research interests, goes to the AI model your agent uses. Nothing is sent anywhere until you make a token and connect an agent, and you can revoke a token at any time.

The privacy page always has the current details.

Why not just ask your agent to search arXiv?

You can, and for a known question it works. If you already know the name of the method you want, search is the right tool.

But finding the paper published today that matters to your product is a different job, and an expensive one.

Hundreds of new papers land on arXiv every day. To find the one that fits your work, your agent would have to fetch them, read them and weigh each one against your project. Then do it all again tomorrow. Almost all of those tokens go on papers that turn out not to matter, before a single line of your code changes.

And search still only answers the question you type. It won't tell you that a paper from Tuesday makes a decision you took in spring look expensive, because you'd never think to ask.

Your agent's tokens are better spent on your product than on searching.

With iReading Room, the searching is done before your agent arrives. It starts from the few papers that already fit your project, and spends its tokens where they pay off: reading the paper that matters, planning the change and building it in your codebase. That's far cheaper than having your agent do the research itself.

It's a simple split of work:

  • iReading Room reads every new paper against your project, recommends the right ones, and keeps the way it finds them up to date with the latest research and models.
  • You and your agent focus on your business: deciding what's worth trying, and turning the right paper into a better product.

Give your agent the newest research

Your agent already knows your code. Now it can know what was published this week about where your code is going, whichever agent your team prefers.

If you're a startup building on AI, here's how iReading Room fits a startup team. If you run an R&D team, here's the R&D version.

Create a token, connect your agent, and ask it what's new.