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

概要
BioMCPは、大規模言語モデルにタンパク質構造解析機能を追加するために設計されたモデルコンテキストプロトコル(MCP)サーバーです。既存のタンパク質データベースとのインターフェースを通じて、タンパク質活性部位の解析や疾患関連タンパク質の検索のためのツールを提供します。
今後の作業は、エージェントが BioMCP を利用できるようにすることを中心に行われます。
Related MCP server: PubMed MCP Server
特徴
活性部位解析:PDB IDを使用してタンパク質の結合部位と機能残基を調べる
疾患タンパク質検索:特定の疾患や病状に関連するタンパク質構造を検索します
統合データアクセス:RCSBタンパク質データバンク(PDB)とシームレスに接続
技術的な詳細
BioMCPはモデルコンテキストプロトコルを実装しており、言語モデルが専門的なタンパク質構造知識にアクセスする際に、この情報をトレーニングデータに組み込む必要はありません。サーバーはAPI接続、データフォーマット、エラー処理を行い、信頼性の高いタンパク質構造情報を提供します。
APIエンドポイント
BioMCP は 2 つの主要なツールを公開します。
analyze-active-site: PDB IDを使用してタンパク質結合部位の詳細情報を提供します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インスペクターの実行
BioMCP サーバーを起動します。
npm start別のターミナルで、MCP Inspector をグローバルにインストールします (まだインストールされていない場合)。
npm install -g @anthropic-ai/mcp-inspectorMCP Inspector を起動し、ローカルの BioMCP サーバーに接続します。
npx @modelcontextprotocol/inspector node build/index.jsインスペクター インターフェースを使用してツールをテストし、応答を表示します。
Claude Desktopでの使用
BioMCP サーバーを構築します。
npm run buildMCP サーバーを起動するように 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プロジェクト ディレクトリへの実際のパスに置き換えます。変更を有効にするには、Claude Desktop を再起動してください。
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 toolsanalyze-active-siteC
Analyze the active site of a protein structure
| Name | Required | Description | Default |
|---|---|---|---|
| pdbId | Yes | The PDB ID of the protein structure to analyze (e.g., 6LU7) |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| disease | Yes | Disease name (e.g., 'covid', 'alzheimer's') |
TDQS
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.
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.
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.
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.
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.
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.
2 tool updates
v1.0.0- Added
analyze-active-site - Added
search-disease-proteins
TDQS
Scored across 2 tools
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.
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.
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.
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
Related MCP Connectors
Agent-to-Agent (A2A) + Model Context Protocol (MCP) hub for peptides.
Protein analysis: ESM-2/ESMC embeddings, mutation scoring, landscape scans, ESMFold structure.
AI-powered bioprotocol optimization — generate, search, and manage lab protocols via MCP
A Model Context Protocol server for Wix AI tools
Related MCP Servers
- FlicenseBqualityDmaintenanceA comprehensive Model Context Protocol (MCP) server that provides access to the AlphaFold Protein Structure Database through a rich set of tools and resources for protein structure prediction analysis.1935-
- AlicenseBqualityDmaintenanceA comprehensive Model Context Protocol server that enables advanced PubMed literature search, citation formatting, and research analysis through natural language interactions.1210MIT
- AlicenseBqualityDmaintenanceA 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.114BSD 3-Clause
- FlicenseNot gradedqualityDmaintenanceModel Context Protocol server for protein binder design using BindCraft via Docker, enabling structure prediction, sequence optimization, and scoring.2-