BioinfoMCP Converter: Automated Bioinformatics Wrapping

• BioinfoMCP Converter is an automated system that transforms standalone command-line bioinformatics tools into MCP-compliant servers using LLMs and Docker.
• It standardizes tool invocation by processing documentation through a three-stage workflow—Preparation, Execution, and Delivery—to generate structured, AI-callable wrappers.
• Empirical benchmarks show a 94.7% success rate across 38 tools, while dependency on documentation quality and incomplete automation highlight areas for improvement.

Searching arXiv for the named systems and closely related MCP bioinformatics work. BioinfoMCP Converter is the conversion component of BioinfoMCP, a two-part platform in which existing bioinformatics tools are automatically converted into MCP-compliant servers from tool documentation using LLMs, while BioinfoMCP Benchmark evaluates the resulting servers individually and in end-to-end workflows (Widjaja et al., 2 Oct 2025). Its stated target is the long-standing mismatch between bioinformatics software and AI-agent frameworks: many tools remain standalone command-line programs for human users, with heterogeneous input-output formats, inconsistent argument naming and defaults, and diverse execution requirements. In the broader MCP transition in bioinformatics, BioinfoMCP Converter occupies a distinct niche from web-service-oriented efforts such as MCPmed, which adapts MCP to bioinformatics web server backends and proposes “breadcrumbs” for services not yet fully MCP-enabled (Flotho et al., 10 Jul 2025).

1. Definition, scope, and problem setting

BioinfoMCP is organized into two components: BioinfoMCP Converter, which generates MCP servers, and BioinfoMCP Benchmark, which validates them across individual tools and multi-step analyses. The Converter is designed for existing bioinformatics software that was built as a standalone command-line interface rather than as a machine-readable service. Its stated purpose is to remove the “manual conversion bottleneck” involved in reading tool documentation, understanding command syntax, and writing MCP wrappers by hand (Widjaja et al., 2 Oct 2025).

The scope of the Converter is therefore narrower and more concrete than a general scientific workflow system. It standardizes tool invocation for AI agents, rather than redesigning the scientific algorithms of the wrapped tools. This is why the platform is described around incompatible interfaces, heterogeneous input-output formats, inconsistent parameter conventions, and execution environments, rather than around new domain-specific models or statistical estimators. A related clarification is terminological: in BioinfoMCP, “MCP” refers to the Model Context Protocol, not to unrelated uses of the same acronym in computational biology, such as the “Multi-Component learning machine to Predict protein secondary structure” (Khalatbari et al., 2018).

2. Conversion pipeline and algorithmic workflow

The Converter is described as a three-stage workflow: Preparation, Execution, and Delivery. The formal input signature given in the paper is: tool name $T$, help manual path $M$, help manual flag $h \in \{0,1\}$, output directory $O$, LLM model $\mathcal{M}$, and API key $\mathcal{K}$. The output is a Dockerised MCP server ready for an AI Agent (Widjaja et al., 2 Oct 2025).

Documentation acquisition currently supports two modes. In the first, official documentation is supplied as a PDF and converted through:

$\mathcal{D} \gets \mathrm{pdf2text}(M)$

In the second, documentation is extracted directly from the executable through a help flag, represented in the paper as:

$$\mathcal{D} \gets \mathrm{subprocess}([T,\,--help])$$

The extracted documentation text $\mathcal{D}$ is then used to construct the prompt:

$$\mathcal{P} \gets \mathrm{generate\_prompt}(T,\mathcal{D})$$

The pseudocode describes an iterative repair loop. Candidate MCP server code is generated, parsed, and checked for failure conditions including no code detected and syntax error. If parsing fails, error-conditioned refinement is triggered through:

$M$0

and

$M$1

The loop repeats until syntax is valid. The generated server code is written to O/app/T_server.py, after which the system generates a Dockerfile and docker-compose.yml for delivery (Widjaja et al., 2 Oct 2025).

