ImmPort MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Get Release Notes

get_release_notes

Retrieve ImmPort data release notes, release histories, and study release status to see which releases exist, what each contains, and when or why a study was released or updated.

Instructions

ImmPort data releases and the release history of studies. Data releases are named DR (e.g. DR69, DR58, point releases like DR52.1); version also accepts 58 or dr58. Requires authentication.

Modes (chosen by which arguments are given): • study_accession only → each study's release history, newest first: [{studyAccession, briefTitle, releases: [{version, releaseDate, status, releaseNotes}]}]. status is 'Initial' (first released) or 'Updated'. releaseNotes is often null for older releases. study_accession may list up to 20 studies separated by commas. • study_accession + version='DR58' → only that release's entry for each study (404 if the study was not in that release). • study_accession + version='latest' → each study's OWN most recent release (e.g. SDY1 → DR58, even if the current release is DR69). • version only (e.g. 'DR69', or 'latest' for the newest release) → the release notes document the data release process published for that release, as is: release_version, release_date, study.studies[] (study_accession, brief_title, description, status, subjects, personnel, publications, assays, programs, release_notes on recent releases) and dataSummary (totals at that release). ⚠️ Large: 100–700 KB. 404 if its notes are not published yet. • neither → list of all data releases, newest first: [{version, releaseDate, initialStudyCount, updatedStudyCount}].

Examples: get_release_notes() # which releases exist get_release_notes(version='latest') # what's in the newest release get_release_notes(study_accession='SDY1') # when was SDY1 released/updated, and why get_release_notes(study_accession='SDY1,SDY269', version='latest')

Input Schema

Name	Required	Description	Default
`version`	No
`study_accession`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.4.0Nov 5, 2026

TDQS

A4.7/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the authentication requirement, 404 conditions (study not in that release, notes not yet published), result ordering (newest first), null releaseNotes for older releases, the 20-study comma-separated cap, and a warning that release-document mode returns 100–700 KB. It does not discuss rate limits, caching, or pagination, which keeps it short of a 5.

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 the resource definition and authentication prerequisite, then organized into a mode bullet list and a worked-examples block, which is efficient for a two-parameter tool with five behavioral modes. It is somewhat long, and the examples partially restate the mode bullet points, but each section still contributes distinct calling information.

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?

A companion output schema exists, yet the per-mode return shapes differ enough that restating them in the description adds real value. Combined with authentication, size warning, ordering, and 404 semantics, an agent has everything needed to pick a mode, build the arguments, and interpret the response.

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 0% and both parameters are bare strings with defaults, so the description must compensate — and it does: version accepts DR<number>, point releases like DR52.1, bare numbers such as 58 or dr58, and the literal 'latest', while study_accession accepts a comma-separated list of up to 20 accessions. The interaction between the two parameters is fully specified.

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 resource (ImmPort data releases and per-study release history) and enumerates the distinct result shapes the tool can produce. The mode enumeration makes it clearly distinguishable from siblings like get_study_data or get_study_data_availability.

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?

Explicitly explains that the operating mode is selected by which arguments are supplied, lists all five mode combinations with their resulting semantics, and closes with four concrete call examples mapping intent to invocation. The only minor gap is it doesn't explicitly name sibling tools to prefer for study-level data retrieval.

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

Deploy Server