Capability registry
A machine readable registry records server identity, lifecycle state, installation requirements, transport, commands and exposed MCP tools.
Scientific infrastructureMCP frameworkSoftware interoperability
BioMCP | Scientific Software Interoperability Framework
A protocol driven software layer for exposing scientific applications, computational tools, model runtimes and data resources through consistent Model Context Protocol interfaces.
What
What is BioMCP?
Scientific software exposes highly heterogeneous interfaces. Some applications provide command line programs, some require local graphical runtimes, some expose network services, and others operate as independent MCP servers. BioMCP defines a common integration layer across these execution models.
Runtime interface
The runtime resolves registered capabilities and provides a consistent path from an MCP request to the corresponding scientific backend.
Adapter boundary
Adapters translate protocol level requests into the native invocation mechanism of each scientific application without replacing its computational engine.
Why
Why is an interoperability layer required?
Scientific applications differ in installation procedure, invocation syntax, transport, data representation, dependency management and output format. Direct integration of every client with every scientific package produces duplicated interface code and inconsistent execution behavior. BioMCP introduces a common protocol boundary so clients can discover and invoke scientific capabilities through one interface while computation remains inside the original scientific software.
Design principle
Protocol handling and scientific computation are separate responsibilities. BioMCP owns discovery, interface validation, routing, configuration and execution controls. The connected scientific application owns domain algorithms, measurements, model inference and scientific artifacts.
How
Technical execution flow
Each operation follows an explicit request path from capability discovery to backend execution and structured return.
01 · Discovery
The client queries available MCP tools and their declared schemas.
02 · Resolution
The registry resolves the selected integration, command, transport and capability metadata.
03 · Validation
The runtime validates typed inputs and applies configuration, resource and execution constraints.
04 · Execution
The adapter invokes the scientific application, executable, model endpoint or external MCP server.
05 · Return
The adapter normalizes the response into structured MCP output with execution metadata and provenance where supported.
BioMCP system architecture. The figure represents the integration model. Components are assigned implementation states only after corresponding code and validation evidence exist.
Implementation
Core platform components
Registry and discovery
Versioned metadata describes integration status, package extras, server commands, supported transports and tool capabilities.
CLI and configuration
The command interface provides installation, listing, execution, diagnostics and client configuration workflows through install, list, run, doctor and configuration operations.
Protocol validation
Validation exercises real MCP client and server communication and installed package artifacts so interface behavior is tested at the protocol boundary.
Model runtime
LLM Gateway
The experimental LLM component provides the initial interface between BioMCP and compatible language model endpoints. The architectural target is a provider abstraction that exposes model capabilities through a controlled runtime boundary.
Provider interface
The target provider layer covers OpenAI compatible endpoints, Ollama, vLLM and compatible local or remote runtimes.
Request interface
Planned protocol capabilities include model discovery, streaming, structured output, JSON schema, tool calling and provider capability metadata.
Execution controls
The target runtime includes timeout policy, retry policy, response limits, credential isolation, sanitized errors, context handling, MCP tool execution controls and provenance metadata.
The current repository contains the initial model bridge. Broader gateway capabilities remain development targets until implemented and validated.
Scientific boundary
Interoperability does not replace the scientific engine.
BioNuclei remains responsible for its models, measurements, evaluation procedures, artifacts and provenance. BioMCP provides the protocol and integration boundary around that system. The scientific implementation remains external to BioMCP.
Results
Current implementation results
The current repository provides executable MCP integrations and package level infrastructure while maintaining explicit lifecycle states for components that are not yet fully validated.
| Component | Implemented function | Current result |
|---|---|---|
| BioImage | Image inspection, intensity summaries and thresholding primitives exposed through MCP. | Experimental and installable |
| ImageJ / Fiji | Controlled invocation of an explicitly configured local ImageJ or Fiji runtime. | Experimental and installable |
| LLM Gateway | Initial OpenAI compatible model endpoint bridge. | Experimental and installable |
| BioNuclei | Independent scientific MCP server connected as an external integration. | Validated and external |
| PyMOL | Molecular visualization and structural biology integration. | Planned for v0.3 |
| CellProfiler | Bioimage analysis pipeline integration. | Planned for v0.3 |
| BLAST+ | Local sequence similarity analysis integration. | Planned for v0.3 |
Experimental indicates executable implementation without completion of every validation gate. Validated indicates documented evidence supporting the integration state. Planned indicates roadmap scope only.
Verification
Engineering evidence
BioMCP validation is designed to test the installed system rather than only source modules. Current package validation covers MCP communication through installed artifacts and exercises the BioImage, ImageJ and LLM server families. Security work also isolates the ImageJ child process environment from credential and execution control variables.
MCP interoperability
Client sessions exercise actual MCP communication with installable server implementations.
Package artifacts
Wheel and source distribution artifacts are built, installed outside the source tree and exercised as consumer installations.
Execution isolation
External process integration uses controlled environment propagation so host credentials and execution control variables are not broadly inherited.
Usage
Local command interface
pip install biomcp biomcp list biomcp doctor # Run an available server biomcp run bioimage # Generate generic MCP client configuration biomcp install --servers bioimage --clients generic # Inspect configuration without writing files biomcp install --servers bioimage --clients generic --dry-run
Command syntax is shown exactly as required by the interface. ImageJ and Fiji require an explicitly configured local executable. The current LLM bridge uses environment supplied endpoint and credential configuration.
Roadmap
Extension through validated scientific adapters
The next planned integrations are PyMOL, CellProfiler and BLAST+. Additional adapters are added only when the scientific use case, invocation boundary, dependency model, security constraints, tests and reproducibility requirements can be specified.
PyMOL
Molecular visualization and structural biology workflows. Planned.
CellProfiler
Reproducible bioimage analysis pipelines. Planned.
BLAST+
Local sequence similarity analysis. Planned.
Development
Scientific software integration with explicit validation.
Contributions can address adapters, MCP interfaces, packaging, protocol tests, security controls, reproducibility infrastructure and technical documentation. BioMCP is maintained as an independent interoperability project.
BioMCP repository →