Supernova Cosmology MCP Server

list_sn_datasets

Lists public supernova datasets grouped into catalogs, summary statistics, and published results, helping you pick the right data for analysis or comparison.

Instructions

List the public datasets this server exposes. Call this first.

Products are grouped as catalogs (object-level data), summary statistics (measurements with covariance) and published results (chains / parameter constraints, for comparison only). Build analyses on catalogs and summary statistics. Each entry also gives access (bundled vs downloaded on first use) and which tools read it.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_sn_datasets"
  }
}

Input Schema

Name	Required	Description	Default
`kind`	No	Only datasets offering this kind of product: 'catalog', 'summary_statistic' or 'published_result'. null = all.

Output Schema

Name	Required	Description	Default
`files`	Yes
`status`	Yes
`message`	Yes
`metadata`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

A3.9/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 it does disclose meaningful behavior: entries report whether data is bundled versus downloaded on first use, which warns the agent that some listings may trigger fetching. It also states each entry names the tools that read it. It stops short of saying the call is read-only and side-effect free, or what latency/auth constraints apply, so a small gap remains.

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?

Three short sentences with the primary instruction ('Call this first') front-loaded, followed by the taxonomy and the analysis rule. The parenthetical glosses ('object-level data', 'measurements with covariance', 'chains / parameter constraints') are dense but each carries real disambiguation value; only the line-break formatting keeps it from being maximally tight.

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?

An output schema exists, so return structure need not be re-explained, and the description still usefully previews what each entry contains (access mode, reading tools). For a zero-required-parameter listing tool with no annotations, this is close to complete; only an explicit read-only/no-side-effect statement and the pointer to describe_sn_dataset are missing.

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

Parameters3/5

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

Schema coverage is 100% and the single 'kind' parameter is fully documented in the schema, including its allowed values and null default, so the baseline is 3. The description's taxonomy of catalogs/summary statistics/published results contextualizes why the filter exists but adds no format or edge-case detail beyond the schema.

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 gives a specific verb and resource ('List the public datasets this server exposes') and immediately explains the product taxonomy the listing returns (catalogs, summary statistics, published results). It positions itself as the entry point ('Call this first'), which implicitly separates it from describe_sn_dataset and the analysis tools, but it never names a sibling, so differentiation is contextual rather than explicit.

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?

Clear when-to-use guidance: 'Call this first' plus an explicit usage rule that analyses should be built on catalogs and summary statistics while published results are 'for comparison only'. What is missing is the negative case and the handoff — it does not say to use describe_sn_dataset for full metadata on a single dataset, nor what to do if a dataset is absent.

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