What can you do with this server?

This server bridges biological datasets, physiological biosignals, and robotic actuation systems through six specialized MCP tools for biotech lab automation and prosthetic control. * fetch_genomic_data: Retrieves protein/gene sequence parameters by ID (e.g., UniProt accession like P42212 for GFP), with local SQLite caching and an offline fallback reference database. * resolve_biotech_spatial_intent: Converts assay parameters (concentration and plate scale) into precise spatial metrics in SI base units (meters) for physical positioning. * map_plate_coordinate: Translates standard alphanumeric well IDs (e.g., A1–H12) into exact Cartesian X/Y offsets in millimeters, following SLAS/SBS 96-well plate standards. * calculate_pipetting_speed: Determines optimal G-code feedrates and pressure delay times based on reagent viscosity (cP) and target volume (µL) to ensure precise liquid handling without splashing. * calculate_dna_melting_temp: Computes GC-content and melting temperature (Tm) of a DNA sequence to configure the correct heating plate temperature on a physical lab deck. * translate_emg_to_actuation: Converts human muscle EMG signals (µV) into safe joint angles and G-code velocity profiles for prosthetic or robotic actuation, including a built-in safety envelope check.

seosiri-biorobotics

Official

by SEOSiri-Official

Overview Schema Related Servers Score Discussions

Python

Remote

SEOSiri Bio-Robotics Core Engine

seosiri-biorobotics MCP server

An open-source, stateless Model Context Protocol (MCP) framework bridging the gap between biological datasets, physiological biosignals, and physical robotic actuation systems.

💖 Sponsorship & Open Source Attribution

This project is developed and maintained by SEOSiri-Official (Official website: seosiri.com).

To fund ongoing engineering research or scale the core physical kinematics engine, consider supporting the team via the SEOSiri Sponsors Page.

Related MCP server: mcp-alphafold

Architecture Overview

This framework acts as a stateless broker. Biological inputs (fetched dynamically from standard web APIs like UniProt or fallback reference data) and physiological biosignals (such as surface electromyography, or EMG) are digested, normalized via mathematical boundaries, and translated into explicit Cartesian physical coordinates represented strictly in International System (SI) units (meters). These coordinates are subsequently mapped to standardized G-code strings for physical motion planning or robotic prosthetic actuation.

[Raw Input: Bio-Data / EMG] → [Stateless MCP Server] → [Deterministic Math Core] → [G-code Serial Stream]

Tools

This server exposes six MCP tools:

Tool	Description
`fetch_genomic_data`	Queries live sequence parameters from the UniProt REST API, with a local fallback for offline or rate-limited conditions.
`resolve_biotech_spatial_intent`	Translates assay parameters (concentration, plate scale) into immutable spatial metrics in SI base units.
`map_plate_coordinate`	Translates alphanumeric well IDs (e.g. `A1`–`H12`) into exact millimeter offsets, per SLAS/SBS 96-well plate standards.
`calculate_pipetting_speed`	Calibrates G-code feedrate and pressure delay from reagent viscosity and target volume.
`calculate_dna_melting_temp`	Calculates GC-content and melting temperature (Tm) of a DNA sequence for thermal deck configuration.
`translate_emg_to_actuation`	Translates EMG muscle signals (µV) into safe joint angles and G-code velocity profiles, with a built-in safety envelope check.

Quickstart (CLI Orchestrator)

This project utilizes a local-first Python runtime to bypass IDE proxy lags and regional API restrictions, offering a stable and deterministic execution channel.

Install Package in Editable Mode:

   pip install -e .

Execute the Decoupled Orchestrator (Live UniProt Fetch):

   # Queries live reference protein GFP (P42212)
   python src/run_experiment.py P42212

Execute Using Fallback Database:

   # Fallback reference run for BRCA1
   python src/run_experiment.py BRCA1

Verify the CI/CD Pipeline:

   pytest tests/test_stability.py

🔌 How to Connect to Claude Desktop or Cursor IDE

You can connect this server to your local AI clients using one of two standard methods.

Method 1: Direct Execution from GitHub (Zero-Setup, Recommended)

If you have uv installed, you can run the server directly from our public repository without cloning it locally.

Open your claude_desktop_config.json (Windows: %APPDATA%\Claude\claude_desktop_config.json | macOS: ~/Library/Application Support/Claude/claude_desktop_config.json) and add this configuration:

{
  "mcpServers": {
    "seosiri-biorobotics": {
      "command": "uv",
      "args": [
        "run",
        "--github",
        "SEOSiri-Official/biorobotics",
        "src/main_mcp_server.py"
      ]
    }
  }
}

