mcp-bionemo
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NGC_API_KEY | No | NGC API key for hosted BioNeMo NIMs. Required when using the hosted live backend. | |
| BIONEMO_BACKEND | No | Set to 'live' to call the real BioNeMo NIMs. By default the server uses an in-process simulator. | simulator |
| BIONEMO_BASE_URL | No | Base URL for a self-hosted BioNeMo NIM, e.g. https://health.api.nvidia.com/v1. Alternative to NGC_API_KEY for the live backend. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| infoA | Return which backend is active (simulated or live) and the tools this server exposes. |
| design_backboneB | Design a protein backbone with RFdiffusion. Args: input_pdb: the target structure as PDB text (the scaffold/target to design against). contigs: RFdiffusion contig string describing what to generate, e.g. "A1-100/0 50-60". hotspot_res: optional target residues the binder should contact, e.g. ["A59", "A83"]. Returns a dict with |
| design_sequencesB | Design amino-acid sequences that fold to a given backbone with ProteinMPNN. Args: input_pdb: the backbone (PDB text) to design sequences for. num_sequences: how many candidate sequences to return. Returns a dict with |
| fold_complexA | Co-fold one or more protein chains (optionally with small-molecule ligands) using Boltz-2. Args: protein_sequences: one amino-acid sequence per protein chain. Give the binder AND the target together to score the complex; a binder folded alone does not measure binding. ligand_smiles: optional list of SMILES strings for small-molecule ligands. predict_affinity: if true and a ligand is given, also return a binding-affinity estimate. Returns a dict with |
| design_binderA | Convenience pipeline: RFdiffusion backbone, then ProteinMPNN sequences for it, in one call. Returns a dict with |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
The tools mostly target distinct stages of the protein-design workflow: info, backbone generation, sequence design, and complex folding. The only overlap is design_binder, which is a convenience wrapper around design_backbone plus design_sequences, but its description makes that relationship clear.
Tool names are consistently snake_case and mostly follow an action-oriented pattern: design_backbone, design_sequences, design_binder, fold_complex. The lone outlier is info, which is a noun-only metadata tool, but it does not break readability.
Five tools is well-scoped for a focused protein/binder design server. Each tool has a clear role in the pipeline, and there is no redundant bloat beyond the intentional convenience wrapper.
The surface covers the core workflow: backbone design, sequence design, complex folding, optional affinity estimation, and a combined pipeline. Minor gaps remain around ranking/filtering designs and direct protein-protein affinity scoring, but agents can work around these using the returned confidence scores.