Paper2Agent turns a research paper and its repository into an MCP server

The gap Paper2Agent targets: papers ship code, not callable tools

A published paper usually arrives as a PDF, a methods section, and a repository with scripts that assume a particular dataset layout. Getting from that to something an AI assistant can call in a conversation normally means reading the repository, guessing entry points, and writing a wrapper by hand. Paper2Agent's stated goal is to automate that conversion: the README describes it as a multi-agent AI system that turns research papers into interactive AI agents with minimal human input, and the deliverable is described as reliable MCP servers and skills. The audience is therefore narrow and specific. You need a coding-agent host with skill support, shell access, and parallel subagent spawning enabled, because the coordinator launches specialist agents and fresh verifier agents through the host. If you only want to read a paper, this is the wrong tool. If you want the paper's method callable from Claude Code, Codex, or the Google Gemini CLI, it is aimed at you.

How the coordinator, specialists and verifiers divide the work

The architecture visible in the repository is a coordinator with two kinds of subordinate agents. The coordinator reads the skill instructions and spawns specialist agents in parallel, one per task or tutorial area, then spawns fresh verifier agents that were not involved in writing the code. That separation matters: a verifier that did not author the wrapper is less likely to accept the author's assumptions about an entry point. The output is not a notebook dump. It is an MCP server plus a ZIP delivery that includes a USAGE.md, and the README says that file records the tested interpreter, the server entry point, required environment variables, and supported platforms. The skill also prepares isolated project environments and records tested versions, which is the mechanism behind the word reliable in the project description. Credentials are handled by reference rather than by value: the README states that credentials stay outside generated code, notebooks, reports, and the delivered ZIP, and that the agent is told the environment variable name instead.

Installing the paper2agent skill and running a first conversion

There is no pip package here. Installation means copying the skill folder into your host's skill directory. The README gives the clone step first, then host-specific copy commands. Claude Code uses the personal skill location documented by Anthropic; Codex uses a different path. Copy the entire folder including subdirectories and supporting files, not just SKILL.md.

git clone https://github.com/jmiao24/Paper2Agent.git
cd Paper2Agent
mkdir -p "$HOME/.claude/skills/paper2agent"
cp -R skills/paper2agent/. "$HOME/.claude/skills/paper2agent/"

For Codex the README uses a different destination, and the command is otherwise the same shape.

mkdir -p "$HOME/.agents/skills/paper2agent"
cp -R skills/paper2agent/. "$HOME/.agents/skills/paper2agent/"

After copying, start your coding agent in the workspace where you want the generated project to live. If the skill does not appear, the README says to restart the coding agent. Then invoke it. The README's examples use Claude Code's slash invocation, and note that in Codex you replace it with $paper2agent.

/paper2agent Convert https://github.com/scverse/scanpy into tested MCP tools in Scanpy_Agent.
Focus on the "Preprocessing and clustering" tutorial.

What you should see at the end is a ZIP and a USAGE.md describing the tested interpreter, entry point, environment variables and platforms. To wire it into your client, the README suggests asking the agent directly: connect the generated MCP server to my coding-agent client using its USAGE.md. For a hosted HTTP server the connection is a single documented command.

claude mcp add --transport http <MCP_NAME> <MCP_ENDPOINT_URL>

Where the conversion breaks: hosts, runtimes and unverified claims

The hardest constraint is the host. Paper2Agent assumes a coding agent that can spawn parallel subagents, and the coordinator's whole design depends on that. A host without subagent support leaves you with instructions you cannot execute, and the README does not describe a fallback path for that case. The second constraint is runtime: the skill inherits whatever the selected repository needs, which the README lists as Python and Git plus any R, native CLI, data, API or GPU requirements. A paper whose method needs a GPU or a private dataset will produce a server whose tools cannot actually run in your environment, and the tested versions recorded in USAGE.md will reflect the environment where conversion happened, not yours. Third, the verification step is only as strong as the verifier's ability to execute the code. The README says the skill installs the generated server's dependencies in its project environment during conversion, but it does not document rollback, nor how a partially converted paper is resumed. Treat a conversion that stops midway as something you restart rather than repair.

Paper2Agent against hand-written MCP wrappers and hosted servers

The obvious alternative is writing the MCP server yourself. That gives you full control over which functions are exposed, how errors surface, and how dependencies are pinned, and it is the right call when the repository has one or two clean entry points you already understand. Paper2Agent's difference is scale and evidence: it parallelises across tasks or tutorials, and it produces a verifier pass plus a USAGE.md that names tested versions. A second alternative is connecting to an already hosted server rather than generating one. The README points to a set of connectable paper MCP servers on Hugging Face, for example a hosted AlphaGenome server, and the connection is a transport plus endpoint URL. That route skips installation and local runtime entirely, at the cost of depending on someone else's deployment and its authentication requirements. Choosing between the two is mostly a question of whether you need the tools running against your own data.

Licence, upgrade cost and what the repository does not say

The repository carries an MIT licence, which is permissive and places few restrictions on reuse of the skill files. That covers the skill itself. It does not cover the papers or repositories you point it at, and those carry their own licences and their own terms for redistributing code. Generated servers bundle or invoke third-party scientific code, so the licence you must satisfy is usually the target repository's, not Paper2Agent's. The README does not discuss this, and it is worth checking before you ship a generated server anywhere shared. On upgrades, there are no releases retrieved, so there is no versioned changelog to read. The skill lives in the repository's skills/ directory and is copied wholesale into your host, which means updating is a re-copy of that folder rather than a package manager operation. The last push to the default branch was on 2026-09-16. Because the skill is instructions plus supporting files rather than a pinned dependency, an update can change the workflow your agent follows without any version number changing.

Editorial conclusion

Adopt Paper2Agent if you already run Claude Code or Codex with parallel subagents and want a paper's code exposed as MCP tools you can call in conversation. Skip it if you have no coding-agent host, no shell access, or no repository to run, because the skill's verification step depends on executing the code. Before committing, confirm that your host can spawn parallel subagents, that you can copy skills/paper2agent into the documented skill directory, and that the target repository's R, CLI, data, API or GPU requirements are available in your environment, since the generated USAGE.md records only the versions that were actually tested.

Frequently asked questions

Official sources

1. Issues
2. jmiao24/Paper2Agent on GitHub
3. License: MIT
4. README