Skip to main content
Glama
enesjakozh
acashmoney

BioMCP

by acashmoney
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

BioMCP：基于代理的生物医学研发

铁匠徽章生物MCP

概述

BioMCP 是一个模型上下文协议(MCP)服务器，旨在增强大型语言模型的蛋白质结构分析能力。它通过与现有的蛋白质数据库对接，提供分析蛋白质活性位点和搜索疾病相关蛋白质的工具。

未来的工作将围绕使代理商能够利用 BioMCP 展开。

Related MCP server: PubMed MCP Server

特征

  • 活性位点分析：使用 PDB ID 检查蛋白质的结合位点和功能残基

  • 疾病蛋白质搜索：查找与特定疾病或医疗状况相关的蛋白质结构

  • 集成数据访问：与 RCSB 蛋白质数据库(PDB)无缝连接

技术细节

BioMCP 实现了模型上下文协议 (MCP)，允许语言模型访问专门的蛋白质结构知识，而无需将这些信息作为训练数据的一部分。该服务器负责处理 API 连接、数据格式化和错误处理，以提供可靠的蛋白质结构洞察。

API 端点

BioMCP 提供两种主要工具：

  1. analyze-active-site ：使用 PDB ID 提供有关蛋白质结合位点的详细信息

  2. search-disease-proteins ：返回与特定疾病或医疗状况相关的蛋白质

入门

通过 Smithery 安装

要通过Smithery自动为 Claude Desktop 安装 BioMCP：

npx -y @smithery/cli install @acashmoney/bio-mcp --client claude

手动安装

# Clone the repository
git clone https://github.com/acashmoney/bio-mcp.git

# Install dependencies
npm install

# Start the server
npm start

设置说明

运行 MCP 检查器

  1. 启动 BioMCP 服务器：

    npm start

  2. 在单独的终端中，全局安装 MCP Inspector（如果尚未安装）：

    npm install -g @anthropic-ai/mcp-inspector

  3. 启动 MCP Inspector 并连接到本地 BioMCP 服务器：

    npx @modelcontextprotocol/inspector node build/index.js

  4. 使用检查器界面测试工具并查看响应。

与 Claude Desktop 一起使用

  1. 构建 BioMCP 服务器：

    npm run build

  2. 配置 Claude Desktop 以启动 MCP 服务器：

    a. 找到你的 Claude Desktop config.json 文件（通常在你的用户目录中）

    b. 编辑 config.json 文件，添加 BioMCP 服务器构建路径。示例配置：

    {
  "globalShortcut": "",
  "mcpServers": {
    "bio-mcp": {
      "command": "node",
      "args": [
        "/path/to/your/build/index.js"
      ]
    }
  }
}

    c. 将/path/to/your/build替换为项目目录的实际路径。

  3. 重新启动 Claude Desktop 以使更改生效。

  4. 您现在可以向 Claude 询问使用 BioMCP 工具的问题：

    • “PDB 结构 6LU7 的活性位点中的关键残基是什么？”

    • “寻找与阿尔茨海默病相关的蛋白质”

示例用法

当与兼容的语言模型集成时，Bio-MCP 支持以下查询：

  • “PDB 结构 6LU7 的活性位点中的关键残基是什么？”

  • “寻找与阿尔茨海默病相关的蛋白质”

要求

  • Node.js 20.0.0 或更高版本

  • TypeScript 5.0+

  • 兼容 MCP 客户端实现

测试

BioMCP 包括一个全面的测试套件，其中包含单元、集成和端到端测试。

运行测试

运行所有测试：

npm test

运行特定的测试套件：

# Unit tests only
npm run test:unit

# Integration tests only (API interactions)
npm run test:integration

# End-to-end tests only
npm run test:e2e

代码检查

检查代码质量：

npm run lint

自动修复 linting 问题：

npm run lint:fix

路线图

  • 扩展活动站点描述的详细程度

  • 利用三维坐标

  • 与文献交互的工具

  • 与计算生物学模型接口的工具：

    • 射频扩散

    • 蛋白质MPNN

    • ColabFold

    • 额外的蛋白质设计和结构预测工具

  • 基于代理的研究流程

  • 向客户介绍蛋白质可视化工具