Method 2: Local Execution (If Cloned)

If you have cloned this repository to your local drive (e.g., D:/my-century-biorobotics-core), configure your client to point to your local entry file:

{
  "mcpServers": {
    "seosiri-biorobotics": {
      "command": "python",
      "args": [
        "D:/my-century-biorobotics-core/src/main_mcp_server.py"
      ],
      "env": {
        "PYTHONPATH": "D:/my-century-biorobotics-core"
      }
    }
  }
}

Verified Live Test Results

All six tools have been independently tested against the running server via Glama.ai's browser-based MCP Inspector, with output matching each tool's closed-form mathematical model exactly:

Tool	Input	Verified Output
`fetch_genomic_data`	`P42212` (GFP)	238-residue sequence, `source: UniProt_Live_API`, `status: DATA_RETRIEVED`
`resolve_biotech_spatial_intent`	concentration=22.8, plate_scale_mm=100.0	`x_axis_delta: 0.022413` m
`map_plate_coordinate`	well=`B5`, plate_format=96	`x: 36, y: 9` mm
`calculate_pipetting_speed`	viscosity_cp=5.0, volume_ul=50.0	`recommended_gcode_feedrate: 300`, `pressure_delay_seconds: 2.5`
`translate_emg_to_actuation`	emg_uV=350, joint=`elbow_servo`	`calculated_angle_degrees: 63`, `gcode_command: "G1 X63.0 F1500.0"`, `safety_envelope: NOMINAL`

Technical Specifications

Communication protocol: Model Context Protocol JSON-RPC over stdio
Actuation protocol: Cartesian G-code, per the NIST RS274/NGC interpreter specification
Coordinate space: SI units (meters), with millimeter-scale conversions for plate-level operations
Verification: automated unit testing via pytest
Containerization: Dockerfile included for isolated runtime environments
Directory sync: glama.json drives the automatic Glama.ai listing sync
Language: Python
Compatible platforms: Linux, macOS, Windows

Requirements

