Uniprot MCP

What smaniches/uniprot-mcp MCP server does

The smaniches/uniprot-mcp MCP server gives an MCP client structured access to UniProtKB, UniRef, UniParc, controlled vocabularies, and selected linked scientific databases. Its catalog covers 41 tools for finding entries, retrieving records, examining sequences and annotations, resolving cross-references, and assembling evidence for protein, drug-target, and clinical workflows.

Entry-oriented tools can search by gene, organism, keyword, or free text, then retrieve a record by accession. Other tools return FASTA sequences, computed sequence properties, Gene Ontology terms, subcellular locations, keywords, publications, domains, binding sites, active sites, processing features, and post-translational modifications. Variant workflows include complete natural-variant lists, residue-position lookups, disease associations, ClinVar resolution, and identifier mapping.

The server also supports structural and comparative work. It can resolve PDB, AlphaFold, InterPro, ChEMBL, and orthology references; retrieve AlphaFold confidence summaries; search or fetch UniRef clusters; and retrieve UniParc sequence-archive records. A target-dossier tool combines several entry-level views into one response for initial drug-discovery or clinical review.

How it works

The server is launched as a local MCP process and makes requests to upstream services as needed. Most data comes from the UniProt REST API. ClinVar lookups use NCBI eutils, while AlphaFold confidence requests use AlphaFoldDB; these external calls are identified in the supplied documentation.

Successful responses record the UniProt release, retrieval timestamp, resolved source URL, and a SHA-256 digest. The provenance verification tool can re-fetch a source and compare its release and canonicalized response hash, allowing a user to check whether the upstream record has changed. The hash is calculated from canonical JSON rather than raw response bytes, so key ordering does not affect verification.

The optional cache is controlled by UNIPROT_MCP_CACHE_DIR. When configured, uniprot_replay_from_cache reads a previously stored response and its provenance without making an upstream request. With the variable unset, replay reports that caching is disabled. This supports repeatable offline analysis or work in an air-gapped environment when a cache snapshot is available.

Setup and configuration

Run the project directly with:

uvx uniprot-mcp-server

It can also be installed into an existing Python environment:

pip install uniprot-mcp-server

The project requires Python 3.11 or newer according to its repository metadata. Use the package name uniprot-mcp-server; the documentation warns that a different PyPI package named uniprot-mcp is unrelated. Set UNIPROT_MCP_CACHE_DIR only when local provenance caching and replay are needed. No API key or other credential is specified for the server itself.

Tools and capabilities

Representative capabilities include:

• Search UniProt entries and fetch one or many accessions.
• Retrieve canonical FASTA sequences and calculate molecular weight, pI, hydrophobicity, charge, extinction coefficient, and composition.
• Inspect GO annotations, features, PTMs, processing regions, active sites, cross-references, publications, diseases, and variants.
• Map identifiers across UniProt and external databases.
• Resolve ClinVar, PDB, AlphaFold, InterPro, ChEMBL, and orthology information where supported.
• Search controlled keyword, subcellular-location, UniRef, UniParc, and taxonomy records.
• Build a target dossier, verify provenance, and replay cached responses.

Limitations and notes

A missing UniProt natural-variant result does not establish that a variant is benign; the supplied documentation distinguishes literature-curated UniProt annotations from population-scale clinical data in ClinVar. Likewise, an empty disease-association result does not prove that a protein lacks disease relevance.

Some operations can take longer than a simple entry lookup. Identifier mapping submits an asynchronous job and polls it to completion, particularly for larger batches. The target dossier still depends on upstream data, despite combining several views into one call. Offline replay requires a previously populated cache and does not fetch current records.

The server's evidence is release- and retrieval-dependent. Verification checks whether the referenced upstream representation and release still match; it does not replace scientific assessment of the underlying annotation.