Skip to main content
Glama

BioMCP: エージェントベースのバイオメディカル研究開発を実現

鍛冶屋のバッジバイオMCP

概要

BioMCPは、大規模言語モデルにタンパク質構造解析機能を追加するために設計されたモデルコンテキストプロトコル(MCP)サーバーです。既存のタンパク質データベースとのインターフェースを通じて、タンパク質活性部位の解析や疾患関連タンパク質の検索のためのツールを提供します。

今後の作業は、エージェントが BioMCP を利用できるようにすることを中心に行われます。

Related MCP server: PubMed MCP Server

特徴

  • 活性部位解析:PDB IDを使用してタンパク質の結合部位と機能残基を調べる

  • 疾患タンパク質検索:特定の疾患や病状に関連するタンパク質構造を検索します

  • 統合データアクセス:RCSBタンパク質データバンク(PDB)とシームレスに接続

技術的な詳細

BioMCPはモデルコンテキストプロトコルを実装しており、言語モデルが専門的なタンパク質構造知識にアクセスする際に、この情報をトレーニングデータに組み込む必要はありません。サーバーはAPI接続、データフォーマット、エラー処理を行い、信頼性の高いタンパク質構造情報を提供します。

APIエンドポイント

BioMCP は 2 つの主要なツールを公開します。

  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. MCP サーバーを起動するように Claude Desktop を構成します。

    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. BioMCP ツールを活用した質問を Claude に尋ねることができるようになりました。

    • 「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

リンティングの問題を自動的に修正します。

npm run lint:fix

ロードマップ

  • アクティブサイトの説明の詳細レベルを拡張する

  • 3D座標を活用する

  • 文学とのインターフェースツール

  • 計算生物学モデルとのインターフェースツール:

    • RF拡散

    • タンパク質MPNN

    • コラブフォールド

    • 追加のタンパク質設計および構造予測ツール

  • エージェントベースの研究パイプライン

  • タンパク質可視化ツールをクライアントに紹介する

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

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

Related MCP Connectors

Related MCP Servers

  • 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
  • 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