Python 3.10+
uv (optional, for zero-setup remote execution) or pip
An MCP-compatible client (Claude Desktop, Cursor IDE, or Glama's browser-based Inspector)

Contributing

Issues and pull requests are welcome. This is a small, modular, readable Python codebase with clear separation of concerns (core_math.py, hardware_gateway.py, main_mcp_server.py) — a reasonable reference implementation if you're building your own MCP server for a physical-hardware use case.

Roadmap

Closed-loop telemetry: parsing real-time coordinate position queries from serial ports to verify physical arrival
Capacitive liquid-level detection (LLD): halting probe movement immediately on contact with a liquid surface, to prevent pipette tip damage

⚠️ Safety Note

translate_emg_to_actuation is a translation and safety-check layer suitable for research and prototyping — it is not a certified medical or prosthetic control system. Any clinical or assistive deployment requires independent regulatory validation beyond the scope of this project.

License

Distributed under the MIT License. See LICENSE for more information.

Available Tools

6 tools

calculate_dna_melting_tempB

Calculates the GC-content and melting temperature (Tm) of a DNA sequence to determine the required heating plate temperature on the physical deck.

ParametersJSON Schema

Name	Required	Description	Default
`dna_sequence`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so description carries full burden. It mentions outputs but does not disclose behavioral traits like formula assumptions, input validation, error handling, or limits on sequence length/composition.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence efficiently communicates purpose and practical outcome. No wasted words, but could be slightly expanded for key details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with output schema, the description is adequate but could mention typical formula used (e.g., nearest-neighbor) or salt dependency to be fully informative.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter, dna_sequence, with 0% schema description coverage. The description simply says 'DNA sequence' without adding format, allowed characters, case sensitivity, or length constraints beyond the parameter name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it calculates GC-content and melting temperature from a DNA sequence, and explicitly links to determining heating plate temperature. Distinguishes from sibling tools which focus on pipetting, genomic data fetching, plate coordinates, and spatial intent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage for DNA melting temperature calculation, but does not provide explicit guidance on when to use versus alternatives, nor any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

calculate_pipetting_speedA

Calculates the optimal safe feedrate (G-code speed) and physical delay times based on the fluid viscosity (in cP) to ensure precise volumes and prevent splashing.

ParametersJSON Schema

Name	Required	Description	Default
`target_volume_uL`	Yes
`reagent_viscosity_cp`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the tool's behavior: calculating safe settings to prevent splashing and ensure precision. As a pure computation, it is implicitly non-destructive, but this is not stated explicitly. However, the described behavior is accurate and sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no redundant words. Every part serves a purpose: verb, output, inputs, and goal. It is optimally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (two numeric inputs, calculation), the description covers its purpose and key inputs. An output schema exists (not shown), so return value details are handled there. No missing context for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate. It clarifies that 'fluid viscosity' is in cP, which is not evident from the schema alone. The other parameter's unit (uL) is implied by its name. While minimal, this addition provides meaningful context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Calculates') and clearly identifies the tool's output (optimal safe feedrate and delay times) and input basis (fluid viscosity and target volume). It also states the goal (ensure precise volumes, prevent splashing). This distinguishes it from the unrelated sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when pipetting speed needs optimization for specific fluid viscosity and target volume. No explicit when-not or alternative tools are needed since siblings are unrelated, but the context of use is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fetch_genomic_dataA

Queries sequence parameters. Checks the local SQLite cache first. If not cached, queries the UniProt REST API and saves the result locally.

ParametersJSON Schema

Name	Required	Description	Default
`gene_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes caching and API fallback behavior, which is useful. However, lacks details on side effects, error handling, or rate limits. No annotations to compensate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each adding value. The main action is front-loaded. Could be slightly more compact but no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With output schema present and one parameter, description explains caching mechanism well. Minor gap: no mention of error responses or data format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage for 'gene_id'. Description mentions it queries by gene_id but adds no format or validation details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb ('queries') and resource ('sequence parameters'), with additional caching behavior. Distinguishes from siblings, which are unrelated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies use for genomic data fetching but provides no explicit when-to-use, when-not-to-use, or alternative tool guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

map_plate_coordinateA

Translates standard alphanumeric well IDs (e.g., 'A1' to 'H12') into exact Cartesian offsets (X, Y) in millimeters based on SLAS/SBS standards.

ParametersJSON Schema

Name	Required	Description	Default
`well_id`	Yes
`plate_format`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must carry the burden. It mentions the transformation and standards but does not disclose edge cases (e.g., invalid well IDs) or side effects. For a computational mapping, this is adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no wasted words. Every part adds value: verb, resource, examples, standards. Perfectly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description doesn't need to detail return values. It covers the main purpose, standards, and units. However, it lacks details on supported plate formats and error behavior, which would make it more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions are absent (0% coverage). The description implicitly defines 'well_id' via examples but does not explain 'plate_format' or its role. With no schema help, the description fails to fully clarify parameter meanings.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'translates' and the resource 'well IDs to Cartesian offsets', with specific examples ('A1' to 'H12') and standards (SLAS/SBS). It distinguishes from unrelated sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance is provided. The description implies usage for coordinate conversion but lacks exclusions or alternatives. Siblings are unrelated, so no confusion, but still falls short of a 4.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

resolve_biotech_spatial_intentC

Translates assay parameters into immutable spatial metrics using SI base units (meters).

ParametersJSON Schema

Name	Required	Description	Default
`plate_scale_mm`	Yes
`concentration_input`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden. It discloses that the output is 'immutable,' implying idempotent behavior and no side effects. It also specifies SI units (meters). However, it does not mention authorization needs, rate limits, or what happens with invalid inputs, leaving some behavioral aspects undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded with the action and key details (immutable, SI units). It is concise and avoids redundancy. However, it is so brief that it sacrifices completeness, which slightly reduces conciseness effectiveness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given two parameters with no schema descriptions and a likely transformation function, the description is too minimal. It does not explain the conversion formula, value ranges, or the meaning of the output metrics (even though an output schema exists). An agent would need to guess the tool's inner logic. For a translation tool, more context is expected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, and the tool description adds no explanation for the parameters 'concentration_input' and 'plate_scale_mm.' Their names hint at meaning, but the description only references 'assay parameters' generically. The agent gets no additional semantic information beyond the parameter names themselves.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'translates' and specifies the result is 'immutable spatial metrics using SI base units (meters).' This clearly indicates a transformation of inputs to outputs in defined units, distinguishing it from the sibling tool 'fetch_genomic_data' which retrieves data. However, 'assay parameters' is vague; it doesn't explicitly state that the tool computes something like spatial resolution or distance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidance is provided. The description does not state when to use this tool versus any alternatives, nor does it mention prerequisites, such as required experimental conditions or data formats. While the sibling tool is different, explicit context for selection is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

translate_emg_to_actuationA

Translates human muscle electrical signals (EMG in microvolts) into safe, deterministic joint angles and velocity profiles for prosthetic actuation.

ParametersJSON Schema

Name	Required	Description	Default
`joint_id`	No		elbow_servo
`emg_microvolts`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions 'safe, deterministic' outputs, which adds behavioral context, but lacks details on calibration, error handling, or edge cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no redundant words, front-loaded with action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with 2 parameters and an output schema, but missing usage guidelines and full parameter semantics; adequate but not comprehensive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description adds value by explaining emg_microvolts and the output (joint angles, velocity profiles). However, joint_id parameter is not explained beyond its default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool translates EMG signals into joint angles and velocity profiles for prosthetic actuation, using specific verbs and resources, and distinguishes it from unrelated sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, no prerequisites or exclusions provided; the description only implies usage for prosthetic actuation.

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. Dates show when Glama detected each change.

1 tool updatev0.1.3Jul 15, 2026
- Addedtranslate_emg_to_actuation
1 tool updatev0.1.2Jul 15, 2026
- Addedcalculate_dna_melting_temp
2 tool updatesv0.1.1Jul 15, 2026
- Addedcalculate_pipetting_speed
- Addedmap_plate_coordinate
2 tool updatesv0.1.0Jul 15, 2026
- First observedfetch_genomic_data
- First observedresolve_biotech_spatial_intent

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool targets a distinct function: DNA melting, pipetting speed, genomic data retrieval, plate coordinate mapping, spatial intent resolution, and EMG actuation. There is no overlap in purpose.

Naming Consistency5/5

All tools follow a consistent verb_noun_noun pattern in snake_case (e.g., calculate_dna_melting_temp, translate_emg_to_actuation). The naming is uniform and predictable.

Tool Count5/5

With 6 tools, the server has a reasonable scope. The count is well within the typical 3-15 range for a focused server.

Completeness2/5

The tools cover disparate areas (wet lab, hardware mapping, prosthetics) without clear integration or coverage of any single domain. For a biorobotics server, there are significant gaps, e.g., no tools for robot control, sensor data processing, or experiment sequencing.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

phasefolio A
com.phasefolio
Biotech rNPV/PoS engine for AI agents. Signed exports, evidence register, asset landscape.
Bioinformatics Finance AI & Machine Learning
132
Axon NeuroAutomataOAuth
ai.axonagentic
Protein analysis: ESM-2/ESMC embeddings, mutation scoring, landscape scans, ESMFold structure.
Bioinformatics Biology & Medicine
2
Elnora MCP ServerOAuth
io.github.Elnora-AI
AI-powered bioprotocol optimization — generate, search, and manage lab protocols via MCP
Biology & Medicine Research & Data App Automation
23
uniprot-mcp-server A
io.github.cyanheads
Protein research over UniProtKB — search by function, fetch curated records, map IDs, proteomes.
Bioinformatics Biology & Medicine
611

Related MCP Servers

UniProt MCP Server
Bioinformatics Research & Data Databases
josefdc
A
license
B
quality
D
maintenance
Provides seamless access to UniProtKB protein database, enabling queries for protein entries, sequences, Gene Ontology annotations, full-text search, and ID mapping across 200+ database types.
Updated 6 months ago (2026-03-02 13:22 UTC)
5
2
MIT
mcp-alphafold
Bioinformatics Biology & Medicine
zeinab-sheikhi
F
license
B
quality
D
maintenance
Provides programmatic access to AlphaFold protein structure predictions and UniProt data, enabling users to retrieve protein structures, summaries, and annotations through natural language.
Updated a year ago (2025-06-08 15:29 UTC)
3
-
mcp-printable
Design Tools
AaronGoldsmith
A
license
A
quality
B
maintenance
Connects MCP-capable agents to Blender and OpenSCAD for AI-driven 3D modeling, with tools and rules optimized for FDM-printable geometry.
Updated 2 months ago (2026-07-05 21:43 UTC)
29
2
MIT
SciAgentKit
Bioinformatics Biology & Medicine
ehsansyh
A
license
Not graded
quality
C
maintenance
MCP-native scientific skills for reproducible computational biology and AI-driven drug-discovery workflows. It combines deterministic scientific tools with an MCP server to give AI agents real computational capabilities.
Updated 3 months ago (2026-06-18 21:24 UTC)
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SEOSiri-Official/biorobotics'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

SEOSiri Bio-Robotics Core Engine

💖 Sponsorship & Open Source Attribution

Architecture Overview

Tools

Quickstart (CLI Orchestrator)

🔌 How to Connect to Claude Desktop or Cursor IDE

Method 1: Direct Execution from GitHub (Zero-Setup, Recommended)

Method 2: Local Execution (If Cloned)

Verified Live Test Results

Technical Specifications

Requirements

Contributing

Roadmap

⚠️ Safety Note

License

Links

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API