The paper does not describe a hand-built parser that first converts manuals into a published intermediate ontology or argument schema. A plausible implication is that the core transformation is intentionally documentation-driven and LLM-mediated rather than rule-based. That design explains both the converter’s breadth and its dependence on documentation quality.

3. Generated MCP server architecture

The generated wrappers are built with Python, FastMCP 2.0, subprocess-based command execution, and Docker plus docker-compose. The paper states that the generated servers adopt the MCP structure from the official documentation, consisting of tools, resources, and prompts (Widjaja et al., 2 Oct 2025).

Operationally, the generated MCP server acts as a CLI wrapper. It accepts a structured request from an AI agent, maps fields to the native command-line interface of the underlying tool, executes the tool through subprocess, captures stdout and stderr, and returns a structured object. The execution response is described with three essential fields—command_executed, stderr, and stdout—and the supplementary examples add output_files. The practical response schema is therefore:

$M$4

The Converter is also described as exposing a complete set of parameter options and generating a detailed description for each tag or flag. If an argument is optional, “an appropriate default value will be given accordingly.” The paper does not publish a formal type system, but the examples show booleans, integers, strings, and lists. Naming is normalized into MCP-facing fields such as input_file, output_file, mate1_files, mate2_files, minimum_length, quality_cutoff, numberOfProcessors, and outFileName, although the exact normalization policy is not formalized (Widjaja et al., 2 Oct 2025).

The Bowtie2 example illustrates the translation layer clearly. A structured MCP request with fields including local, threads, index_base, sam_output, mate1_files, mate2_files, and very_sensitive_local is converted into a complete bowtie2 command line, including flags and defaults such as -q, --very-sensitive-local, -N 0, --local, -p 4, and --seed 0. Similar examples are shown for Cutadapt, samtools sort, deeptools:bamCoverage, and SPAdes (Widjaja et al., 2 Oct 2025).

4. Empirical coverage and benchmark evidence

The paper reports 38 converted bioinformatics tools, spanning sequence QC, trimming and preprocessing, aligners, assembly, alignment processing, variant calling, transcriptomics quantification, motif and peak analysis, deep sequencing visualization, single-cell analysis, and general utility tools. For multifunction packages such as GATK and DeepTools, conversion is performed at the level of individual subtools, including ApplyBQSR, BaseRecalibrator, HaplotypeCaller, SelectVariants, bamCoverage, computeGCBias, correctGCBias, and plotCorrelation (Widjaja et al., 2 Oct 2025).

Conversion speed is reported as an average of 40 seconds per tool, with complex tools such as bcftools and cell-ranger taking no more than two minutes. The generated wrappers vary substantially in size: examples include 59 lines for DeepTools:plotCorrelation, 106 lines for FastQC, 665 lines for Bowtie2, 1081 lines for bcftools, and 1297 lines for Cell-ranger. Backend comparison on FastQC shows the following measurements: GPT-4.1-mini at 13.7188 s, 88 NCL, 879 NT, and $M$20.01151; GPT-4o at 13.7019 s, 72 NCL, 801 NT, and $M$30.02834; and Deepseek-chat at 52.9808 s, 106 NCL, 1085 NT, and $0.00996 (Widjaja et al., 2 Oct 2025).

Benchmarking is carried out on three AI-agent platforms: a local AI agent, Claude Desktop, and Cursor. Of the 38 converted tools, 36/38 succeeded across all three platforms; Cell-ranger failed on all three; and STAR succeeded only on the local AI agent. The reported proportion is therefore 94.7%, matching the abstract’s statement that 94.7% successfully executed complex workflows across three widely used AI-agent platforms (Widjaja et al., 2 Oct 2025).

