co-scientist-plugin
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@co-scientist-pluginStart a research session to find new drug targets for Alzheimer's"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
co-scientist plugin
Run a multi-agent scientific research engine from inside your coding agent.
An Agent Plugins 1.0 package that lets Claude Code, Codex CLI, Cursor, VS Code, Copilot and Kiro drive the AI co-scientist engine: generate hypotheses, review them, settle them in an Elo tournament, evolve the winners, and read the synthesis back.
Install · What the agent gets · The design rule · Works with ScientistOS · Contributing
The idea
The AI co-scientist engine is an open re-implementation of Gottweis et al., Nature, 2026. It takes a research goal and runs six specialist agents over it: Generation, Reflection, Ranking, Evolution, Proximity and Meta-review, scheduled by a Supervisor over a durable SQLite task queue.
That engine has a CLI. This package gives it an agent-facing surface, so the thing driving it can be Claude Code or Codex rather than you typing commands:
you → "review hypothesis 3 in that Crohn's session and tell me what breaks"
agent → reads the hypothesis, searches the literature, applies the rubric,
records the review into the engine's database, reports the verdictThe review it wrote is now a row in the same table the engine's own Reflection agent writes to. It counts toward the tournament. The meta-review will see it.
Related MCP server: consensus-mcp
What the agent gets
One MCP server with fifteen tools:
Group | Tools |
Lifecycle |
|
Reading |
|
Writing |
|
Diagnostics |
|
Seven skills carrying the judgement the tools cannot:
Skill | What it does |
| Sharpens a vague goal into a real one, gates on the size of the run, starts and monitors it |
| Reads the ranked output honestly, with five known failure modes checked |
| Reviews against a rubric with score anchors and a verdict decision rule, then records it |
| Runs a three to five turn debate, decides on ordered criteria, records the Elo match |
| Combine, simplify, feasibility, out-of-box, each with its own reference file and failure mode |
| Cross-model Elo bench, and how to read a result without overclaiming |
| Checks that citations say what they are claimed to say, per claim, with verdicts |
The design rule
The engine keeps all state: Elo, the task queue, dedup, embeddings, the token budget, termination. This package reimplements none of it.
Everything an agent produces goes back in through the same repositories the
engine's own agents write to. match_record reuses the engine's Elo module and
its elo_journal idempotency. review_record writes the same Review model
and promotes draft to reviewed exactly as Reflection does.
hypothesis_record derives created_by from whether parents were given.
The skills state the consequence in plain words: output that is not recorded
does not exist. An agent that describes a review in chat without calling
review_record has produced nothing the system can use.
This is what stops the common failure of "port the prompts to skills and call it done". The prompts are not where the quality comes from. The tournament is, and a tournament needs somewhere to keep score.
Works with ScientistOS
This plugin generates and ranks candidate hypotheses. It does not decide what
you are allowed to claim from them, and the difference matters: a hypothesis
can top the tournament and still rest on a mechanism the literature
contradicts. The reading-research-overviews skill lists that failure mode and
several others to check by hand.
ScientistOS makes that check structural instead of advisory. It keeps a typed evidence graph and refuses to record a claim at a strength its lineage does not support.
this plugin → ranked hypotheses, reviews with claim / url / excerpt per source
↓
ScientistOS → hypothesis and source nodes, evidence at its honest level,
an integrity gate before anything gets written upThe two install side by side, since both are skill and MCP packages, and an agent with both loaded gets the whole path. Nothing here requires ScientistOS, and ScientistOS does not depend on this.
Install
No API key, and nothing to decide about billing. If you are reading this you already have the Claude Code or Codex CLI signed in, and that is the whole requirement: the research engine runs its agents through the same subscription your coding agent uses.
python3.12 -m venv .venv
source .venv/bin/activate
pip install "co-scientist @ git+https://github.com/Kaimen-Inc/Co-Scientist.git"
pip install "co-scientist-plugin @ git+https://github.com/Ahmad-Jaradat-Space/co-scientist-plugin.git"
co-scientist initOn first connection the server looks for a working backend. Finding none, it
adopts whichever agent CLI is installed and signed in, writes that choice to
~/.co-scientist/config.toml, and gets on with it. An existing provider =
line is never touched, so a setup you configured yourself is left alone. Set
COSCI_AUTO_BACKEND=0 to turn the whole thing off.
If doctor still reports no backend, sign the CLI in (claude, or
codex login) rather than reaching for a key. It will also report a local hash
embedder, which is the expected keyless state: dedup catches repeated wording
but not two hypotheses that say the same thing differently.
Everything stays on your machine: SQLite under ./data, no account, no service
to sign up for, and no traffic beyond the model calls your CLI was already
making.
config/subscription.toml is the same choice
written out by hand, with the model ids pinned rather than left to the alias
your CLI resolves. Point the engine at it with
export COSCI_CONFIG=/path/to/config/subscription.toml.
A metered API works too: set a provider and key in
~/.co-scientist/config.toml before first run and auto-selection stays out of
the way. estimate_cost then prices the run against a budget, and the skills
ask for a go-ahead on spend rather than on time. See the
engine's backend guide.
Codex CLI
codex plugins install ./co-scientist-pluginClaude Code
ln -s "$PWD/skills/"* ~/.claude/skills/
claude mcp add co-scientist -- co-scientist-mcpAnything else
Any client that reads Agent Plugins 1.0 loads the directory as it is. Any client
that reads SKILL.md and MCP config separately can take skills/ and mcp.json
on their own.
Configuration
The server reads the engine's config. Set these in the env block of your
mcp.json if you need them:
Variable | Effect |
| Path to an extra TOML config to overlay |
|
|
| Seconds to wait for a spawned run to register, default 120 |
|
|
Read-only installs
A session makes hundreds of model calls and keeps running after the conversation ends. On a shared machine, or anywhere an agent should not be able to start one on its own:
co-scientist-mcp --read-onlyReads keep working; session_start and session_resume refuse with an
explanation.
Virtualenv paths
mcp.json calls co-scientist-mcp, which assumes the console script is on
PATH. If your agent does not activate the virtualenv, use an absolute path:
{
"command": "/path/to/.venv/bin/co-scientist-mcp",
"args": []
}Development
pip install -e ".[dev]"
ruff check coscientist_plugin tests
pytest -q
co-scientist-plugin-validateEvery test runs offline against a throwaway database. No key, no network, no model calls.
Three checks guard this package:
co-scientist-plugin-validatechecks spec conformance: the ten permitted manifest fields, transport types, skill frontmatter, name and directory agreement, body length, and that every relative link resolves and stays one level deep.tests/test_plugin.pychecks what a validator cannot: that no skill tells an agent to call an MCP tool or an engine command that does not exist, and that the recording discipline is actually stated in the skills that write.tests/test_server.pycovers the invariants the design rests on: zero-sum Elo, idempotency per round, cross-session refusal, evidence without an excerpt refused, and state transitions that never drag a ranked hypothesis backwards.
Relationship to the engine
This repository is the plugin layer only. The engine it drives lives at
Kaimen-Inc/Co-Scientist and is a
separate project under the same licence. See NOTICE.
Neither project is affiliated with Google or with the paper's authors. Hypotheses either one produces are a starting point for a scientist, not a finding.
Licence
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Servers
- AlicenseAqualityAmaintenanceAn MCP server that lets Claude Code consult stronger AI models (o3, Gemini 2.5 Pro, DeepSeek Reasoner) when you need deeper analysis on complex problems.1102129MIT
- AlicenseNot gradedqualityCmaintenanceAn MCP server that enables multi-model debate and consensus building through a single tool. It orchestrates multiple AI models from various providers to debate topics and reach validated conclusions with real-time progress tracking.323MIT

multivon-mcpofficial
AlicenseAqualityAmaintenanceMCP server that gives AI coding agents direct access to evaluation tools.22Apache 2.0- AlicenseAqualityDmaintenanceMCP server that lets Claude Code ask GPT Codex for adversarial planning, code review, debugging, research, and risk triage without leaving your project workflow.971MIT
Related MCP Connectors
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
MCP server for AI dialogue using various LLM models via AceDataCloud
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Ahmad-Jaradat-Space/co-scientist-plugin'
If you have feedback or need assistance with the MCP directory API, please join our Discord server