Skip to main content
Glama

search_uniprot_entity

Read-only

Search UniProt proteins using Solr-style queries, filtering by gene, organism, keyword, or sequence length. Returns TSV rows with accession, protein name, and organism.

Instructions

Search for a UniProt entity ID by query.

⚠️ Only the search string and limit are accepted. Extra parameters like taxon, organism, reviewed, species, etc. are silently dropped and have no effect — express such filters inside the Solr query string instead (e.g., organism_id:9606 AND reviewed:true).

⚠️ An unrecognised FIELD NAME inside the query string is not silently ignored: UniProt rejects it (HTTP 400, "'taxon' is not a valid search field") and this tool returns the "Error:" string described below. Common wrong guesses that fail this way: taxon, organism, species, go_id. What CAN fail silently is a valid field given an ill-formed value — it returns 0 rows, or rows you did not expect, with HTTP 200.

The search string can be passed as any of: query (canonical), search, term, keyword, keywords, search_term, or name.

RETURNS a TSV string with columns: accession, protein_name, organism_name. On upstream/HTTP failure this tool does NOT raise — it returns a plain string beginning with "Error:" (not TSV). CHECK FOR the "Error:" prefix BEFORE parsing rows.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
termNo
limitNoThe maximum number of results to return. Default is 20.
queryNoThe Solr-style query string for the UniProtKB /search endpoint. QUERY SYNTAX: - Simple keyword: "rubisco" - Field-specific: "field:value" (e.g., "gene:BRCA1", "protein_name:rubisco") - Boolean operators: AND, OR, NOT (e.g., "gene:TP53 AND organism_id:9606") - Grouping with parentheses: "((gene:CTNNB1) AND (taxonomy_id:9606))" - Wildcards (* suffix): "gene:PRO*" matches any gene starting with PRO - Ranges: "length:[1000 TO 2000]" or open-ended "length:[5000 TO *]" KEY QUERY FIELDS: Identity / Name: accession UniProt primary accession (e.g., "accession:P04637") id UniProt entry name / mnemonic (e.g., "id:P53_HUMAN") protein_name Protein name, including synonyms (e.g., "protein_name:rubisco") gene Gene name with wildcard support (e.g., "gene:BRCA*") gene_exact Exact gene name match (e.g., "gene_exact:TP53") ec Enzyme Commission number (e.g., "ec:1.1.1.1") Taxonomy: organism_id NCBI taxonomy ID (e.g., "organism_id:9606" for human, "organism_id:10090" for mouse) organism_name Organism scientific or common name taxonomy_id Taxon ID including all descendants lineage Taxonomic lineage keyword Annotation status: reviewed true = Swiss-Prot (manually reviewed), false = TrEMBL (automatically annotated) ALWAYS add "reviewed:true" when seeking high-quality entries. Sequence properties: length Sequence length as a range (e.g., "length:[100 TO 500]") mass Molecular mass in Daltons (range supported) existence Protein existence level: 1 (protein), 2 (transcript), 3 (homology), 4 (predicted), 5 (uncertain) Functional annotation: keyword UniProt keyword name (e.g., "keyword:Kinase") keyword_id UniProt keyword ID (e.g., "keyword_id:KW-0418") go Gene Ontology term, by ID or by term name (e.g., "go:0043202", 'go:"lysosomal lumen"'). TWO behaviours to know: (1) the ID must be zero-padded to 7 digits — "go:43202" is a VALID field with an unmatchable value, so it returns 0 rows and no error; (2) the match includes the term's GO DESCENDANTS, so "go:0043202" also returns proteins annotated only to its children (acrosomal lumen, endolysosome lumen) — 192 reviewed entries carry the term directly, 214 once descendants are counted (2026-08-20). function Function free-text annotation family Protein family (e.g., "family:globin") organelle Subcellular organelle (e.g., "organelle:chloroplast") cc_subcellular_location Subcellular location comment Cross-references: database Database cross-reference (e.g., "database:PDB") xref Cross-reference ID (e.g., "xref:pdb-1A2B") chebi ChEBI ID (e.g., "chebi:15422") interactor UniProt accession of interacting protein Literature: lit_author Author surname (e.g., "lit_author:Smith") lit_pubmed PubMed ID lit_doi DOI EXAMPLES (structured queries): # Reviewed human TP53 protein "gene_exact:TP53 AND organism_id:9606 AND reviewed:true" # All human kinases manually reviewed "keyword:Kinase AND organism_id:9606 AND reviewed:true" # EGFR in human or mouse "gene_exact:EGFR AND (organism_id:9606 OR organism_id:10090) AND reviewed:true" # Long chloroplast proteins (>= 5000 aa) in any organism "organelle:chloroplast AND length:[5000 TO *]" # Proteins with PDB structures involved in apoptosis "database:PDB AND keyword:Apoptosis AND organism_id:9606 AND reviewed:true" # Proteins encoded by gene names starting with "PIK3" "gene:PIK3* AND organism_id:9606 AND reviewed:true"
searchNo
keywordNo
keywordsNo
search_termNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

This is unusually transparent: it discloses silent dropping of extra parameters, HTTP 400 on invalid field names, silent 0-row or unexpected results for ill-formed values, the exact TSV column layout, and the 'Error:' prefix on upstream failure. These details go far beyond the readOnly/openWorld annotations and contain no contradiction.

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 longer than average, but every sentence earns its place: accepted parameters, failure modes, alias names, return format, and the required error-prefix check. It is front-loaded with the core purpose and uses structured warnings rather than padding.

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?

It covers return format, failure behavior, accepted parameter aliases, and query-field constraints, which combined with the rich query syntax in the schema makes it largely complete. Minor gaps remain, such as what happens with an empty query and any pagination behavior beyond the schema's default limit.

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 only 25% schema coverage, the description compensates by enumerating all accepted aliases (query, search, term, keyword, keywords, search_term, name) and clarifying that extra parameter names are ignored. The query parameter's syntax is already extensively documented in the schema, so the description does not need to repeat it.

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 opens with 'Search for a UniProt entity ID by query,' clearly naming the action and resource, and the subsequent details about Solr queries and TSV output clarify the scope. It distinguishes the tool from sibling search_* tools by resource, though 'entity ID' is slightly imprecise because the tool returns TSV rows rather than a single ID.

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 gives clear context: use it for UniProt queries, express filters inside the Solr query string, and only the search string and limit are accepted. It explicitly warns against extra parameters like taxon/organism/reviewed, but it does not directly compare this tool to sibling search tools.

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

Install Server

Other Tools

Latest Blog Posts

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/dbcls/togomcp'

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