The workflow benchmark further evaluates multi-step use. Five analyses are listed: RNA-seq for differentially expressed genes; WGS for genome assembly; ChIP-seq for motif discovery; ATAC-seq for identifying open chromatin region; and WGS/WES for somatic SNV calling. The benchmark table assigns “Time Required” values of 4, 5, 11, 7, and 9, but the units are not defined in the paper. The prompts used for evaluation ask the agent either to run a named tool on a genomic file path and report commands and outputs, or to run a named pipeline for a specified task and summarize the results (Widjaja et al., 2 Oct 2025).

5. Relation to MCP-enabled bioinformatics infrastructure

BioinfoMCP Converter belongs to a wider effort to render bioinformatics infrastructure machine-actionable for LLMs and autonomous agents. MCPmed frames this transition as a layered progression from UI to API to MCP, where the MCP layer adds semantic metadata, scientific concept tagging, provenance, and operational details such as authentication, rate limits, pagination, health checks, and error handling (Flotho et al., 10 Jul 2025).

The distinction between the two efforts is structural. MCPmed is concerned with bioinformatics web servers and their backends; its concrete examples include GEO, STRING DB, and UCSC Cell Browser, and it proposes HTML-embedded breadcrumbs for services lacking native MCP or even suitable APIs. BioinfoMCP Converter, by contrast, is directed at standalone command-line tools, generating FastMCP-based wrappers around native executables from manuals or --help output rather than wrapping existing web endpoints (Widjaja et al., 2 Oct 2025).

A common misconception is that MCP conversion homogenizes scientific data formats themselves. The BioinfoMCP paper explicitly does not present a dedicated format-normalization engine. Instead, the wrapper standardizes the tool-access layer: structured parameters are passed to the original CLI, which still consumes native file types such as FASTQ, gzipped FASTQ, SAM/BAM, BigWig, YAML datasets, and output directories. This suggests that BioinfoMCP Converter is best viewed as an interoperability mechanism for invocation and orchestration, not as a universal biological data model (Widjaja et al., 2 Oct 2025).

6. Limitations, failure modes, and future directions

The central limitation identified in the paper is dependence on documentation quality. The manual should contain a clear structure for command-line execution, a complete list of flags or tags or options, and enough detail to infer how those options modify execution. Poor or incomplete documentation can therefore degrade generated MCP server robustness (Widjaja et al., 2 Oct 2025).

A second limitation is that automation remains incomplete at the ingestion stage. The current version still requires manual retrieval of PDF documentation or access to --help output. Future work is described as allowing the user to provide only the tool name, after which the framework would automatically invoke tool --help or retrieve documentation from curated online sources (Widjaja et al., 2 Oct 2025).

A third limitation is that the Converter’s internal validation is primarily syntactic. The repair loop detects missing code blocks and syntax errors, but the paper does not describe unit-test synthesis, formal semantic verification, or automated checking of cross-argument constraints. The SPAdes example demonstrates this boundary: the wrapper permits --isolate and --careful together, but SPAdes itself returns the error “you cannot specify --mismatch-correction or --careful in isolate mode!” The wrapper faithfully exposes the failure through structured stdout, stderr, and an empty output_files list, but it does not prevent the invalid combination in advance (Widjaja et al., 2 Oct 2025).

Resource demands also complicate interpretation of success and failure. The paper notes that some failures, especially for STAR and Cell-ranger, are likely tied to heavy memory or time requirements rather than to incorrect wrapper generation, and it adds that current AI agents cannot yet connect to GPUs. Security treatment is comparatively limited: the system prompt includes “safety guardrails,” and Docker packaging provides an isolation boundary, but the paper does not detail a broader security model around shell injection, filesystem restriction, or untrusted input sanitization (Widjaja et al., 2 Oct 2025).

Taken together, these constraints indicate a system that is robust enough for broad practical use but not yet a complete semantic compiler for bioinformatics software. The evidence from 38 converted tools and multi-platform benchmarking nevertheless shows a scalable route for transforming legacy command-line bioinformatics programs into standardized, AI-callable MCP services (Widjaja et al., 2 Oct 2025).