Supernova Cosmology MCP Server

fetch_sn_lightcurve

Download and parse photometric light-curve data for one Type Ia supernova, returning a CSV with MJD, band, flux, and flux error from Pantheon+ or DES-SN5YR datasets.

Instructions

Download and parse raw photometric light-curve data for one SN Ia.

Pantheon+ light curves are individual SNANA .dat files from PantheonPlusSH0ES/DataRelease
(downloaded on demand). DES-SN5YR light curves come from the SALT3 fit LCPLOT file (data +
model columns; 7.4 MB download on first use). Returns a CSV with mjd, band, flux, flux_err
(and mag where available). Use plot_sn_lightcurve to visualise.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "output_dir": "<output_dir>",
      "cid": "<cid>"
    },
    "name": "fetch_sn_lightcurve"
  }
}

Input Schema

Name	Required	Description	Default
`cid`	Yes	SN candidate ID (e.g. '2011fe', '523183', '2254').
`dataset`	No	pantheonplus (SNANA text files, per-SN download) or des5yr (extracted from DES5YR_SALT3_LCFIT.LCPLOT.gz).	pantheonplus
`output_dir`	Yes	Directory for the light-curve CSV(s).

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

A4.1/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 reasonably well: it discloses on-demand network downloads, the 7.4 MB first-use cost for DES-SN5YR, and the exact source files (SNANA .dat vs SALT3 LCPLOT). It omits caching/offline behaviour after the first fetch and error semantics for unknown IDs, so it is not fully transparent.

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 core action, then the two data-source specifics, then the downstream plotting pointer; every sentence is relevant. The dataset provenance sentence partially duplicates the schema enum description, which is the only wasted space.

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 values need not be spelled out, yet the description still names the CSV columns, which is helpful. For a three-parameter download tool this is nearly complete; only failure modes (missing cid, network failure) and post-download caching are unaddressed.

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%, so the schema already explains cid, dataset enum values, and output_dir. The description largely restates that the two dataset names map to SNANA .dat files versus the LCPLOT file, adding only the 7.4 MB first-download detail beyond the schema.

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?

Opens with a specific verb and resource ('Download and parse raw photometric light-curve data') and scopes it to a single SN Ia, which separates it cleanly from plot_sn_lightcurve (rendering) and fetch_sn_salt2_params (fit parameters) among the siblings.

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?

Explicitly routes visualisation to plot_sn_lightcurve and makes clear this is the raw-data acquisition step, giving a clear workflow context. It stops short of stating when to prefer the other data-fetching sibling (fetch_sn_salt2_params) or what happens if the cid is not present.

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