Available Tools

2 tools
analyze-active-siteC

Analyze the active site of a protein structure

ParametersJSON Schema
NameRequiredDescriptionDefault
pdbIdYesThe PDB ID of the protein structure to analyze (e.g., 6LU7)

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states the action without disclosing behavioral traits. It doesn't mention computational requirements, output format, error conditions, or whether the analysis is read-only or has side effects, leaving significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and front-loaded with the core purpose, making it easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description is incomplete for a tool that performs analysis. It doesn't explain what the analysis entails, what results to expect, or any behavioral context, which is inadequate for guiding an AI agent effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the single parameter 'pdbId'. The description adds no additional meaning beyond what the schema provides, such as examples of analysis outputs or constraints on PDB IDs, meeting the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('analyze') and target resource ('active site of a protein structure'), making the purpose understandable. However, it doesn't differentiate from the sibling tool 'search-disease-proteins' or specify what aspects of the active site are analyzed, preventing a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus the sibling 'search-disease-proteins' or other alternatives. The description implies usage for protein structure analysis but lacks explicit context, prerequisites, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search-disease-proteinsC

Search for proteins related to a disease

ParametersJSON Schema
NameRequiredDescriptionDefault
diseaseYesDisease name (e.g., 'covid', 'alzheimer's')

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does ('Search for proteins') without describing how it behaves—no information about response format, pagination, error handling, rate limits, authentication requirements, or whether it's a read-only or mutating operation. This leaves significant gaps in understanding 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise—a single sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core functionality, making it efficient and easy to parse, though this conciseness comes at the cost of completeness in other dimensions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what the search returns (e.g., protein names, IDs, relevance scores), how results are structured, or any behavioral aspects. For a search tool with no structured output documentation, the description should provide more context about the expected results and operational characteristics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, with the single parameter 'disease' fully documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema (e.g., it doesn't elaborate on search algorithms, result filtering, or disease name formatting). This meets the baseline expectation when schema coverage is complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Search') and resource ('proteins related to a disease'), making it immediately understandable. However, it doesn't explicitly differentiate from the sibling tool 'analyze-active-site', which appears to be a different type of analysis tool rather than a direct alternative for searching.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool 'analyze-active-site' or any other potential tools, nor does it specify prerequisites, constraints, or typical use cases beyond the basic purpose.

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.

  1. 2 tool updatesv1.0.0
    • Addedanalyze-active-site
    • Addedsearch-disease-proteins
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one analyzes protein structures (active sites), while the other searches for disease-related proteins. There is no overlap in functionality, making it easy for an agent to choose the correct tool based on the task.

Naming Consistency4/5

Both tools use a consistent verb-noun pattern with hyphens (e.g., analyze-active-site, search-disease-proteins). This naming scheme is readable and predictable, though with only two tools, it's hard to assess full consistency across a larger set.

Tool Count2/5

With only two tools, the server feels thin for a bioinformatics domain, which typically involves more operations like sequence alignment, structure prediction, or data retrieval. This limited set may not cover common workflows adequately.

Completeness2/5

The tool surface is severely incomplete for a bioinformatics server. It lacks basic operations such as fetching protein sequences, aligning sequences, predicting structures, or managing datasets. This will likely cause agent failures in handling typical tasks in this domain.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • PubMed MCP Server

    chrismannina
    A
    license
    B
    quality
    D
    maintenance
    A comprehensive Model Context Protocol server that enables advanced PubMed literature search, citation formatting, and research analysis through natural language interactions.
    12
    10
    MIT

  • STRING-MCP

    MCPmed
    A
    license
    B
    quality
    D
    maintenance
    A Model Context Protocol server that provides tools for interacting with the STRING database to analyze protein-protein interaction networks and functional enrichment. It enables users to map protein identifiers, retrieve interaction data, and generate biological network visualizations through natural language interfaces.
    11
    4
    BSD 3-Clause

Appeared in Searches