biomate-connector puts 2,455 bioinformatics workflows behind an MCP tool call

From a sentence in chat to a running pipeline

Bioinformatics work usually breaks at the interface, not the analysis. The person who knows which pipeline to run is often not the person who can write the command, and the data sits on an instrument, in a bucket, or behind an accession number. biomate-connector is built to remove that hand-off: you describe the goal in one to three sentences of plain English, and BioMate picks a workflow, fills the parameters, launches it, and streams progress back to whatever assistant you were already talking to.

The README's own examples give the flavour: ask for hERG inhibition and CYP3A4 metabolism on two molecules given as SMILES, ask for RNA-seq differential expression on an s3 path with a strand orientation and an FDR threshold, or ask for a CryoSPARC homogeneous refinement with C2 symmetry and a box size. It claims 2,455 indexed workflows behind that selection step.

The intended user is a wet-lab scientist or a computational biologist who already has a BioMate account and would rather stay in Claude Code, ChatGPT, Slack or WeChat than open another console.

Seventeen tools across three tiers, from one manifest

The repository describes 17 tools split by surface capability. The lite set is what consumer surfaces get: biomate_session, which is the entry point that takes the goal and drives the run; upload_file, which returns a presigned S3 URL so a local file can be staged first; and export_report, which downloads the findings as PDF or DOCX once a run finishes.

The full set, available to Claude Desktop, Cursor, Codex and the API, adds workflow primitives for searching a workflow, reading its spec, running it, polling it, cancelling it and listing past runs. It also adds output helpers to preview a file, analyse results and explain an error, a database query tool, a memory recall tool, and three data connectors for resolving an accession, browsing data and fetching public data.

What holds this together is the mcp/ directory, which the README calls the shared MCP tools manifest and server and the single source of truth for all surfaces. That is the right architecture for a project that has to keep seven clients in sync, and it is also why the repository contains a regen_tools_manifest.sh script: the manifest is generated rather than hand-edited per surface.

Installing it and making the first call

The fast path is a single npx command per surface. The CLI writes the MCP configuration for you and stores your token in the OS keychain, and you authenticate once in a browser.

npx @biomate/connect claude-code

The README lists one command per supported surface: claude-code, claude-desktop, cursor and codex all take the same shape, with open-claw covering WeChat and Open Claw. ChatGPT and Slack do not have a one-liner here; the README points at connectors/chatgpt/INSTALL.md and connectors/slack/README.md instead.

If you would rather wire it up by hand, or you are on a surface the CLI does not cover, authentication is an API key. Generate one in the BioMate settings page, copy it when shown, since the README states the value is only displayed once, then export it:

export BIOMATE_API_KEY=bm_live_...

Before you trust the rest of the setup, check the key against the ping endpoint. The README shows this request and says it returns a JSON body with a status of ok and your user address.

curl -H "X-API-Key: $BIOMATE_API_KEY" https://app.biomate.ai/api/tools/ping

For Claude Desktop, Cursor and Codex the MCP server is a Python module, configured through the standard mcpServers block. This is the config from the README, with the API URL and key passed as environment variables:

{
  "mcpServers": {
    "biomate": {
      "command": "python3",
      "args": ["-m", "mcp.biomate_mcp_server"],
      "env": {
        "BIOMATE_API_URL": "https://app.biomate.ai",
        "BIOMATE_API_KEY": "bm_live_..."
      }
    }
  }
}

After that the first real use is a goal rather than a command. The README advises including the analysis type, the data location or inline sequences, and any parameter that matters, and says you can omit anything BioMate can reasonably infer because it will ask when something is genuinely ambiguous.

Watchers that start a run when an instrument finishes

The lab_instruments directory is the part that is genuinely unusual, and it is what separates this from another chat integration. Ten connectors are documented, each keyed to a trigger rather than a schedule.

| Instrument | File | Trigger | |---|---|---| | Illumina BaseSpace | lab_instruments/illumina_basespace_connector.py | New run via BaseSpace API | | Oxford Nanopore MinKNOW | lab_instruments/nanopore_minknow_connector.py | Run complete via MinKNOW HTTP API | | CryoEM EPU | lab_instruments/cryoem_instrument_connector.py | New .mrc or .mrcs micrographs in output dir | | LC-MS | lab_instruments/lcms_connector.py | New .raw, .d or .wiff files (Thermo, Bruker, Waters, SCIEX) | | Flow Cytometer | lab_instruments/flow_cytometer_connector.py | New .fcs files (BD, Beckman, Sony) | | qPCR | lab_instruments/qpcr_connector.py | New .eds (QuantStudio) or .pcrd (Bio-Rad CFX) | | Plate Reader | lab_instruments/plate_reader_connector.py | New .xlsx exports (BioTek, Molecular Devices) | | Opentrons OT-2/Flex | lab_instruments/opentrons_connector.py | Protocol complete via robot HTTP API | | Benchling ELN | lab_instruments/benchling_connector.py | New entry or assay result via Benchling API | | SiLA2 devices | lab_instruments/sila2_adapter.py | gRPC events (Hamilton, Sartorius) |

