plant-genomics-mcp

Overview Schema Source Related Servers Discussions Admin

UniProt: ID Mapping (batch, every entry)

uniprot_id_mapping

Read-onlyIdempotent

Maps up to 500 plant gene, transcript, or protein IDs per batch to every UniProtKB accession returned, preserving all mappings instead of one locus hit.

Instructions

Map a batch of gene, transcript or protein IDs to EVERY UniProtKB entry UniProt's own ID mapping service returns, one job for the whole batch. Use it when a question asks for all accessions, or for many IDs at once: resolve_locus_to_uniprot returns one entry per locus (its best search hit), so a gene with several entries loses the rest. from_db names the IDs' source as UniProt does: Ensembl_Genomes for plant gene IDs such as maize Zm00001eb, rice Os01g, wheat TraesCS (the default), Ensembl_Genomes_Transcript, Ensembl_Genomes_Protein, or Araport for Arabidopsis AGIs. Each ID comes back mapped (accessions, each with entry_type and reviewed) or unmapped (UniProt lists it as failed: it maps to no entry). Up to 500 IDs per call; duplicates are collapsed. upstream_version is the UniProt release. Maize RefGen_v4 IDs (Zm00001d) are not in UniProt: translate them first with maize_gene_model_translation.

Input Schema

Name	Required	Description	Default
`ids`	Yes	IDs from from_db, e.g. ['Zm00001eb326750', 'Zm00001eb181120']
`from_db`	No	UniProt's name for the IDs' source database	Ensembl_Genomes

Output Schema

Name	Required	Description
`count`	Yes	Distinct IDs queried (duplicates collapsed)
`to_db`	Yes	Always UniProtKB
`mapped`	Yes	Results with status mapped
`from_db`	Yes	UniProt's name for the source database
`results`	Yes
`unmapped`	Yes	Results with status unmapped
`obsolete_count`	Yes	UniProt's obsoleteCount for the job: mapped entries now obsolete
`upstream_version`	No	UniProt release that produced THIS response, as stated by the x-uniprot-release header. null means UniProt did not state one — never that no release exists, and never inferred from a separate metadata call, which can describe a different release than the one that answered.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.30.0Oct 29, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent safety, but the description adds behavior beyond them: a 500-ID cap, duplicate collapsing, job-per-batch semantics, the mapped/unmapped outcome split with the meaning of 'failed', and what upstream_version represents. This is exactly the context annotations cannot carry.

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?

Front-loaded with purpose and the sibling contrast before the ID-source detail. It is a dense single block, though every clause carries distinct operational value; slight trimming of the organism examples would improve scanability.

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?

An output schema exists, and the description still sketches the return shape (accessions with entry_type and reviewed, vs. unmapped). Given two parameters and a batch, read-only tool, nothing needed to call it correctly is missing.

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

Parameters5/5

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

Schema coverage is 100% (baseline 3), and the description still adds real meaning: it translates each from_db enum value into the organism/ID convention it corresponds to (maize Zm00001eb, rice Os01g, wheat TraesCS, Arabidopsis AGIs) and flags which is the default. That is information present in neither the enum list nor the parameter descriptions.

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?

States a specific verb and resource ('Map a batch of gene, transcript or protein IDs to EVERY UniProtKB entry') and adds the distinguishing scope ('one job for the whole batch'). It explicitly contrasts with resolve_locus_to_uniprot, so an agent can pick between the two without opening a schema.

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

Usage Guidelines5/5

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

Gives an explicit use condition ('when a question asks for all accessions, or for many IDs at once') and names the alternative it replaces, explaining the failure mode of the alternative ('a gene with several entries loses the rest'). It also routes a related edge case to maize_gene_model_translation.

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

Deploy Server