How do I use UniProt MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@UniProt MCP Server fetch the protein entry for P12345" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

UniProt MCP Server

by josefdc

Overview Schema Related Servers Score Discussions

Python

Hybrid

UniProt MCP Server

PyPI version Python versions License: MIT MCP Registry

A Model Context Protocol (MCP) server that provides seamless access to UniProtKB protein data. Query protein entries, sequences, Gene Ontology annotations, and perform ID mappings through a typed, resilient interface designed for LLM agents.

✨ Features

🔌 Dual Transport: Stdio for local development and Streamable HTTP for remote deployments
📊 Rich Data Access: Fetch complete protein entries with sequences, features, GO annotations, cross-references, and taxonomy
🔍 Advanced Search: Full-text search with filtering by review status, organism, keywords, and more
🔄 ID Mapping: Convert between 200+ database identifier types with progress tracking
🛡️ Production Ready: Automatic retries with exponential backoff, CORS support, Prometheus metrics
📝 Typed Responses: Structured Pydantic models ensure data consistency
🎯 MCP Primitives: Resources, tools, and prompts designed for agent workflows

Related MCP server: mcp-uniprot

🚀 Quick Start

Installation

pip install uniprot-mcp

Run the Server

Local development (stdio):

uniprot-mcp

Remote deployment (HTTP):

uniprot-mcp-http --host 0.0.0.0 --port 8000

The HTTP server provides:

MCP endpoint: http://localhost:8000/mcp
Health check: http://localhost:8000/healthz
Metrics: http://localhost:8000/metrics (Prometheus format)

Test with MCP Inspector

npx @modelcontextprotocol/inspector uniprot-mcp

📚 MCP Primitives

Resources

Access static or dynamic data through URI patterns:

URI	Description
`uniprot://uniprotkb/{accession}`	Raw UniProtKB entry JSON for any accession
`uniprot://help/search`	Documentation for search query syntax

Tools

Execute actions and retrieve typed data:

Tool	Parameters	Returns	Description
`fetch_entry`	`accession`, `fields?`	`Entry`	Fetch complete protein entry with all annotations
`get_sequence`	`accession`	`Sequence`	Get protein sequence with length and metadata
`search_uniprot`	`query`, `size`, `reviewed_only`, `fields?`, `sort?`, `include_isoform`	`SearchHit[]`	Full-text search with advanced filtering
`map_ids`	`from_db`, `to_db`, `ids`	`MappingResult`	Convert identifiers between 200+ databases
`fetch_entry_flatfile`	`accession`, `version`, `format`	`string`	Retrieve historical entry versions (txt/fasta)

Progress tracking: map_ids reports progress (0.0 → 1.0) for long-running jobs.

Prompts

Pre-built templates for common workflows:

Summarize Protein: Generate a structured summary from a UniProt accession, including organism, function, GO terms, and notable features.

🔧 Configuration

Environment Variables

Variable	Default	Description
`UNIPROT_ENABLE_FIELDS`	unset	Request minimal field subsets to reduce payload size
`UNIPROT_LOG_LEVEL`	`info`	Logging level: `debug`, `info`, `warning`, `error`
`UNIPROT_LOG_FORMAT`	`plain`	Log format: `plain` or `json`
`UNIPROT_MAX_CONCURRENCY`	`8`	Max concurrent UniProt API requests
`MCP_HTTP_HOST`	`0.0.0.0`	HTTP server bind address
`MCP_HTTP_PORT`	`8000`	HTTP server port
`MCP_HTTP_LOG_LEVEL`	`info`	Uvicorn log level
`MCP_HTTP_RELOAD`	`0`	Enable auto-reload: `1` or `true`
`MCP_CORS_ALLOW_ORIGINS`	`*`	CORS allowed origins (comma-separated)
`MCP_CORS_ALLOW_METHODS`	`GET,POST,DELETE`	CORS allowed methods
`MCP_CORS_ALLOW_HEADERS`	`*`	CORS allowed headers

