evo2-mcp-server
Evo2-7B Bioinformatics MCP Server
一个把 NVIDIA 托管的 Evo2-7B Forward API 封装成 MCP (Model Context Protocol) Tools 的服务器,让 Claude Code、Cursor、Codex 等 Agent 可以用自然语言驱动 Evo2:
Agent
↓
MCP Tool
↓
Evo2 MCP Server(本项目)
↓
NVIDIA Evo2-7B Forward API
↓
forward outputs → likelihood / variant scores
↓
AgentPOST https://health.api.nvidia.com/v1/biology/arc/evo2-7b/forward
Authorization: Bearer $NVIDIA_API_KEY1. 项目介绍
提供 5 个 MCP Tools:
Tool | 作用 |
| 对 DNA sequence 执行 Evo2-7B forward inference,返回指定 layer 的输出统计(或保存原始 tensor) |
| 计算 Evo2 模型对 DNA sequence 的 model-based likelihood(total / mean / per-position) |
| 比较单个 nucleotide variant 对 Evo2 sequence likelihood 的影响(Δ log-likelihood) |
| 批量比较多个 nucleotide variants(复用一次 WT forward,并发受限,自动去重) |
| 对 FASTA 中每个 record 评分(本地路径受 |
本项目是 Bioinformatics MCP Tool Server,不是简单的 HTTP API wrapper:
自动校验 / 规范化 DNA sequence(大写、去空白、非法字符明确报错)
基于官方语义计算 likelihood(byte-level tokenizer + causal shift,见 §17)
输出分层设计(summary / raw / save),防止 MCP context 爆炸
完整错误分类(400/401/403/404/408/413/422/429/5xx/timeout)+ retry/backoff
API Key 只从环境变量读取,绝不写死、绝不进日志
配套批量脚本:
scripts/score_fasta.py(批量 FASTA 评分 + embedding 提取,见 §18)与scripts/analyze_run.py(聚类/分类/回归下游分析,见 §19)
Related MCP server: bio-mcp-evo2
2. Evo2 API 介绍
Evo2(Arc Institute / NVIDIA)是 DNA 基础模型(StripedHyena2 架构),7B 版 32 层、Apache-2.0、训练上下文达 1M bp。NVIDIA 提供托管 NIM 服务:
Forward 端点:
POST https://health.api.nvidia.com/v1/biology/arc/evo2-7b/forward请求体(官方 OpenAPI
ForwardInputs):{ "sequence": "ACGTACGT...", "output_layers": ["output_layer"] }output_layers支持 1–100 个 layer 名(如output_layer、decoder.layers.24.mlp.linear_fc2、decoder.layers.3.self_attention、embedding、decoder.final_norm)。响应体(官方 OpenAPI
ForwardOutputs):{"data": "<base64 编码的 NPZ>", "elapsed_ms": <int>};超大响应可能以Content-Type: application/zip(原始 NPZ 字节)返回。output_layer= 最终 logits,shape[seq_len, batch_size, 512](512 是 byte-level tokenizer 的 padded vocabulary size)。
⚠️ Deprecation 提醒(2026-08-24 核实):build.nvidia.com 上托管的
arc/evo2-7b端点已标记 Deprecated(页面提示 "This NIM Endpoint has been deprecated")。官方 NIM 文档(docs.nvidia.com/nim/bionemo/evo2/latest/)描述的 API 与托管端点完全一致;如托管端点不可用,可改为自托管 NIM 容器,把EVO2_MCP_BASE_URL指向http://localhost:8000/biology/arc/evo2。
已核实的官方事实(实现依据,2026-08-24)
项目 | 结论 | 来源 |
响应格式 | JSON | NVIDIA NIM endpoints 文档 + 托管 OpenAPI schema( |
|
| 同上("Final output/logits") |
vocabulary 大小 | 512(padded);byte-level tokenizer,每 bp = 1 个 token | NVIDIA 文档 + Arc/vortex |
A/C/G/T → logits index | A=65, C=67, T=84, G=71(ASCII 字节值) | NVIDIA 文档原文 + |
BOS/EOS/offset | 默认无 BOS(Arc | Arc |
likelihood 计算 |
| Arc |
特殊 token | 输出中只有 A/C/G/T 4 个 token 有意义(NIM 文档原文) | NVIDIA 文档 |
实测与文档的差异(2026-08-24 live 验证,任务要求记录实际接口)
用真实 key 探测托管 health.api.nvidia.com 端点后发现文档中的 layer 名在托管端不适用:
请求的 layer 名 | 托管 API 实际行为 |
| ❌ |
| ❌ 422 |
| ✅ 最终 logits:NPZ key |
| ✅ |
| ✅ |
| ✅ |
应对措施(已实现并 live 通过):
新增
EVO2_MCP_LOGITS_LAYER配置(默认auto):评分工具先尝试文档名output_layer,若收到422 has no attribute(托管端)自动切换到unembed并缓存,之后不再重复探测;自托管 NIM 2.x 容器则一次成功,零额外请求。NPZ 解析器同时支持裸 key(
output_layer)和<name>.output(unembed.output)两种 key 格式,并按"末维 = 512"启发式兜底。422错误信息现在会提示托管端可用的属性名。
如果返回的
seq_len与输入序列长度不一致(例如服务端加了 padding/BOS),本服务器拒绝计算 likelihood 并返回 raw 统计 + 明确说明,绝不猜测对齐。
3. NVIDIA API Key 获取方法
打开 https://build.nvidia.com/,右上角 Get API Key(需要登录 NVIDIA 账号)。
创建一个 key(形如
nvapi-xxxxxxxx...)。把它设置到环境变量,不要写进代码 / 配置 / Git:
export NVIDIA_API_KEY="nvapi-xxxxxxxx"或者复制
.env.example为.env并填入(.env已被.gitignore忽略)。
4. 安装
# 推荐:pip / uv
pip install -e ".[dev]"
# 或
uv sync --extra dev
# 推荐(本项目自带):pixi 项目本地环境
pixi install
pixi run test要求 Python >= 3.10(推荐 3.11+)。核心依赖:mcp>=2.0、httpx>=0.27、numpy>=1.26、pydantic>=2.6、python-dotenv>=1.0。分析脚本(scripts/analyze_run.py)额外需要 dev 依赖:scikit-learn、pandas、matplotlib。
5. 环境变量
变量 | 默认 | 说明 |
| 无(必填) | API Key,只从这里读取 |
|
| 服务地址(自托管 NIM 时修改) |
|
| HTTP 读超时(秒) |
|
| 408/429/5xx 最大重试次数 |
|
| batch/FASTA 并发上限 |
| 空 | FASTA 允许读取的目录( |
|
|
|
|
| 设为 |
|
| 序列长度硬上限 |
|
|
|
|
| per-position 列表返回上限(超出取头尾) |
|
| 评分用的 logits layer 名: |
6. CLI 启动
# 三种方式等价
python -m evo2_mcp
evo2-mcp
uv run evo2-mcp # 用 uv 管理的项目环境
# pixi 环境:
pixi run evo2-mcp服务器通过 stdio 与 MCP 客户端通信,正常启动后不会有输出(等待 MCP 握手)。
7. MCP 配置
Claude Code(.mcp.json)
{
"mcpServers": {
"evo2": {
"command": "uv",
"args": ["run", "evo2-mcp"],
"env": {
"NVIDIA_API_KEY": "${NVIDIA_API_KEY}"
}
}
}
}注意:
${NVIDIA_API_KEY}是否被客户端展开取决于客户端实现。最稳妥的方式是直接填入真实 key:
{
"mcpServers": {
"evo2": {
"command": "uv",
"args": ["run", "evo2-mcp"],
"env": {
"NVIDIA_API_KEY": "YOUR_API_KEY"
}
}
}
}但 千万不要把含真实 key 的 .mcp.json 提交到 Git(把该文件加入 .gitignore,或用环境变量/密钥管理工具注入)。也可以不传 env,让服务器进程自己从环境或 .env 读取 NVIDIA_API_KEY:
{
"mcpServers": {
"evo2": {
"command": "uv",
"args": ["run", "evo2-mcp"]
}
}
}Cursor(~/.cursor/mcp.json 或项目 .cursor/mcp.json)
{
"mcpServers": {
"evo2": {
"command": "uv",
"args": ["run", "evo2-mcp"],
"env": { "NVIDIA_API_KEY": "YOUR_API_KEY" }
}
}
}Codex(~/.codex/config.toml)
[mcp_servers.evo2]
command = "uv"
args = ["run", "evo2-mcp"]
env = { "NVIDIA_API_KEY" = "YOUR_API_KEY" }自托管 NIM
{
"mcpServers": {
"evo2": {
"command": "uv",
"args": ["run", "evo2-mcp"],
"env": {
"EVO2_MCP_BASE_URL": "http://localhost:8000/biology/arc/evo2"
}
}
}
}8. Tool 列表
evo2_forward(sequence, output_layers=["output_layer"], mode="summary", save_path=None)
对 DNA sequence 执行 Evo2-7B forward inference。mode:
"summary"(默认):每层返回shape / dtype / min / max / mean / std,context 安全;"save":把原始 tensor 存成.npz(output/evo2_forward_<时间戳>.npz),返回路径;"raw":内联完整 tensor(仅当元素总数 ≤EVO2_MCP_RAW_INLINE_MAX,默认 4096,防止 context 爆炸)。
layer 名注意:托管
health.api.nvidia.com端点接受的是模型属性名(logits 用unembed,另有embedding_layer、norm、blocks.N.mlp),文档名output_layer/decoder.layers.N.*只适用于自托管 NIM 2.x 容器。evo2_score/evo2_variant_score/evo2_batch_score/evo2_score_fasta会自动探测,无需手动指定;只有直接调用evo2_forward时需要按实际端点选名。
evo2_score(sequence, include_per_position=False)
计算 Evo2 对序列的 likelihood:
{
"sequence_length": 123,
"total_log_likelihood": -123.45,
"mean_log_likelihood": -1.2345,
"scored_positions": 122,
"per_position_log_likelihood": null,
"method_notes": "...",
"disclaimer": "..."
}语义(与 Arc 官方实现一致):logits[i] 预测位置 i+1 的碱基,在完整 512 vocab 上做 log-softmax 后取目标碱基字节索引;position 0 不参与计分,因此 scored_positions = length - 1,mean 是对这 N-1 个值取平均。per_position_log_likelihood[k] 对应序列 0-based 位置 k+1(即 1-based 位置 k+2)。若 API 返回的 seq_len 无法与序列对齐,不伪造结果,返回 raw 统计并明确说明:
Likelihood calculation is not supported until the API output format is verified.evo2_variant_score(sequence, position, ref, alt, coordinate="1-based", include_per_position=False)
{
"position": 100,
"ref": "A",
"alt": "G",
"wildtype_log_likelihood": -500.1,
"mutant_log_likelihood": -500.5,
"delta_log_likelihood": -0.4,
"interpretation": "The mutant sequence is less likely than the wildtype under Evo2-7B ... (NOT a clinical pathogenicity call)"
}校验链:position 范围 → coordinate 换算 → ref 必须与序列该位一致 → ref≠alt → 1-based 位置 1(0-based 0)不可评分(causal LM 无法给第一个 token 赋概率)→ 明确报错。
evo2_batch_score(sequence, variants, coordinate="1-based")
{
"sequence_length": 300,
"wildtype_log_likelihood": -1200.0,
"variants": [
{ "position": 100, "ref": "A", "alt": "G", "delta_log_likelihood": -0.42 },
{ "position": 200, "ref": "C", "alt": "T", "delta_log_likelihood": 0.13 }
]
}WT forward 只计算一次并复用于所有 variant;
相同
(position, alt)的 mutant 只 forward 一次(memoize);并发受
EVO2_MCP_MAX_CONCURRENCY限制(默认 2,尊重 NVIDIA rate limit);单个 variant 失败不影响整个 batch(逐条返回
error)。
evo2_score_fasta(fasta_path=None, fasta_text=None)
>sequence_1
ACGTACGT...
>sequence_2
TTGGCCAA...fasta_text:内联 FASTA(默认可用,有大小/记录数上限);fasta_path:仅当文件位于EVO2_MCP_ALLOWED_DIRS内才允许读取,否则明确拒绝;逐条返回
total_log_likelihood / mean_log_likelihood,单条错误不影响其余。
9. 使用示例
{
"sequence": "acgtACGT acgt", // 小写 + 空白自动处理
"output_layers": ["output_layer"],
"mode": "summary"
}返回:
{
"sequence_length": 12,
"requested_output_layers": ["output_layer"],
"returned_layers": ["output_layer"],
"layer_stats": [
{ "name": "output_layer", "shape": [12, 1, 512], "dtype": "float32",
"size": 6144, "min": -3.21, "max": 4.02, "mean": 0.01, "std": 0.98 }
],
"api": { "elapsed_ms": 87 }
}Agent 想要完整 logits 时:
{ "sequence": "ACGT...", "mode": "save" }{
"saved": true,
"path": "/abs/path/output/evo2_forward_20260824_153000.npz",
"bytes_on_disk": 24576,
"layer_stats": [...]
}10. FASTA 示例
{
"fasta_text": ">geneA\nACGTACGTACGT\n>geneB\nTTGGCCAATTGG"
}(或 "fasta_path": "/data/genomes/genes.fa",需配置 EVO2_MCP_ALLOWED_DIRS=/data/genomes)
大批量 FASTA(如整目录的 enhancer/promoter)评分 + 提取 embedding,用 scripts/score_fasta.py(见 §18)—— 每次运行输出独立 run 文件夹(scores.csv + embeddings.npz)。
11. Variant scoring 示例
{
"sequence": "ACGTACGTACGTACGTACGT",
"position": 10,
"ref": "A",
"alt": "G"
}12. Batch scoring 示例
{
"sequence": "ACGTACGTACGTACGTACGT",
"variants": [
{ "position": 10, "ref": "A", "alt": "G" },
{ "position": 12, "ref": "T", "alt": "C" },
{ "position": 14, "ref": "A", "alt": "T" }
]
}典型 Agent 工作流(对应"分析序列上所有 SNP,找 Evo2 score 变化最大的前 20 个"):
读取输入 → 解析 DNA / VCF → 生成 WT / mutant → evo2_batch_score
→ 按 |delta_log_likelihood| 排序 → 取前 20 → 保存 CSV → 解释结果13. 错误处理
HTTP | 含义 | 本服务器行为 |
400 | Bad Request(含非法序列等) | 直接报错,附响应摘要 |
401 | API Key 无效 | 直接报错,提示检查 |
403 | 无权限(托管端点已弃用等) | 直接报错,提示可能原因 |
404 | 路径不存在 | 直接报错,提示检查 |
408 | 服务端超时 | 有限重试(backoff)后报错 |
413 | Payload 过大 | 直接报错,提示减小序列或 layer 数量 |
422 | 参数校验失败 | 直接报错,附详情 |
429 | Rate limit | 重试 + exponential backoff(尊重 |
5xx | NVIDIA 服务端错误 | 有限重试后报错 |
timeout | 请求超时( | 明确报错: |
所有错误通过 MCP 返回结构化 JSON:{"error": "Evo2APIError", "message": "..."}。evo2_batch_score 中单条失败返回 {"error": ..., "status": ...},不中断整批。
14. Rate limit
NVIDIA 托管 NIM 有 rate limit。设计对策:
EVO2_MCP_MAX_CONCURRENCY(默认 2)限制并发;429 → exponential backoff(1s, 2s, 4s, 8s, 16s…,封顶 30s + 抖动;若有
Retry-After优先遵循但封顶 60s);重试上限
EVO2_MCP_MAX_RETRIES(默认 4),不会无限重试;batch 内 WT 只算一次、相同 mutant 去重,减少请求数。
15. 安全说明
API Key:只从
NVIDIA_API_KEY环境变量(或.env)读取;代码中没有任何硬编码 key;日志只记录 URL、序列长度、layer 名,不记录序列内容和 key;错误信息只包含响应前 500 字符摘要。序列隐私:所有日志/错误只含
preview(如ACGT...GCTA (len=12345))。路径沙箱:
FASTA 读取仅限
EVO2_MCP_ALLOWED_DIRS;未配置时拒绝一切本地路径;mode="save"的save_path必须位于EVO2_MCP_OUTPUT_DIR内;
.gitignore已包含.env、*.env、output/、*.npz。N 碱基:默认拒绝并明确报错(Evo2 模型未在含糊碱基上评测过,文档只保证 A/C/G/T 有意义)。如确需透传 N,用
EVO2_MCP_ALLOW_AMBIGUOUS=1启动 —— 这是显式选择,不是静默丢弃。Don't execute:本服务器不做任何 shell 执行;Agent 通过 FASTA/序列输入只能触发受限的 HTTP 请求。
16. 生物学解释限制
Evo2 score 是 model-based sequence likelihood change,不是实验证据,更不是临床致病性诊断。
delta_log_likelihood < 0只能解读为"突变体序列在模型下更不可能",不能解读为"致病"。需要 downstream 验证(实验、群体频率、ClinVar 注释、蛋白结构影响等)才能谈 pathogenicity。
每个 Tool 的 description 都带有以下声明(MCP 客户端可见):
This is a DNA foundation model inference tool. It does not provide clinical
diagnosis. Model scores should not be interpreted as pathogenicity labels
without additional validation.17. 实现依据与验证来源(2026-08-24)
NVIDIA NIM for Evo 2 — Endpoints:https://docs.nvidia.com/nim/bionemo/evo2/latest/endpoints.html
NVIDIA NIM for Evo 2 — Quickstart:https://docs.nvidia.com/nim/bionemo/evo2/latest/quickstart-guide.html
NVIDIA 托管 API 参考(arc/evo2-7b-forward OpenAPI schema):https://docs.api.nvidia.com/nim/reference/arc-evo2-7b-infer
托管端点实测(2026-08-24,真实 key):
output_layer返回 422StripedHyena has no attribute 'output_layer';unembed返回 logits(NPZ keyunembed.output,shape(1, seq, 512),float64)—— 因此评分工具默认EVO2_MCP_LOGITS_LAYER=auto自动探测批量实测(2026-08-25,真实 key,3800+ 条 K562 enhancer/promoter):
序列 > ~100 kb 时托管端返回 422(PyTorch
canUse32BitIndexMath限制)—— 批量跑用--skip-longer-than 100000;并发下 layer 名自动探测的竞态已修复(
forward_logits用局部变量记录尝试名)并加了回归测试;embedding 提取:
norm/embedding_layer/blocks.N均可用,shape(1, seq, 4096)float64(mean-pool 后 4096 维)。
Arc Institute Evo2 仓库(
scoring.py、models.py):https://github.com/ArcInstitute/evo2vortex
CharLevelTokenizer(Evo2 官方 tokenizer 实现):PyPIvtx1.1.0 源码vortex/model/tokenizer.py
若 NVIDIA 调整 API,请以官方最新文档为准;EVO2_MCP_BASE_URL 可随时切换。
18. 批量评分与 Embedding 提取(scripts/score_fasta.py)
MCP Tools 适合 Agent 交互式调用;大批量 FASTA 评分用配套脚本 scripts/score_fasta.py(真实 API 已用 3800+ 条 K562 enhancer/promoter 验证)。
每次运行自动创建一个带时间戳的独立文件夹:
output/run_20260825_104403/
├── scores.csv # 每序列一行:id, header, length, total/mean LL, ...
│ # + embedding_key(与 embeddings.npz 的 record_ids 对齐)
└── embeddings.npz # embeddings: (n, 4096) float32 mean-pooled 矩阵
# record_ids: 与矩阵行一一对应的键(来源__序列id)# 小样本(指定 id)
.pixi/envs/dev/bin/python scripts/score_fasta.py \
--fasta /path/cis/enhancers.fa /path/cis/promoters.fa \
--ids K562_TE_629,K562_MPT_6842 --allow-ambiguous
# 全量(跳过 >100kb —— 托管端对该长度返回 422;保留原始 embedding)
.pixi/envs/dev/bin/python scripts/score_fasta.py \
--fasta /path/cis/enhancers.fa /path/cis/promoters.fa \
/path/trans/enhancers.fa /path/trans/promoters.fa \
--skip-longer-than 100000 --allow-ambiguous \
--embedding-layer norm --keep-raw-embeddings关键参数:
参数 | 说明 |
| 提取哪个 layer 的 embedding(默认 |
| 额外保存每条原始逐位 embedding |
| 跳过超过该长度的序列(托管 API 限制,见 §17) |
| 允许 N 碱基透传(5 条含 N 的序列照常跑并带 caveat 警告) |
| 并发数(默认 2,尊重 rate limit) |
| 覆盖默认 run 文件夹布局 |
效率设计:每条序列只发一次请求(output_layers=["unembed","norm"],logits 与 embedding 同取);logits layer 名整次运行只探测一次;相同并发由信号量限制。
19. Embedding 关联与下游分析(scripts/analyze_run.py)
embeddings.npz 是 mean-pooled 的序列表示(每序列一个 4096 维向量),适合直接做聚类、分类、回归。加载与关联:
import csv, numpy as np
run = "output/run_20260825_104403"
rows = list(csv.DictReader(open(f"{run}/scores.csv")))
d = np.load(f"{run}/embeddings.npz", allow_pickle=True)
X = d["embeddings"] # (n, 4096) float32
ids = [str(x) for x in d["record_ids"]] # 与 X 行一一对应
key_to_row = {r["embedding_key"]: r for r in rows if r.get("embedding_key")}
scores = [key_to_row[k] for k in ids] # scores[i] ↔ X[i]一键跑完整分析(KMeans 聚类、enhancer-vs-promoter 分类、embedding→likelihood 回归、PCA 图):
.pixi/envs/dev/bin/python scripts/analyze_run.py output/run_20260825_104403 --k 3输出 analysis_<run>.npz(合并后的 X + keys)和 analysis_<run>.png。分析要点:
4096 维向量做相似度/聚类前先单位化(脚本已做);
小样本时分类/回归自动跳过(保护阈值 ≥6 条);全量 3806 条跑完后这些分析才有统计意义;
键
cis_enhancers__xxx→ 类别 enhancers、区域 cis;trans_*同理(parse_source可改标签维度做 cis-vs-trans 分类)。
开发与测试
pixi install # 或 pip install -e ".[dev]"
pixi run test # 运行 pytest(全部 mock,不调用真实 API)离线测试 91 passed / 4 skipped(skip = live 门控)。覆盖:序列校验、大小写/空白归一化、非法字符、缺 API key、forward 请求构造、401/408/429/5xx/timeout、layer 名自动探测(含并发竞态回归)、variant 校验、variant/batch 评分数学正确性(对照 Arc 语义独立复算)、NPZ 解码(JSON base64 / zip / 旧版 JSON tensor / <layer>.output key)、FASTA 沙箱、MCP session 集成、脚本纯函数(pooling/键名)等。
真实 API 冒烟测试(需要真实 key,默认跳过)。key 从 .env 自动读取(Settings.from_env() 已加载):
EVO2_MCP_RUN_LIVE=1 .pixi/envs/dev/bin/python -m pytest tests/test_live_api.py -v -slive 测试会真实请求 NVIDIA 端点,验证:logits layer 自动探测(unembed)、真实 NPZ 解析((1, seq, 512) float64)、evo2_score 与手工从原始 logits 复算一致、variant score。
项目结构
.
├── pyproject.toml
├── README.md
├── .env.example
├── .gitignore
├── src/evo2_mcp/
│ ├── __main__.py # python -m evo2_mcp 入口
│ ├── config.py # 环境变量配置
│ ├── sequence.py # DNA 校验/归一化
│ ├── api_client.py # HTTP 客户端(retry/backoff/错误分类/响应解码 + layer 自动探测)
│ ├── forward_output.py# NPZ 解码 + likelihood 计算 + embedding 提取
│ ├── fasta.py # FASTA 解析 + 读取沙箱
│ ├── tools.py # 5 个 Tool 的实现
│ └── server.py # MCP server(stdio)
├── scripts/
│ ├── score_fasta.py # 批量 FASTA 评分 + embedding 提取(每次运行独立 run 文件夹)
│ └── analyze_run.py # 下游分析:加载/关联 → 聚类/分类/回归 + PCA 图
├── tests/ # pytest(全 mock,91 用例)+ 可选 live test
└── output/ # mode="save" 的 .npz 输出 + run_*/ 运行结果(git 忽略)Available Tools
5 toolsevo2_batch_scoreA
Score many single-nucleotide variants against one wildtype sequence. The WT forward pass is computed exactly once and reused; identical (position, alt) mutants are forwarded once; mutant requests run with bounded concurrency (EVO2_MCP_MAX_CONCURRENCY, default 2) to respect NVIDIA rate limits, and per-variant API errors are reported per-variant. Use for saturation-mutagenesis-style analyses. This is a DNA foundation model inference tool. It does not provide clinical diagnosis. Model scores should not be interpreted as pathogenicity labels without additional validation.
| Name | Required | Description | Default |
|---|---|---|---|
| sequence | Yes | Wildtype DNA sequence (>= 2 bp). | |
| variants | Yes | List of {position, ref, alt} dicts (1-based positions). | |
| coordinate | No | 1-based |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure, and it excels. It reveals the caching behavior (WT pass computed once, identical mutants forwarded once), concurrency limits (EVO2_MCP_MAX_CONCURRENCY, default 2) to respect NVIDIA rate limits, and per-variant error reporting. It also adds crucial disclaimers (not clinical diagnosis, not pathogenicity labels). This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place. It leads with the core purpose, then efficiently packs performance details, error handling, and disclaimers. It is slightly longer than minimal but avoids fluff. The structure is logical: purpose → efficiency → safety/limitations. This is good, though a bit dense; a 4 feels right.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch scoring tool with no output schema, the description covers the execution semantics, concurrency, error reporting, and clinical disclaimer. However, it omits any description of the return format or how results are structured (even per-variant errors are mentioned but not the shape). Given the complexity and no annotations, the absence of output details leaves a small but notable gap, so it stops short of a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (sequence and variants have descriptions; coordinate has an enum with a default). The description does not add parameter-level meaning beyond what the schema already provides—it merely restates the variants structure and coordinate default implicitly. It does clarify the 'many' scope, but that is more behavioral than parameter-specific. Baseline 3 is appropriate since the schema covers most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a strong, specific verb-resource pair: 'Score many single-nucleotide variants against one wildtype sequence.' It clearly states the batch scope and distinguishes itself from single-variant tools by emphasizing 'many' and 'batch.' It also specifies the analysis type (saturation-mutagenesis), which orients the agent on the intended use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool provides a clear when-to-use directive: 'Use for saturation-mutagenesis-style analyses.' It also implies batching by explaining the reuse of the WT forward pass and bounded concurrency. However, it does not explicitly name alternative sibling tools for single-variant scoring, so the agent must infer those from the 'many' qualifier. This is solid but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evo2_forwardA
Run a forward pass of Evo2-7B on a DNA sequence (forward inference) and return summary statistics — or raw tensors — for the requested model layers (final logits, attention, MLP or embedding outputs). Use this when you need layer outputs for analysis, not just a scalar score. Modes: 'summary' (shape/dtype/min/max/mean/std per layer — default, context-safe), 'save' (write the .npz under the server's output dir and return the path), 'raw' (inline small tensors only; large tensors must be saved to a file instead). This is a DNA foundation model inference tool. It does not provide clinical diagnosis. Model scores should not be interpreted as pathogenicity labels without additional validation.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | summary: per-layer shape/dtype/min/max/mean/std only. raw: inline the tensors as nested lists (small only, capped). save: always write an .npz file in the output dir and return its path. | summary |
| sequence | Yes | DNA sequence over {A,C,G,T}. Lowercase and whitespace are normalised. IUPAC ambiguity codes (N, R, Y, ...) are rejected unless the server was started with EVO2_MCP_ALLOW_AMBIGUOUS=1 (N only). | |
| save_path | No | Optional filename for the saved NPZ (implies mode='save'). Must resolve inside the server's output directory (EVO2_MCP_OUTPUT_DIR, default ./output). If omitted, a timestamped file is used. | |
| output_layers | No | Evo2 layer names. The final logits layer is 'output_layer' on self-hosted NIM 2.x containers, but the hosted health.api.nvidia.com endpoint uses model attribute names — use 'unembed' for final logits (also 'embedding_layer', 'norm', 'blocks.N.mlp'). Scoring tools auto-detect this. See https://docs.nvidia.com/nim/bionemo/evo2/latest/endpoints.html |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility. It discloses mode behavior (summary is context-safe, raw only for small tensors, save writes to server output dir), ambiguity-code handling with an environment flag, endpoint-dependent layer naming, and the clinical limitation. This is exceptionally transparent for a complex inference tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, then organizes modes and constraints in a logical flow. Every sentence provides distinct information—no filler. Dense but efficient, appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, no output schema, and no annotations, this description is remarkably complete. It covers return types, mode constraints, output directory rules, ambiguity handling, endpoint differences, and disclaimers—everything an agent needs to invoke it correctly without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover all parameters (100% coverage), but the description adds significant value: it explains the endpoint-specific layer names (output_layer vs unembed), the save_mode implication of save_path, and the ambiguity environment flag. This goes beyond the schema to make parameter usage clearer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Run a forward pass of Evo2-7B') and explicitly contrasts with scoring tools: 'Use this when you need layer outputs for analysis, not just a scalar score.' This clearly distinguishes from sibling scoring tools and conveys the tool's core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool versus alternatives ('not just a scalar score'), and details the three modes with their intended contexts. It also adds a clinical disclaimer ('does not provide clinical diagnosis'), guiding appropriate usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evo2_scoreA
Compute the model-based log-likelihood of a DNA sequence under Evo2-7B (nucleotide-level log-likelihood via the byte-level tokenizer). Returns total_log_likelihood, mean_log_likelihood, scored_positions and optionally per_position_log_likelihood (position 0 is unscored by the causal shift; value k corresponds to 0-based position k+1). Use for sequence-level probability estimates. This is a DNA foundation model inference tool. It does not provide clinical diagnosis. Model scores should not be interpreted as pathogenicity labels without additional validation.
| Name | Required | Description | Default |
|---|---|---|---|
| sequence | Yes | DNA sequence over {A,C,G,T} (>= 2 bp). | |
| include_per_position | No | Return the per-position log-likelihood list (default False to keep the response small; long lists are truncated to head+tail). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses output structure, the causal shift causing position 0 to be unscored, optional per-position output, and explicitly warns against clinical diagnosis and pathogenicity interpretation. This is thorough and transparent for a model-scoring tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a few sentences but each adds necessary context: purpose, output details, usage, and disclaimers. It is not overly verbose and front-loads the core function. Slightly dense with parentheticals, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description fully explains the returned fields (total_log_likelihood, mean_log_likelihood, scored_positions, optional per_position_log_likelihood) and the positional convention. It also addresses interpretation caveats. For a single-sequence inference tool, nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are well-documented in the schema. The description adds little beyond the schema; it does explain the per-position output semantics within the overall description, but that is not parameter-specific. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes model-based log-likelihood of a DNA sequence under Evo2-7B, with specific output fields. It does not explicitly differentiate from siblings like evo2_batch_score or evo2_variant_score, but the single-sequence focus is implied by the parameter list and usage text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear context: 'Use for sequence-level probability estimates' and notes this is a DNA foundation model inference tool. It does not explicitly state when not to use it or mention alternatives, but the use case is specified clearly enough without being misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evo2_score_fastaA
Score every record in a FASTA source under Evo2-7B. Provide EITHER fasta_text (inline FASTA) OR fasta_path (local file — only allowed when its directory is listed in EVO2_MCP_ALLOWED_DIRS; the server refuses arbitrary paths). Returns per-record total/mean log-likelihood; per-record errors are reported inline. This is a DNA foundation model inference tool. It does not provide clinical diagnosis. Model scores should not be interpreted as pathogenicity labels without additional validation.
| Name | Required | Description | Default |
|---|---|---|---|
| fasta_path | No | Local FASTA path (sandboxed by EVO2_MCP_ALLOWED_DIRS). | |
| fasta_text | No | Inline FASTA text, e.g. '>seq1\nACGT...'. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full disclosure burden. It states the output type (per-record total/mean log-likelihood), error reporting behavior, and importantly warns that scores are not clinical diagnostics. It does not explicitly state read-only behavior, but for an inference tool this is implied and not a significant gap given the safety disclaimers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet covers all essential aspects: purpose, input options, constraints, output, and limitations. The main action is front-loaded, and every sentence serves a purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description explains the return values clearly. It covers input constraints and error reporting, but does not specify the exact response format (e.g., whether it's a JSON object or text). For a tool with only two parameters, this is a minor gap, so a 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter comments, so the baseline is 3. The description adds value by clarifying the meaning of the output (per-record scores) which is not in the schema, and reinforces the sandboxing constraint for fasta_path, going beyond the schema's own description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Score every record'), the specific resource (FASTA source), and the model (Evo2-7B). It also distinguishes itself from siblings by focusing on FASTA input, making it easily separable from evo2_score or evo2_variant_score without needing to infer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use the tool: 'Provide EITHER fasta_text OR fasta_path', with the path restriction clearly stated. It also provides cautionary guidance on interpreting results, which helps agents avoid misuse. The description mentions no alternatives but the either/or and sandboxing rules effectively guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evo2_variant_scoreA
Compare a single-nucleotide variant: the Evo2-7B log-likelihood of the wildtype sequence vs the mutant sequence. Returns delta_log_likelihood (mutant − wildtype); a negative value means the mutant sequence is LESS likely under the model. Positions are 1-based by default (VCF-style). Variants at position 1 are rejected because a causal LM cannot score the first base. This is a DNA foundation model inference tool. It does not provide clinical diagnosis. Model scores should not be interpreted as pathogenicity labels without additional validation.
| Name | Required | Description | Default |
|---|---|---|---|
| alt | Yes | Alternate allele (single A/C/G/T). | |
| ref | Yes | Reference allele (single A/C/G/T). | |
| position | Yes | Variant position, 1-based by default. | |
| sequence | Yes | Wildtype DNA sequence context (>= 2 bp). | |
| coordinate | No | Coordinate system of `position`. | 1-based |
| include_per_position | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it explains the output meaning (negative delta indicates lower likelihood), the reasoning behind rejecting position 1 (causal LM limitation), coordinate system default, and important limitations (not clinical, not pathogenicity). This goes well beyond a basic verb+object statement and gives the agent a clear model of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences with no redundancy. It front-loads the core purpose and output interpretation, then adds constraints and domain caveats. Every sentence carries meaningful information, and the structure makes it easy for an agent to quickly grasp the tool's role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema or annotations, the description covers the essential aspects: what it computes, how to interpret the result, coordinate system, positional restriction, and domain limitations. It does not explicitly describe the effect of include_per_position (though schema notes default false), but that is a minor gap. Overall, an agent has sufficient context to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (83%), so the baseline is 3. The description adds semantic value by explaining the output delta and the coordinate system, but it does not elaborate on parameters that the schema already documents. It reinforces the 'sequence' as wildtype context, which is consistent with schema descriptions, but adds no new parameter-level nuance beyond the position-1 rejection rule.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Compare a single-nucleotide variant') and defines the exact output ('delta_log_likelihood (mutant − wildtype)'). It clearly distinguishes the tool from siblings by focusing on variant comparison rather than generic scoring or batch operations. The inclusion of the model name (Evo2-7B) and the caveat about clinical diagnosis further clarify its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (for single-nucleotide variant scoring) but does not explicitly compare with siblings like evo2_score or evo2_batch_score. It does provide usage constraints (1-based positions, rejection of position 1, not for clinical diagnosis) that help an agent decide applicability, yet it lacks an explicit 'use when' versus 'use instead' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
5 tool updates
v0.1.0- First observed
evo2_batch_score - First observed
evo2_forward - First observed
evo2_score - First observed
evo2_score_fasta - First observed
evo2_variant_score
TDQS
Scored across 5 tools
Each tool has a clearly distinct purpose: forward pass for layer tensors, sequence log-likelihood scoring, single variant effect, batch variant scoring, and FASTA-based scoring. The descriptions clearly delineate usage scenarios, reducing misselection risk.
All tools follow the evo2_ verb-noun pattern (forward, score, variant_score, batch_score, score_fasta). While the second part varies, the consistent prefix and action-oriented naming make the set predictable and easy to navigate.
Five tools is well-scoped for a focused DNA model inference server. Each tool adds a distinct capability without redundancy, covering single sequence, variant, batch, and file-based scoring.
The surface covers the core workflows for an Evo2 model: sequence scoring, variant effect analysis (single and batch), FASTA batch processing, and forward pass tensor extraction. No obvious dead ends or missing critical operations for the stated purpose.
Related MCP Connectors
Protein analysis: ESM-2/ESMC embeddings, mutation scoring, landscape scans, ESMFold structure.
Hosted DNA language models: promoter, splice, enhancer, chromatin, expression, annotation
AI-powered bioprotocol optimization — generate, search, and manage lab protocols via MCP
Free OpenAI-compatible inference with signed provenance receipts and 3 focused MCP tools.
Related MCP Servers
- AlicenseAqualityCmaintenanceEnables genomic sequence analysis through the Evo 2 model, supporting DNA sequence scoring, embedding, generation, and variant effect prediction with multiple model checkpoints (7B, 40B, 1B parameters).63LGPL 3.0

bio-mcp-evo2official
AlicenseNot gradedqualityDmaintenanceAn MCP server that enables AI assistants to generate, score, and analyze DNA sequences using the evo2 genomic foundation model. It supports multiple execution modes including local GPU, SLURM clusters, and the Nvidia NIM cloud API for tasks like variant effect prediction and sequence embedding.1MIT- FlicenseNot gradedqualityDmaintenanceEnables protein sequence analysis and structure prediction by extracting ESM-2 embeddings and batch processing FASTA files via Docker. It provides tools for large-scale embedding extraction, job monitoring, and model management within an MCP-compatible environment.-
- AlicenseNot gradedqualityDmaintenanceEnables AI agents to query clinical genomics databases, retrieve supporting literature, analyze population genetics, and visualize biological pathways.18MIT