Paper2Agent, Which Turns a Research Paper Into an AI Agent, Was Published in Nature on September 16, 2026

Paper2Agent is a multi-agent framework that reads a paper together with its code repository, converts both into a Model Context Protocol (MCP) server, and connects that server to a chat agent such as Claude Code so the paper's tools and workflows run through natural language. Nature published the work on September 16, 2026 under the title "Reimagining research papers as interactive and reliable AI agents" (DOI 10.1038/s41586-026-11044-y), authored by Jiacheng Miao, Joe R. Davis, Yaohui Zhang, Jonathan K. Pritchard and James Zou of Stanford. The paper builds an agent that uses AlphaGenome to interpret genomic variants and agents built on ScanPy and TISSUE to run single-cell and spatial transcriptomics analyses, validates that they reproduce the original results, and reports that an automatically created AI co-scientist identified a new splicing variant associated with ADHD risk. The GitHub repository is published under the MIT license with 2.5k stars and 374 forks. ASAP works only from the arXiv text and the official repository to set out what this changes about how papers circulate.

What happens when one paper becomes one MCP server

Paper2Agent does not summarize a paper; it converts the paper's code into a list of executable tools. According to the official repository, the system coordinates parallel specialist agents that read the paper content and the associated code repository, run conversion workflows, pass through verification steps, and deliver a tested MCP server as a ZIP file accompanied by usage documentation.

The core is not the conversion but the verification loop bolted onto it. The arXiv abstract states that the system systematically analyzes the paper and the associated codebase using multiple agents to construct an MCP server, then iteratively generates and runs tests to refine and robustify the result. Reading a paper and wrapping its code is something several tools already attempted; the part this work adds is the stretch where the wrapper is hammered on by automatically generated tests until it holds.

The fact that the output follows the MCP specification is what fixes the distribution path. The repository states that generated tools connect to coding agents such as Claude Code, Codex and the Google Gemini CLI. The listed requirements are Python, Git, a coding-agent host with skill support and shell access, and per-project runtime dependencies including R, CLI tools, APIs and GPU resources. In Claude Code the installation is two lines that copy the repository's skills/paper2agent folder into the home skills directory.

The two bars AlphaGenome, ScanPy and TISSUE were used to clear

The paper's chosen cases are AlphaGenome, ScanPy and TISSUE, and the validation is split across two distinct bars. The AlphaGenome-based agent handles genomic variant interpretation, while the ScanPy and TISSUE agents carry single-cell analysis and spatial transcriptomics respectively.

The abstract's validation sentence separates into two items: that the paper agents can reproduce the original paper's results, and that they can correctly carry out novel user queries. These bars differ in difficulty. Reproduction retraces a path for which the paper already recorded the answer, while a novel query combines the tools in ways the authors never anticipated. Code release on its own only ever guaranteed the first one.

Quantitative evaluation is split out into a separate artifact. The official repository points to a distinct GitHub repository named Paper2AgentBench for comprehensive evaluation metrics. Neither the Nature title nor the arXiv abstract presents a single headline number such as a conversion success rate or tool-call accuracy; the evidence the paper leads with is in-depth case studies.

The ADHD splicing variant is an existence proof, not a success rate

The strongest claim in the arXiv abstract is that the AI co-scientist Paper2Agent created automatically identified a new splicing variant associated with ADHD risk. The first thing to check in that sentence is the level of the claim. The abstract's word is associated, and it asserts no causality. This is a hypothesis produced computationally, and experimental confirmation falls outside the scope of this paper.

What makes the result interesting is the route that produced it rather than the finding itself. The variant was surfaced not by one tool but by a composition of tools originating in different papers. Joining paper A's method to paper B's processing pipeline by hand requires standing up both environments and reconciling input and output formats. Once each is wrapped as an MCP server, that joining cost collapses to a single tool call. What the paper actually demonstrates is that combinatorial search starts on its own once the joining cost falls far enough.

The same single result must not be mistaken for a performance figure. One new variant is an existence proof, and no published document gives a rate at which paper-agent compositions produce valid hypotheses. The question a lab should ask before adopting this is not how many discoveries have been reported but how often a wrong hypothesis arrives in a plausible-looking form. The automatically generated tests verify that code runs, not that a method is scientifically sound.

What changed during the twelve months between preprint and publication

The Paper2Agent preprint went up on arXiv as v1 on September 8, 2025 and was updated to v2 on October 16, 2025, with Nature publication following on September 16, 2026. Review therefore took close to a year, and that interval says a great deal about the nature of this work.

Over the same stretch MCP hardened into the de facto connection standard for coding agents, and the Paper2Agent repository accumulated 2.5k stars and 374 forks. The practical distribution of this paper happened a year before its formal publication. The repository carries the MIT license, so anyone could take it and modify it. A study about turning papers into tools spread through repository distribution faster than through journal publication, which substantiates its own argument.

It also clarifies where the reproducibility conversation had been stuck. Releasing code and data is an old norm, and containers and notebooks succeeded at preserving execution environments. What they never preserved was intent. Which function is the right tool in which situation, and what shape the input has to take, largely stayed scattered across the paper body and example notebooks. An MCP server's tool descriptions pin exactly that layer in a machine-readable form. The substance of this paper is that the unit of dissemination drops from the PDF to the tool specification.

What teams can apply today and what still has preconditions

The immediately actionable step for any lab is running the MIT-licensed Paper2Agent repository against its own paper repository. The requirements are Python, Git and a coding-agent host with skill support and shell access. Papers whose repositories are well organized and ship working examples see the benefit first, while repositories with broken examples or unpinned dependencies stall at the conversion step.

For teams that account for citation and adoption separately, this creates a new signal. Journal citation is slow and hard to influence, but publishing a method as an accompanying MCP server opens a path where another researcher's agent calls that tool directly. Every call is a use of the method, and used methods find their way back into papers. This case has already shown that repository signals move faster than review cycles.

The same structure applies inside companies. Internal technical documents and analysis scripts pile up unread, and the cost of getting new staff to that asset absorbs most of any handover. The procedure for converting a paper maps directly onto an internal document and code-repository pair. Because the approach presumes shell access and runtime execution, data-access permissions and internal security policy have to be settled first.

Remaining limits and the questions to ask

Paper2Agent's output quality is set by the condition of the original repository. A paper with no code, a paper whose data access is closed, or a repository with unpinned dependencies leaves nothing to convert. The tests the system generates repeatedly confirm whether a tool executes and whether the output format holds; they are not a mechanism for judging whether a method is scientifically valid.

The second question is maintenance. An MCP server, once built, is bound to the repository state at that moment. When the upstream repository is updated or a dependency shifts, the tool drifts quietly out of alignment. Any organization using paper agents in earnest needs to manage conversion output as a build artifact, with a reconversion cadence and version-handling rules attached.

The third is attribution. What happens to credit when an agent calls paper A's tool to produce a result is not addressed here. Under the current structure the call survives in tool logs and not in the final output. The more that papers circulate as tools, the more the practical question becomes how citation systems absorb those logs. Anyone who wants the quantitative picture first should start from the evaluation metrics in the Paper2AgentBench repository.

Source: Paper2Agent: Reimagining Research Papers As Interactive and Reliable AI Agents (arXiv:2509.06917) · jmiao24/Paper2Agent official repository (MIT license) · Reimagining research papers as interactive and reliable AI agents (Nature, September 16, 2026, DOI 10.1038/s41586-026-11044-y)