CLI Flags

# HTTP server flags
uniprot-mcp-http --host 127.0.0.1 --port 9000 --log-level debug --reload

📖 Usage Examples

Fetching a Protein Entry

# Using MCP client
result = await session.call_tool("fetch_entry", {
    "accession": "P12345"
})

# Returns structured Entry with:
# - primaryAccession, protein names, organism
# - sequence (length, mass, sequence string)
# - features (domains, modifications, variants)
# - GO annotations (biological process, molecular function, cellular component)
# - cross-references to other databases

Searching for Proteins

# Search reviewed human proteins
result = await session.call_tool("search_uniprot", {
    "query": "kinase AND organism_id:9606",
    "size": 50,
    "reviewed_only": True,
    "sort": "annotation_score"
})

# Returns list of SearchHit objects with accessions and scores

Mapping Identifiers

# Convert UniProt IDs to PDB structures
result = await session.call_tool("map_ids", {
    "from_db": "UniProtKB_AC-ID",
    "to_db": "PDB",
    "ids": ["P12345", "Q9Y6K9"]
})

# Returns MappingResult with successful and failed mappings

🛠️ Development

Prerequisites

Python 3.11 or 3.12
uv (recommended) or pip

Setup

# Clone the repository
git clone https://github.com/josefdc/Uniprot-MCP.git
cd Uniprot-MCP

# Install dependencies
uv sync --group dev

# Install development tools
uv tool install ruff
uv tool install mypy

Running Tests

# Run all tests with coverage
uv run pytest --maxfail=1 --cov=uniprot_mcp --cov-report=term-missing

# Run specific test file
uv run pytest tests/unit/test_parsers.py -v

# Run integration tests only
uv run pytest tests/integration/ -v

Code Quality

# Lint
uv tool run ruff check .

# Format
uv tool run ruff format .

# Type check
uv tool run mypy src

# Run all checks
uv tool run ruff check . && \
uv tool run ruff format --check . && \
uv tool run mypy src && \
uv run pytest

Local Development Server

# Stdio server
uv run uniprot-mcp

# HTTP server with auto-reload
uv run python -m uvicorn uniprot_mcp.http_app:app --reload --host 127.0.0.1 --port 8000

🏗️ Architecture

src/uniprot_mcp/
├── adapters/           # UniProt REST API client and response parsers
│   ├── uniprot_client.py  # HTTP client with retry logic
│   └── parsers.py         # Transform UniProt JSON → Pydantic models
├── models/
│   └── domain.py       # Typed data models (Entry, Sequence, etc.)
├── server.py           # MCP stdio server (FastMCP)
├── http_app.py         # MCP HTTP server (Starlette + CORS)
├── prompts.py          # MCP prompt templates
└── obs.py              # Observability (logging, metrics)

tests/
├── unit/               # Unit tests for parsers, models, tools
├── integration/        # End-to-end tests with VCR fixtures
└── fixtures/           # Test data (UniProt JSON responses)

📦 Publishing

This server is published to:

PyPI: uniprot-mcp
MCP Registry: io.github.josefdc/uniprot-mcp

Building and Publishing

# Build distribution packages
uv build

# Publish to PyPI (requires token)
uv publish --token pypi-YOUR_TOKEN

# Publish to MCP Registry (requires GitHub auth)
mcp-publisher login github
mcp-publisher publish

See docs/registry.md for detailed registry publishing instructions.

🤝 Contributing

Contributions are welcome! Please:

Read our Contributing Guidelines
Follow our Code of Conduct
Check the Security Policy for vulnerability reporting
Review the Changelog for recent changes

Quick start for contributors:

Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Make your changes with tests
Run quality checks: uv tool run ruff check . && uv tool run mypy src && uv run pytest
Commit using Conventional Commits (feat:, fix:, docs:, etc.)
Push and open a Pull Request

📄 License

This project is licensed under the MIT License - see the LICENSE file for details.

