{"answer": "This is an MCP server that lets you discover and understand 5,000+ curated public scientific data archives across all domains — no API keys or downloads required, read-only access over stdio or HTTP.\n\n- Search archives (search_archives): Natural-language queries across the full catalog (e.g., "single-cell RNA-seq of human cortex"), with optional category filtering and result limits. Returns ranked matches with IDs, titles, categories, and summaries.\n- Get archive metadata (get_archive): Full metadata for a specific archive by ID, including whether a schema card exists.\n- Inspect structure (get_schema_card): Compact schema card with file format, column definitions, sample rows/headers, sidecar docs (READMEs/data dictionaries), and a copy-paste starter code cell — all without downloading.\n- Browse files (list_archive_files): Sample of files/objects in storage (up to 200), to see what's physically in the archive.\n- Get data access (get_data_access): Storage location plus copy-paste code snippets filterable by language (datasets, s3fs, gcsfs, etc.).\n- Guided prompts: explore_dataset(topic) walks search → schema cards → recommendation → load code; start_analysis(archive_id, goal?) pulls schema + access snippet and outlines an analysis plan. Available as slash commands in supported clients like Claude Code."}
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@scigantic-mcp find public RNA-seq datasets on human cancer and show their schema cards"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server that exposes the Scigantic catalog of public scientific data archives to any MCP client.
It is built to drop into Kiro for Life Sciences alongside its domain database servers. Where each Kiro server wraps one domain's APIs (genomics, proteomics, structural, …), Scigantic is the cross-domain launchpad: 5,000+ curated public archives spanning every domain, each with an LLM-ready schema card (file format, columns, sample rows/headers, inlined READMEs/data dictionaries, and a copy-paste starter cell) so an agent can understand a dataset's structure before downloading anything.
It is discovery-only and zero-config — every tool calls public, read-only Scigantic endpoints, so there is no API key to set up.
Requires Python 3.10+ and MCP SDK 2.x.
Prefer the hosted server if your client speaks HTTP. Scigantic also runs a remote MCP server at
https://api.scigantic.com/mcp(no auth, nothing to install, and it carries two extra tools):claude mcp add --transport http scigantic https://api.scigantic.com/mcp. This package exists for clients that launch stdio servers, such as Kiro.
Tool | What it does |
| Natural-language search across the whole catalog. |
| Full metadata for one archive. |
| The compact schema card — the fastest way to learn a dataset's structure. |
| How to load the dataset in your own environment: storage location + copy-paste code snippets. |
| A sample of the files/objects in the archive. |
Related MCP server: EasyPeasyMCP
These surface as slash commands in Claude Code (/mcp__scigantic__<name>):
Prompt | What it does |
| Search → inspect schema cards → recommend the best dataset → offer load code. |
| Pull schema card + data-access snippet for an archive and outline an analysis plan. |
Add an entry under mcpServers in ~/.kiro/settings/mcp.json.
Option A — uvx (zero-install, recommended):
{
"mcpServers": {
"scigantic": {
"command": "uvx",
"args": ["scigantic-mcp"]
}
}
}Option B — install into a venv (matches the Kiro servers' own mcp.json form):
python3 -m venv .venv && . .venv/bin/activate
pip install scigantic-mcp # or: pip install /path/to/scigantic-mcp{
"mcpServers": {
"scigantic": {
"command": "/path/to/.venv/bin/scigantic-mcp",
"env": {
"SCIGANTIC_API_URL": "https://api.scigantic.com"
}
}
}
}Works the same in Claude Desktop / Claude Code (claude mcp add scigantic -- uvx scigantic-mcp)
or any MCP client that launches stdio servers.
Env var | Default | Purpose |
|
| API base (set to |
|
| Origin header → selects the public (default) catalog tenant. |
This package is a thin client over the public Scigantic REST API. That API is not versioned and may change without notice — if a response shape moves, a pinned older release of this package can break. Pin a version you have tested, and open an issue if a tool starts returning something unexpected.
The MCP tool names and their arguments are treated as the stable surface, and will not change without a minor version bump.
The tool/client layer has no mcp dependency, so those tests run on any Python
with httpx and need no network (mocked transport):
python3 tests/test_tools.py # or: pytesttests/test_server_import.py covers the wiring layer — that the server module
imports, and that the registered tools and prompts are the expected set. It needs
the mcp SDK installed (Python ≥ 3.10) and is skipped otherwise:
pip install -e '.[test]' && pytestKeep it that way: the tool tests skip server.py on purpose, so an SDK breaking
change is invisible to them. All 12 passed while the server could not import at
all under SDK 2.x, which is what test_server_import.py now guards against.
Richer discovery for agents — structured tool outputs and MCP resources (attach an archive + its schema card as durable context).
Upstream inclusion as life-sciences-scigantic in
aws-samples/sample-kiro-power-life-sciences.
Hosted compute is intentionally not exposed here. Scigantic's notebooks are
interactive (a JupyterLab URL a human opens); handing an external agent that URL
is a dead end. The agent-to-agent path is get_data_access — the caller runs the
analysis in its own environment. Letting Scigantic execute code for an agent
(run against an ephemeral kernel with the dataset mounted, return outputs) is a
separate capability the platform would need to build first.
MIT-0.
Get full metadata for one archive by id, including whether a schema card exists.
Args: id: Archive id from search_archives.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says it returns 'full metadata' and notes schema card existence, but doesn't disclose the return format despite an output schema existing, doesn't describe failure modes (nonexistent id), read-only nature, or access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (two sentences plus an Args section). It's appropriately sized for a single-parameter retrieval tool. Minor inefficiency: 'Args' section slightly redundant given the one parameter, but the sourcing hint justifies it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-param tool, it's fairly complete. An output schema exists, so return format is covered there. Gaps: no guidance on alternatives among siblings, no mention of error handling for invalid ids, and no explicit read-only disclosure (though annotations are absent). Reasonable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the single parameter 'id' is 'Archive id from search_archives', which tells the agent exactly where to source the value — meaningful semantic context beyond the bare property name 'Id' in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description has a specific verb+resource ('Get full metadata for one archive by id') and distinguishes itself by specifying the scope (single archive by id, includes schema card existence). It's clear this is an individual-item retrieval tool, distinct from search_archives which lists/filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is 'id: Archive id from search_archives' which indicates where ids come from. There's no guidance on when to use this vs. get_schema_card, list_archive_files, or get_data_access, no stated alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get how to load a dataset in YOUR OWN environment: storage location plus copy-paste code snippets (from the dataset's schema card, or generated as a fallback).
Use this after finding a dataset when you want to run analysis where you are, rather than in a hosted notebook.
Args: id: Archive id from search_archives. language: Optional filter for the snippet language (e.g. "datasets", "s3fs", "gcsfs").
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| language | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description mentions a fallback behavior ('or generated as a fallback') when no schema card snippet exists, which is useful. However, it doesn't disclose what the output structure looks like, whether network calls are made for snippet generation, potential failure modes for invalid archive ids, or rate limit behavior. For a read tool with no annotations, more transparency about the output/return value would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized—a clear opening sentence, a usage context sentence, and parameter explanations. No wasted words, everything earns its place. Minor deduction for not being front-loaded with the most critical behavior in the very first sentence, though the first sentence is quite informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (which covers return value explanation), 2 params, and moderate complexity. The description covers purpose, usage timing, and parameter semantics. The fallback behavior is disclosed. It's reasonably complete for a read-oriented access-tool. Slight deduction because the language parameter's accepted values aren't exhaustively listed and there's no mention of what happens if the archive id is invalid or if snippets are unavailable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does: 'id' is explained as 'Archive id from search_archives,' clarifying the data source, and 'language' is described as 'Optional filter for the snippet language' with examples. Since there is no output schema coverage and no enums constraining language values, the examples ('datasets', 's3fs', 'gcsfs') add meaningful value beyond the minimal schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: retrieves storage location and copy-paste code snippets for loading a dataset in one's own environment. The resource is clearly identified (dataset access), and the context—where to run analysis versus hosted notebook—adds specificity. It distinguishes from siblings like get_schema_card and list_archive_files by focusing on loading data locally.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use this after finding a dataset when you want to run analysis where you are, rather than in a hosted notebook.' This clearly indicates when to use it. It doesn't explicitly name alternative tools or exclude other scenarios, which keeps it from a 5, but the context is strong and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the compact schema card for an archive: file format, columns, sample rows/headers, sidecar docs (READMEs/data dictionaries) and a copy-paste starter cell.
This is the fastest way to understand a dataset's structure without downloading it.
Args: id: Archive id from search_archives.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. The description does disclose what the tool returns (a compact card with specific components). However, it doesn't mention the id source (tells you to use search_archives id) or any caching/side effects. Since this is a read-only inspection tool, the risk profile is low, and the return content is well specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact and front-loaded. The first line states the core purpose and content list. The usage context is one sentence. Args section is minimal. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Has an output schema and only 1 parameter. The description fully covers the parameter sourcing (from search_archives), the content of the result, and the use case. For a simple inspection tool, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the single 'id' parameter. It does, by explaining that the id comes from search_archives, which gives meaningful provenance. Even though the schema has 100% of the single parameter documented in structure, the description adds sourcing semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: 'Get the compact schema card for an archive' with detailed content enumeration (format, columns, sample rows/headers, sidecar docs, copy-paste starter cell). Clearly distinguishes from search_archives (searching) and get_archive/list_archive_files (retrieval/listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use case: 'This is the fastest way to understand a dataset's structure without downloading it.' This provides clear context for when to prefer this tool. It doesn't explicitly name alternative tools for exclusion, but the context (fastest way to understand structure) signals when it applies and the siblings are understandable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a sample of the files/objects in an archive's storage.
Args: id: Archive id from search_archives. limit: Max entries (default 50, max 200).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It honestly discloses this is a 'sample' of files rather than a complete listing, which is valuable behavioral context. However, it doesn't mention potential read safety implications, permission needs, or rate limits—though it's clearly a read operation given 'list' semantics and preview behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences plus a compact docstring with Args. Efficient and front-loaded with the core purpose. The only minor waste is restating parameter info that also appears in the schema (limit default), but overall it's lean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the has-output-schema flag is true (relieving the description of explaining return values) and only 2 params, the description is reasonably complete. The 'sample' disclosure for a listing tool is appropriate. But with no annotations and no explicit workflow guidance connecting it to siblings, there's room to add more about how it composes with get_archive or search_archives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does explain 'id' as 'Archive id from search_archives' and 'limit' with default/max values, which adds meaning beyond the bare schema. However, it doesn't clarify what the limit units are or format expectations for id beyond the pointer to search_archives.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource purpose: 'List a sample of the files/objects in an archive's storage.' This distinguishes it from siblings like search_archives and get_archive by specifying it lists files within a single archive rather than searching across archives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says id comes from search_archives, providing a useful prerequisite for sourcing the id. However, it doesn't explicitly state when to use this vs get_archive or get_schema_card, or any exclusions. The context implies it complements get_archive (which likely returns archive metadata) but doesn't say so.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Scigantic catalog of public scientific data archives by natural-language query.
Returns ranked matches with id, title, category and a short summary across all domains. Follow up with get_schema_card to understand a match's structure.
Args: query: Natural-language search, e.g. "single-cell RNA-seq of human cortex". category: Optional category filter, e.g. "Genomics & Bioinformatics" (comma-separate for several). limit: Max results (default 10, max 50).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| category | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses what results contain (id, title, category, short summary), that there's a category filter, and the limit default (10) and max (50). This is reasonably transparent behavior for a read/search operation. It doesn't describe pagination or error behavior, but for a search tool this covers the essential behavioral surface.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a brief purpose statement, a clear return-value note, a follow-up recommendation, and compact Args documentation. Every sentence earns its place — no fluff. The format is scannable with clear section breaks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description explains what a search returns and how to follow up. For a search tool with 3 parameters (1 required), plus an output schema, plus a sibling chain to drill into results, this is complete. The follow-up recommendation to get_schema_card completes the workflow story.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does explain each parameter in the Args section: query is a natural-language search with a concrete example, category is an optional filter with an example and comma-separate guidance, and limit is documented with default and max. This adds real value beyond the bare schema, though the category value format ('Genomics & Bioinformatics') is somewhat ambiguous as to whether it's an exact match or fuzzy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource+scope: 'Search the Scigantic catalog of public scientific data archives by natural-language query.' It states what is searched (catalog of public scientific data archives), the method (natural-language query), and explicitly notes returns 'across all domains,' distinguishing from siblings like get_archive and list_archive_files which target specific archives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States when to use it (to search the catalog by natural language) and gives a clear follow-up path (get_schema_card to understand a match's structure), which implicitly distinguishes it from the archive-specific sibling tools. It doesn't explicitly say when NOT to use it, but the follow-up recommendation and description of returning ranked matches across all domains provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_archiveget_data_accessget_schema_cardlist_archive_filessearch_archivesMost tools are clearly distinct: search returns matches, get_archive fetches full metadata, get_schema_card explains structure, list_archive_files samples files, get_data_access provides load code. However, get_archive and get_schema_card overlap somewhat since both retrieve metadata about an archive, and list_archive_files could be confused with get_schema_card's file/column info. Descriptions mostly clarify boundaries.
All use snake_case with verb_noun structure, but verbs are mixed in style: 'search_archives' and 'get_archive' share the archives noun base, while 'get_schema_card', 'list_archive_files', and 'get_data_access' diverge to different nouns. Each tool combines get/search/list with a distinct noun, but the noun targeting is inconsistent (archives vs schema_card vs archive_files vs data_access).
Five tools is well-scoped for a scientific data catalog server. Each tool has a clear purpose: discovery (search), metadata (get_archive), structure (get_schema_card), file listing (list_archive_files), and access guidance (get_data_access). Together they cover a complete discovery-to-access workflow without redundancy.
The workflow is well covered: search to find datasets, get_archive for metadata, get_schema_card for structure, list_archive_files for contents, and get_data_access for loading. Minor gaps exist, such as no tool to filter/sort search results more granularly, no preview/download of actual data contents, and get_archive is somewhat redundant given get_schema_card. But core discovery and access needs are met.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for live public-data APIs and Skills for AI agents.
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
Read-only MCP server over the APIs.io catalog — discover APIs, providers, tags & artifacts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Scigantic/scigantic-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