The README says there are six more beyond these ten. Setting one up means copying config.example.yaml from lab_instruments, filling in the instrument details, and starting the watcher.

pip install -r requirements.txt
python3 lab_instruments/instrument_watcher.py --config config.yaml

The connector test suites are described as covering an offline sandbox, a live API, and 68 lab instrument checks, which is a meaningful amount of coverage for code that has to speak to vendor hardware.

Tokens, scopes and the authorization server

Browser-based surfaces authenticate with OAuth 2.1 and PKCE rather than a static key, and the repository ships the authorization server itself under oauth_server/. The README describes it as self-contained and runnable independently, with configuration options documented in oauth_server/oauth/server.py.

The security section is short and specific, which is a good sign. No shared secrets and no stored passwords. Per-surface scope grants that can be revoked individually from the account connectors page. Refresh tokens hashed at rest with HMAC-SHA256 and rotated on every use. Access tokens are 30-minute JWTs.

Two things follow for anyone rolling this out in a lab. Rotation on every use means a stolen refresh token is single-use, but it also means a client that cannot persist state will churn through them. And because grants are per surface, disconnecting Slack does not have to disturb Claude Code.

The repository also carries seed_oauth_clients.py, so registering clients is scripted rather than manual.

Where your data goes, and what you cannot self-host

The limitation to be clear-eyed about is architectural. This repository is the connector, not the platform. The README describes runs launching on BioMate cloud, and the privacy policy it links is the place to read what the connector sends and how it is stored, shared and retained. On a locked-down institutional network, that is the question that decides adoption.

Self-hosting extends to the OAuth server only. Nothing in the README suggests you can run the workflow execution layer on your own hardware.

The other practical caveats are smaller. Instrument connectors depend on vendor APIs and on file-drop detection, so a vendor changing its API or a machine writing to a new directory breaks the trigger. The repository has no releases, so there is no tagged version to pin to. The last push was on 2026-07-10 and the repository is not archived.

It is also the wrong tool if you want to inspect or modify the pipelines. Those live behind the platform, not in this repository.

Against nf-core and running the pipelines yourself

The closest alternative in spirit is nf-core, the community collection of curated Nextflow pipelines. The difference in approach is where the decision and the compute live. With nf-core you choose the pipeline yourself, supply parameters in a config or on the command line, and run it wherever you have Nextflow and a container runtime: a laptop, an HPC cluster, or your own cloud account. The data does not leave your infrastructure unless you move it.

BioMate inverts both halves. Selection is inference from a sentence rather than a choice you make, and execution happens on the vendor's cloud. You gain a route from intent to result that does not require knowing which of 2,455 workflows applies, and you give up the ability to read the pipeline that produced your numbers.

For a group with a cluster and someone who knows Nextflow, nf-core remains the stronger position on reproducibility and cost control. For a group with neither, and with instruments producing files nobody has time to route, the connector addresses a real bottleneck.

Licence, layout and maintenance

The README states MIT for the connector code in this repository, and says BioMate platform usage is governed by the terms at biomate.ai/terms. Read those two sentences together: what you can fork, modify and redistribute is the client, and what you are paying for and bound by is the service. Commercial terms for the platform are not in this repository.

The layout reflects that split. connectors/ holds the per-surface install guides and the CLI, lab_instruments/ holds the instrument watchers, oauth_server/ holds the authorization server, mcp/ holds the shared manifest and server, skills/biomate/ is a Claude skill bundle for the Anthropic Skills gallery, and tests/ holds the connector suites. There is also a biomate_connector package directory and a docs directory carrying the architecture and data flow figures.

Maintenance is a single branch with no release tags, so anyone depending on it is tracking main. The contribution surface is narrow by design: adding a surface means adding an install path against the shared manifest, and adding an instrument means adding a file under lab_instruments plus a test.

Editorial conclusion

Take it if you already pay for BioMate and want to drive it from a chat or coding assistant instead of a dashboard, or if you want an instrument to hand its output straight to a pipeline. Leave it if you need to run analysis inside your own network, since the repository only self-hosts the authorization server, not the execution layer, and every run is described as launching on BioMate cloud. Check three things first: that the MIT grant covers only the connector code while platform use falls under the BioMate terms, that your surface is one of the seven listed with a real install command, and that sending your FASTQ files or vendor exports offsite is something your institution permits.

Frequently asked questions

Official sources

1. bioMate-AI/biomate-connector on GitHub
2. Issues
3. README