🙏 Acknowledgments

UniProt Consortium: For providing comprehensive, high-quality protein data through their REST API
Anthropic: For the Model Context Protocol specification and Python SDK
Community: For feedback, bug reports, and contributions

🔗 Links

Documentation: GitHub Repository
UniProt API: REST API Documentation
MCP Specification: Model Context Protocol
Issues & Support: GitHub Issues

⚠️ Disclaimer

This is an independent project and is not officially affiliated with or endorsed by the UniProt Consortium. Please review UniProt's terms of use when using their data.

Built with ❤️ for the bioinformatics and AI communities

Available Tools

5 tools

fetch_entryC

Return a structured UniProt entry.

ParametersJSON Schema

Name	Required	Description	Default
`accession`	Yes
`fields`	No
`version`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`go`	No	Gene Ontology annotations extracted from the entry.
`id`	No	UniProt entry name/ID.
`xrefs`	No	Cross-references to external databases.
`features`	No	Annotated sequence features.
`organism`	No	Scientific name of the source organism.
`reviewed`	Yes	True for Swiss-Prot, False for TrEMBL.
`sequence`	No	Protein sequence metadata when available.
`accession`	Yes	Primary accession identifier.
`raw_payload`	No	Original UniProt payload for debugging or future enrichment.
`taxonomy_id`	No	NCBI taxonomy identifier for the organism.
`gene_symbols`	No	Canonical gene symbols associated with the entry.
`protein_name`	No	Recommended protein name where available.

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure but only states it returns structured data without detailing aspects like rate limits, authentication needs, error handling, or what 'structured' entails. It misses critical behavioral traits for a read operation.

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, efficient sentence with zero waste, front-loading the core purpose. It's appropriately sized for a simple tool, though its brevity contributes to gaps in other dimensions.

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?

Given 3 parameters with 0% schema coverage and no annotations, the description is incomplete as it lacks parameter semantics and behavioral details. However, the presence of an output schema reduces the need to explain return values, making it minimally adequate but with clear gaps.

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 description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'accession', 'fields', or 'version' mean, their formats, or how they affect the output, leaving all three parameters semantically undocumented.

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 clearly states the action ('Return') and the resource ('a structured UniProt entry'), providing specific verb+resource pairing. However, it doesn't differentiate from sibling tools like 'fetch_entry_flatfile' or 'get_sequence', which likely retrieve similar data in different formats or scopes.

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 is provided on when to use this tool versus alternatives like 'fetch_entry_flatfile' or 'get_sequence'. The description lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from tool names alone.

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

fetch_entry_flatfileC

Return the UniProt flatfile (txt or fasta) for a specific entry version.

ParametersJSON Schema

Name	Required	Default
`accession`	Yes
`version`	Yes
`format`	No	txt

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/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 of behavioral disclosure. It states the tool returns a flatfile but doesn't describe aspects like rate limits, authentication needs, error handling, or whether it's a read-only operation (implied by 'Return' but not explicit). This leaves significant gaps for a tool with no annotation coverage.

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, efficient sentence that front-loads the key action and resource. There is no wasted wording, making it highly concise and well-structured for quick understanding.

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?

Given the tool has an output schema (which should cover return values), no annotations, and low schema coverage, the description is minimally adequate. It states the purpose but lacks details on parameters, behavioral traits, and usage context, making it incomplete for full agent guidance without relying heavily on the output schema.

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 description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'specific entry version' and 'format' but doesn't explain what 'accession' or 'version' represent (e.g., UniProt identifiers), nor does it detail valid formats beyond 'txt or fasta'. This adds minimal value beyond the schema.

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 clearly states the action ('Return') and the specific resource ('UniProt flatfile for a specific entry version'), distinguishing it from siblings like 'fetch_entry' or 'get_sequence' by specifying the flatfile format. However, it doesn't explicitly differentiate from all siblings (e.g., 'search_uniprot' might also return flatfiles), so it's not a perfect 5.

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?

