BioMCP
BioMCP: 에이전트 기반 생물의학 R&D 활성화

개요
BioMCP는 단백질 구조 분석 기능을 통해 대규모 언어 모델을 강화하도록 설계된 모델 컨텍스트 프로토콜 (MCP) 서버입니다. 기존 단백질 데이터베이스와의 연동을 통해 단백질 활성 부위를 분석하고 질병 관련 단백질을 검색하는 도구를 제공합니다.
향후 작업은 에이전트가 BioMCP를 활용할 수 있도록 하는 데 중점을 둘 것입니다.
Related MCP server: PubMed MCP Server
특징
활성 부위 분석 : PDB ID를 사용하여 단백질의 결합 부위와 기능적 잔류물을 조사합니다.
질병-단백질 검색 : 특정 질병이나 건강 상태와 관련된 단백질 구조를 찾습니다.
통합 데이터 액세스 : RCSB 단백질 데이터 뱅크 (PDB) 와 원활하게 연결
기술적 세부 사항
BioMCP는 모델 컨텍스트 프로토콜(Model Context Protocol)을 구현하여 언어 모델이 특정 단백질 구조 지식에 접근할 수 있도록 합니다. 이 정보는 학습 데이터에 포함되지 않아도 됩니다. 서버는 API 연결, 데이터 형식 지정 및 오류 처리를 통해 신뢰할 수 있는 단백질 구조 정보를 제공합니다.
API 엔드포인트
BioMCP는 두 가지 주요 도구를 제공합니다.
analyze-active-site: PDB ID를 사용하여 단백질 결합 부위에 대한 자세한 정보를 제공합니다.search-disease-proteins: 지정된 질병이나 건강 상태와 관련된 단백질을 반환합니다.
시작하기
Smithery를 통해 설치
Smithery를 통해 Claude Desktop용 BioMCP를 자동으로 설치하는 방법:
지엑스피1
수동 설치
# 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. BioMCP 서버 빌드 경로를 포함하도록 config.json 파일을 편집합니다. 구성 예시:
{ "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 이상
타입스크립트 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-