Skip to main content
Glama
Sign In
ImmPort MCP Server

ImmPort MCP Server

Official
by ImmPortDB
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get Study Data

get_study_data

Retrieve any sub-resource (summary, arms, demographics, assays, publications, and more) for one or more ImmPort studies by accession and resource type, including combined multi-study results.

Instructions

Get any sub-resource for one or more ImmPort studies by specifying the resource parameter. All endpoints require authentication. Use study_accession format SDY#### (e.g. SDY1, SDY305).

MULTIPLE STUDIES: study_accession may list up to 20 studies separated by commas (e.g. 'SDY1,SDY269,SDY305') to get one combined result — every row carries studyAccession, so rows can be grouped per study. Studies without data for that resource are simply absent. Prefer one multi-study call over one call per study when comparing studies. Every resource returns a JSON array; 'summary' and 'json_ld' return one entry per study.

⚡ EFFICIENCY RULE: Issue multiple resource calls IN PARALLEL — they are independent. This tool returns structured JSON directly and is the preferred approach for AI agents. Only use Tab.zip (get_study_files action='manifest' → action='download') when you need join tables with no API equivalent: reagent specs, expsample-to-reagent mapping, fcs_header_marker, or expsample-to-treatment joins.

Available resources: summary: ▶ START HERE for any study workflow. Rich summary: title, PI, description, objectives, endpoints, hypothesis, subjects count, interventions, data completeness, publications, personnel, links basic_info: Basic study fields: title, briefDescription, doi, clinicalTrial, enrollment, age range, start/completion dates, sponsoring org arm: Study arms (cohorts/treatment groups): armAccession, name, description, typeReported, typePreferred (e.g. Placebo Comparator, Experimental) planned_visits: Planned visits (time points): plannedVisitAccession, name, orderNumber, minStartDay, maxStartDay, startRule, endRule conditions: Disease/conditions studied: conditionPreferred, conditionReported personnel: Study personnel: personAccession, firstName, lastName, roleInStudy, titleInStudy, organization, email, orcid protocols: Protocol documents: protocolAccession, type, name, description, fileName contract_program: Contract/funding: contractGrantId, contractGrantName, contractGrantCategory, programId, programCategory, programDescription inclusion_exclusion: Inclusion/exclusion eligibility criteria: criterion text and category (Inclusion or Exclusion) pubmed: PubMed publications: pubmedId, doi, authors, title, journal, year, issue. For cross-study publication analysis (e.g. 'top journals'), use search_studies(source_fields=['pubmed.journal']) in bulk instead of looping this per study — see immport://search-fields file: Study document files (case report forms, data dictionaries, protocols): studyFileAccession, studyFileType, description, fileName. NOT for downloadable result files — use files tool for those json_ld: JSON-LD (schema.org Dataset) structured metadata: title, abstract, DOI, creators, funders, health conditions, measurement techniques, citations, data access conditions links: External links: studyLinkId, name, type, value (URL) experiments: Experiments (assay runs): experimentAccession, name, description, measurementTechnique adverse_events: Adverse events: adverseEventAccession, subjectAccession, namePreferred, severityPreferred, outcomePreferred, causality, organOrBodySystemPreferred, startStudyDay, endStudyDay demographic: ⚠️ LARGE — Subject demographics (one row per subject): subjectAccession, armAccession, armName, ageEvent, ageUnit, minSubjectAge, maxSubjectAge, gender (=sex field), race, ethnicity, ancestral_population, species, strain, subjectLocation. For deep analysis use Tab.zip (subject.txt) instead. (⚠️ may be large) biosample: ⚠️ LARGE — Subject→biosample: subjectAccession, biosampleAccession, biosampleName, type, subtype, plannedVisitAccession. For deep analysis use Tab.zip (biosample.txt) instead. (⚠️ may be large) expsample_mapping: ⚠️ LARGE — Full Subject→BioSample→Experiment→ExpSample hierarchy. Prefer get_assay_results for assay data, or Tab.zip (expsample.txt) for the full hierarchy. (⚠️ may be large) interventions: ⚠️ LARGE — Subject-level interventions: compoundNameReported, compoundRole, dose, doseUnits, routeOfAdminPreferred, startDay, endDay, status. For deep analysis use Tab.zip (treatment.txt) instead. (⚠️ may be large) lab_tests: ⚠️ LARGE — Clinical lab test results (CBC, BMP etc): labTestPanelNamePreferred, labTestNamePreferred, resultValuePreferred, resultUnitPreferred, plannedVisitAccession. For deep analysis use Tab.zip or get_assay_results(assay_type='lab_test') instead. (⚠️ may be large) assessment: ⚠️ LARGE — Questionnaires/clinical assessments: assessmentComponentNamePreferred, resultValuePreferred, resultValueCategory, verbatimQuestion, studyDay. For deep analysis use Tab.zip (assessment_component.txt) instead. (⚠️ may be large) immune_exposure: ⚠️ LARGE — Vaccinations/infections/challenges: exposureMaterialPreferred, exposureProcessPreferred, diseasePreferred, diseaseStagePreferred. For deep analysis use Tab.zip (immune_exposure.txt) instead. (⚠️ may be large)

Input Schema

NameRequiredDescriptionDefault
resourceYes
study_accessionYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.4.0

TDQS

A4.9/5.0
Behavior5/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 so: authentication is required for all endpoints, return shape is disclosed (JSON array, one entry per study for summary/json_ld), and missing-study semantics are stated ('Studies without data for that resource are simply absent'). It also flags payload risk with ⚠️ LARGE markers plus a concrete alternative for heavy resources.

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?

The length is justified by 22 enum values and is well structured with headers, bullets, and a front-loaded efficiency rule. Minor waste comes from repeating '(⚠️ may be large)' twice on several lines and restating the same Tab.zip escape hatch per heavy resource.

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?

For a two-parameter but 22-branch tool, the description covers auth, batching, return shape, empty-result behavior, and per-branch alternatives. With an output schema present, it correctly avoids explaining return values and spends its budget on selection guidance instead.

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%, so the description must compensate, and it does: study_accession format is given as SDY#### with examples and a hard cap of 20 comma-separated values with grouping behavior. Every one of the 22 enum values gets a field-level description, which is far beyond what the bare enum in the schema conveys.

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?

The opening sentence states a specific verb and resource ('Get any sub-resource for one or more ImmPort studies') and immediately ties it to the `resource` parameter. It explicitly separates itself from siblings by naming get_assay_results, get_study_files, and Tab.zip as different paths, so an agent can route without opening another 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?

Provides explicit when-to-use ('summary: START HERE for any study workflow'), when-not ('Only use Tab.zip when you need join tables with no API equivalent'), and named alternatives per resource (e.g. pubmed → search_studies with source_fields). It also prescribes call strategy: prefer one multi-study call over per-study loops, and issue resource calls in parallel.

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

Deploy Server

Other Tools