The description provides no guidance on when to use this tool versus alternatives like 'fetch_entry' or 'get_sequence', nor does it mention any prerequisites or exclusions. It implies usage for retrieving flatfiles but lacks explicit context for tool selection.

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

get_sequenceC

Return only the sequence metadata for an accession.

ParametersJSON Schema

Name	Required	Description	Default
`accession`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns metadata, implying a read-only operation, but doesn't specify details like rate limits, error handling, or what 'sequence metadata' includes (e.g., format, size). This leaves significant gaps in understanding the tool's behavior.

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, clear sentence with zero wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration.

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?

Given the tool's low complexity (one parameter) and the presence of an output schema, the description is minimally adequate. However, with no annotations and poor parameter documentation, it lacks completeness for safe and effective use, such as clarifying the 'accession' parameter or behavioral traits.

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 input schema has 0% description coverage, with one undocumented parameter 'accession'. The description adds minimal semantics by implying 'accession' is used to retrieve sequence metadata, but it doesn't explain what an accession is (e.g., a database identifier), its format, or examples, failing to compensate for the schema's lack of documentation.

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 clearly states the verb ('return') and resource ('sequence metadata for an accession'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'fetch_entry' or 'fetch_entry_flatfile', which might also retrieve sequence-related data, so it doesn't reach the highest score.

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?

The description provides no guidance on when to use this tool versus alternatives like 'fetch_entry' or 'search_uniprot'. It lacks context about prerequisites, such as what an 'accession' refers to or any constraints, leaving the agent without usage direction.

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

map_idsC

Map identifiers between UniProt-supported namespaces.

ParametersJSON Schema

Name	Required	Description	Default
`from_db`	Yes
`to_db`	Yes
`ids`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`to_db`	Yes	Target identifier namespace.
`from_db`	Yes	Source identifier namespace.
`results`	No	Mapping from input IDs to resolved identifiers (empty list for no match).

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but lacks details on permissions, rate limits, error handling, or what the mapping entails (e.g., one-to-one, many-to-many). This is a significant gap for a tool with parameters and an output schema.

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, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the core function without unnecessary elaboration.

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?

Given 3 parameters with 0% schema coverage and an output schema, the description is incomplete. It covers the basic purpose but lacks parameter details and behavioral context. The output schema mitigates some gaps, but overall it's minimally adequate with clear room for improvement.

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 description coverage is 0%, so the description must compensate. It implies parameters for source/target databases and IDs but doesn't explain what 'UniProt-supported namespaces' are, valid values for from_db/to_db, or ID formats. This leaves key semantics undocumented.

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 clearly states the tool's purpose: mapping identifiers between UniProt-supported namespaces. It specifies the verb 'map' and the resource 'identifiers', but doesn't differentiate from sibling tools like fetch_entry or search_uniprot, which have different functions (fetching entries vs. searching).

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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage based on the purpose alone.

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

search_uniprotB

Search UniProtKB and return curated hits.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`size`	No
`reviewed_only`	No
`fields`	No
`sort`	No
`include_isoform`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'curated hits' but doesn't explain what that entails, such as result format, pagination, rate limits, or authentication needs. This is inadequate for a search tool with 6 parameters.

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, efficient sentence with no wasted words. It's front-loaded with the core action and outcome, making it easy to parse quickly.

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?

Given the complexity (6 parameters, no annotations) and the presence of an output schema, the description is minimally adequate but lacks depth. It doesn't explain what 'curated hits' means or how results are structured, though the output schema may cover return values. For a search tool, more context on behavior and usage would be beneficial.

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 description coverage is 0%, so the description must compensate, but it adds no parameter-specific information beyond the generic 'search' context. The baseline is 3 because the schema provides parameter details (e.g., defaults, types), but the description doesn't enhance understanding of what parameters like 'fields' or 'sort' mean in practice.

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 clearly states the action ('Search UniProtKB') and the outcome ('return curated hits'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'fetch_entry' or 'map_ids', which is why it's not a 5.

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?

The description provides no guidance on when to use this tool versus alternatives like 'fetch_entry' or 'map_ids'. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.

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.

5 tool updatesv1.0.0Jan 3, 2026
- Changedfetch_entry1 field changed
  - addedInput schema / title
```
Added value: +"fetch_entryArguments"
```
- Changedfetch_entry_flatfile1 field changed
  - addedInput schema / title
```
Added value: +"fetch_entry_flatfileArguments"
```
- Changedget_sequence1 field changed
  - addedInput schema / title
```
Added value: +"get_sequenceArguments"
```
- Changedmap_ids1 field changed
  - addedInput schema / title
```
Added value: +"map_idsArguments"
```
- Changedsearch_uniprot1 field changed
  - addedInput schema / title
```
Added value: +"search_uniprotArguments"
```
5 tool updatesNov 3, 2025
- First observedfetch_entry
- First observedfetch_entry_flatfile
- First observedget_sequence
- First observedmap_ids
- First observedsearch_uniprot

Install Server

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

TDQS

B3.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: fetch_entry retrieves structured data, fetch_entry_flatfile provides flatfile formats, get_sequence focuses on sequence metadata, map_ids handles identifier mapping, and search_uniprot performs searches. There is no overlap or ambiguity between these functions.

Naming Consistency4/5

The naming is mostly consistent with a verb_noun pattern (e.g., fetch_entry, get_sequence, map_ids, search_uniprot), but fetch_entry_flatfile deviates slightly by including an extra descriptor. Overall, the pattern is readable and predictable.

Tool Count5/5

With 5 tools, this server is well-scoped for the UniProt domain. Each tool serves a specific, essential function without redundancy, making the count appropriate for typical use cases like data retrieval, mapping, and searching.

Completeness4/5

The toolset covers core operations for UniProt access: fetching entries in different formats, getting sequences, mapping IDs, and searching. A minor gap might be the lack of update or delete tools, but these are likely unnecessary for a read-only biological database, so agents can work effectively with the provided tools.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

uniprot-mcp-server A
io.github.cyanheads
Protein research over UniProtKB — search by function, fetch curated records, map IDs, proteomes.
Bioinformatics Biology & Medicine
611
Uniprot A
io.github.pipeworx-io
UniProt MCP — protein sequence + function database.
Bioinformatics Biology & Medicine Research & Data
372
STRING Database MCP Server A
org.string-db
Query STRING interactions, enrichment, annotations, homology, and PPI networks.
Bioinformatics Biology & Medicine
1725
wikidata-mcp-server A
io.github.cyanheads
Search and fetch Wikidata entities, execute SPARQL queries, and resolve external identifiers.
Knowledge & Memory Search Open Data
723

Related MCP Servers

UniProt MCP Server
Bioinformatics Research & Data Databases
TakumiY235
A
license
B
quality
D
maintenance
Enables AI assistants to access protein information directly from UniProt, allowing retrieval of protein names, functions, sequences, and organism data by accession number.
Updated 3 months ago (2026-05-29 16:23 UTC)
2
14
MIT
mcp-uniprot
Bioinformatics Biology & Medicine
pipeworx-io
A
license
Not graded
quality
C
maintenance
Provides access to UniProt protein sequence and function knowledge base, enabling search and retrieval of protein entries, proteomes, taxonomy, and feature annotations.
Updated 11 days ago (2026-08-26 17:31 UTC)
13
MIT
uniprot-mcp
Bioinformatics Biology & Medicine Research & Data
fastmcp-me
A
license
B
quality
D
maintenance
Provides seamless access to UniProtKB protein data, enabling querying of protein entries, sequences, Gene Ontology annotations, and ID mappings through a typed, resilient interface.
Updated 8 months ago (2025-12-22 16:00 UTC)
5
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
-

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/josefdc/Uniprot-MCP'

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