The spedas-mcp server provides 40 MCP tools for agentic heliophysics and planetary science workflows, covering data discovery, retrieval, geometry computation, and analysis across major space science archives.
Science Workflow & Planning
spedas_overview() — Compact map of all capabilities and recommended workflows
search_spedas_data_sources() — Recommend the right data source family (CDAWeb, PDS, SPICE) for a science question
plan_spedas_observation() — Generate a source-specific data plan before fetching
compare_cdaweb_pds_spice() — Clarify boundaries between CDAWeb, PDS, and SPICE for a given goal
create_spedas_analysis_bundle() — Create a structured directory scaffold (requests/, data/, plots/, provenance/, notes/) for a study
Unified Data Layer
browse_data_sources() / load_data_source() / browse_data_parameters() / fetch_data_product() — Unified browse and fetch across CDAWeb, PDS, SPICE, HAPI, and FDSN
Source-specific tools for CDAWeb (browse_observatories, load_observatory, browse_parameters, fetch_data) and PDS (browse_pds_missions, load_pds_mission, browse_pds_parameters, fetch_pds_data)
Cache management: manage_data_cache(), manage_cdaweb_cache(), manage_pds_cache()
SPICE Geometry & Ephemeris
list_spice_missions() — List supported spacecraft/bodies with NAIF IDs
get_ephemeris() — Position/velocity for targets over a time range
compute_distance() — Distance between two SPICE bodies over time
transform_coordinates() — Transform 3D vectors between coordinate frames
list_coordinate_frames() — List supported frames and usage notes
manage_spice_kernels() — Load, check, clean, or purge SPICE kernels
Optional Analysis Tools (spedas-mcp[analysis])
Coordinate transforms: transform_timeseries_coordinates(), generate_fac_matrix(), analyze_minvar_coordinates()
Time-frequency analysis: dynamic_power_spectrum(), wavelet_transform()
Magnetic field models: evaluate_magnetic_field() (IGRF, T89/T96/T01/TS04), calculate_lshell()
Particle science: compute_particle_moments() (density, velocity, temperature), compute_particle_spectra() (energy/pitch-angle spectrograms)
Rendering: render_tplot() — Render line plots and spectrograms to PNG
Optional External Backends
HAPI ([hapi] extra): browse_hapi_catalog(), fetch_hapi_data() — Access any HAPI-compliant server
FDSN/MTH5 ([fdsn] extra): browse_fdsn_datasets(), fetch_fdsn_data() — EarthScope magnetotelluric data
All bulk data is written to disk; tools return file paths and compact summaries rather than raw arrays.
Provides tools for discovering, fetching, and analyzing NASA heliophysics data from CDAWeb, PDS, and SPICE, enabling AI agents to perform space physics research workflows.
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., "@spedas-mcp Show me the available CDAWeb observatories"
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.
spedas_agent_kit is the SPEDAS organization MCP server for agentic heliophysics workflows. It presents one SPEDAS-facing data layer and organizes capabilities by data source category instead of by the internal backend packages used to implement them.
The current design follows Jason's A+B direction:
A. SPEDAS data layer — one unified entry point for source categories such as cdaweb, pds, and spice/geometry.
B. SPEDAS science workflow layer — high-level planning tools that let Claude Code, Codex, OpenCode, LingTai, or another agent start from a science question before choosing source-specific operations.
Implementation backend packages should stay visible to maintainers, but they should not be the user's first mental model.
Official repo: https://github.com/spedas/spedas_agent_kit
Python package name: spedas-agent-kit
Python module / CLI module: spedas_agent_kit
Canonical shared skills: src/spedas_agent_kit/resources/skills/ (packaged with the kit; wrappers should stay thin)
Default MCP tool count: 13 (legacy CDAWeb/PDS compatibility tools are conditionally registered); advertised tools carry MCP ToolAnnotations plus meta.surface (primary or compat) so launchers can filter by surface and side-effect hints.
Related MCP server: space-mcp-server
Use this section as the README-level operating guide for researchers and agents. The detailed capability map below is the reference; this guide is the shortest safe path from a science question to reproducible artifacts.
Restate the science question and constraints. Capture the target, mission, instrument or observable, time range, and whether the request is heliophysics, planetary, geometry-only, or analysis oriented.
Ask SPEDAS Agent Kit to choose the data-source family before fetching data. Start
with spedas_overview(), then call search_spedas_data_sources(...) or
plan_spedas_observation(...). Do not jump directly to a low-level archive
tool just because a mission name matched a backend.
Create a run directory. For work that may fetch, transform, render, or be
cited later, call create_spedas_analysis_bundle(...) first and keep data,
plots, provenance, and notes under that bundle.
Browse narrowly, then fetch narrowly. Use the data-layer tools to browse source categories and parameters. Keep public-archive requests to small, reproducible intervals and explicit parameters.
Use geometry as a follow-on step. SPICE geometry, ephemeris, and frame transforms consume explicit files/artifacts. They should not hide large downloads or return bulk arrays inline.
Return paths, provenance, and caveats. A good answer names the source, dataset/product, variables, time window, output files, validation/caveats, and the next reproducible command. It does not paste CDF contents or giant arrays into chat.
User request pattern | Lead with | Then use | Common caveat |
Near-Earth magnetosphere, solar wind, MMS, THEMIS, Cluster, Geotail, Van Allen / RBSP, STEREO, PSP, Solar Orbiter, Ulysses, Voyager heliosphere |
| CDAWeb browse/load/fetch tools; SPICE only if geometry is part of the question | Mission names may also appear in planetary archives; keep the science context in the plan. |
Planetary mission fields/particles at a planet, e.g. Juno/Jupiter, Cassini/Saturn, MAVEN/Mars, New Horizons/Pluto |
| PDS discovery/fetch, plus SPICE geometry when trajectory or observation geometry matters | Generic words like "bow shock", "magnetosphere", "plasma", or "energetic particle" are not enough to choose CDAWeb if the target is planetary. |
Ephemeris, distance, trajectory, frame transforms, observer-target geometry |
| Browse missions/frames with | SPICE is geometry, not measurement data. Pair it with CDAWeb/PDS when you also need fields or particles. |
For an open-ended question, the safe skeleton is:
spedas_overview()
search_spedas_data_sources(question="...", target="...", observables=[...])
plan_spedas_observation(science_goal="...", start="...", stop="...", target="...", observables=[...])
create_spedas_analysis_bundle(study_name="...", output_dir="...")
browse_data_sources(source_type="cdaweb|pds|spice")
load_data_source(source_type="...", source_id="...")
browse_data_parameters(source_type="...", dataset_id="...")
fetch_data_product(source_type="...", dataset_id="...", parameters=[...], start="...", stop="...", output_dir="...")Add geometry only when the plan calls for it:
get_ephemeris(...)
compute_distance(...)
transform_coordinates(...)PSP perihelion solar wind: route the science question first, let CDAWeb lead
measurement discovery, then add SPICE only for spacecraft-Sun geometry. See
docs/examples/psp_perihelion_solar_wind.md.
MMS magnetopause interval: use plan_spedas_observation to keep mission,
observable, and interval explicit; fetch selected CDAWeb variables into an
analysis bundle before plotting or transforming. See
docs/examples/mms_magnetopause_workflow.md.
Juno / planetary plasma interactions: let PDS lead MAG/plasma archive
discovery and use SPICE as a geometry companion. See
docs/examples/juno_pds_spice_workflow.md.
Overview + geomagnetic-index context: for IDL-SPEDAS-style summary plots
or Dst/AE/Kp/SYM-H context, load the Claude skill
overview-geomagnetic-indices and use spedas_overview()["guided_recipes"]
to map the intent to CDAWeb/HAPI OMNI datasets or PySPEDAS Kyoto/NOAA loaders.
Every non-trivial run should leave a directory that another researcher can audit:
<run>/
requests/ original prompt, plan, or recipe
data/ fetched or prepared measurement files
plots/ PNG/SVG/PDF renderings
provenance/ source IDs, parameters, cache notes, tool versions, hashes
notes/ interpretation, caveats, and next stepsWhen reporting results, include at least:
science goal and time range;
selected source family (cdaweb, pds, or spice);
dataset/product IDs and parameters/variables;
output files and hashes when available;
dependency or data-access caveats (missing_dependency, archive rate limits,
cache-only validation, unavailable kernels, no matching station, etc.);
the next command or MCP call needed to reproduce or extend the run.
Prefer the unified data-layer and science-workflow tools over compatibility low-level tools for new work.
Do not infer a source from one keyword. Use target + mission + observable + time context, especially for planetary versus near-Earth uses of generic words such as "magnetosphere", "bow shock", "radiation belt", "solar wind", and "energetic particle".
Keep fetches narrow. Public archives can rate-limit or be cold; long intervals should be split deliberately and recorded in provenance.
The base install exposes the bundled CDAWeb/PDS/SPICE surface only; the optional
analysis, hapi, and fdsn extras (and their tools) were removed in the
one-MCP cleanup.
Validate generated artifacts before interpreting them. Check file existence, row/sample counts, time coverage, coordinate frame, and whether the tool returned warnings or caveats.
Start here when the user asks for data, datasets, parameters, products, archives, or cache status.
browse_data_sources(source_type="all", query=None) — browse SPEDAS data source categories, or drill into one category.
load_data_source(source_type, source_id, mode="compact", limit=None, offset=0, instrument=None, dataset_query=None, include_full_prompt=False) — load source context. CDAWeb observatories default to a compact structured dataset page (dataset IDs, instruments, coverage, next calls); use limit/offset and filters for large catalogs, or mode="full" / include_full_prompt=True for the legacy full prompt.
browse_data_parameters(source_type, dataset_id, dataset_ids=None) — browse parameters/metadata for CDAWeb or PDS datasets; for SPICE, returns geometry/frame context.
fetch_data_product(source_type, dataset_id, parameters, start=None, stop=None, output_dir=None, format="csv", limit=None) — unified measurement/archive data fetch for CDAWeb/PDS. SPICE requests are routed to geometry tools instead. limit is currently a CDAWeb-oriented safety control; PDS fetches should be narrowed by time/parameters.
manage_data_cache(source_type="all", action="status", cache_dir=None, mission=None, ...) — unified cache status/maintenance for the source categories. It passes source-specific cache options through one advertised tool: CDAWeb (category, observatory, dataset_ids, older_than_days, dry_run, detail), PDS (category, mission, dataset_ids, older_than_days, dry_run, detail, force), and SPICE (mission, filenames). Per-call cache_dir is reported as guidance only; backend cache roots are configured by the MCP server environment.
Supported source_type values:
source_type | Use for | Main data-layer path |
| heliophysics observatory time-series, plasma/fields/particles, solar wind, CDF-like intervals |
|
| Planetary Plasma Interactions archives, planetary mission datasets, PDS metadata/products |
|
| geometry, ephemeris, trajectory, distance, coordinate frames/transforms |
|
Compact CDAWeb catalog discovery examples:
# Default MMS page is compact (<12 KB) and includes exact next calls per dataset.
load_data_source(source_type="cdaweb", source_id="mms")
# Page through or narrow large observatories.
load_data_source(source_type="cdaweb", source_id="mms", limit=10, offset=10)
load_data_source(source_type="cdaweb", source_id="mms", instrument="fgm", dataset_query="srvy")
# Opt into the legacy human prompt only when needed.
load_data_source(source_type="cdaweb", source_id="mms", mode="full")Start here for open-ended science requests.
spedas_overview() — compact map of capability groups and recommended workflow.
search_spedas_data_sources(question, target=None, observables=None) — recommend which data source categories should lead a request.
plan_spedas_observation(science_goal, start=None, stop=None, target=None, observables=None, data_sources=None) — produce a source-specific plan before fetching data.
compare_cdaweb_pds_spice(science_goal="") — explain source boundaries and choose the right source family.
create_spedas_analysis_bundle(study_name, output_dir, ...) — create a request/provenance scaffold with requests/, data/, plots/, provenance/, and notes/ folders.
SPICE is exposed as a data source category, but geometry operations are clearer as explicit tools:
Browse SPICE missions with browse_data_sources(source_type="spice"); the response also includes a frame_catalog with frame descriptions and aliases.
Browse the same SPICE coordinate-frame catalog explicitly with load_data_source(source_type="spice", source_id="frames") or browse_data_parameters(source_type="spice", dataset_id="frames"); use supported_frame_names as transform_coordinates from_frame/to_frame values.
get_ephemeris(mission, target, start, stop, step="1h", frame="J2000", observer=None)
compute_distance(mission, target, observer, start, stop, step="1h")
transform_coordinates(mission, coordinates, from_frame, to_frame, epoch=None)
SPICE kernel cache status/load/clean/check/purge actions are exposed through manage_data_cache(source_type="spice", action=..., mission=..., filenames=...).
These remain available for clients that already know the source-specific browse/fetch operations:
CDAWeb: browse_observatories, load_observatory, browse_parameters, fetch_data
PDS: browse_pds_missions, load_pds_mission, browse_pds_parameters, fetch_pds_data
SPICE: the geometry tools above
The former dedicated cache tools (manage_cdaweb_cache, manage_pds_cache, manage_spice_kernels) are no longer advertised as MCP tools because their actions and kwargs are covered by manage_data_cache. See docs/public_api_strategy.md for the compatibility map and deprecation guidance.
data/pds_archive_map.json is a crawled map of the PDS Planetary Plasma Interactions (PPI) node's public archive tree (https://pds-ppi.igpp.ucla.edu/data, an Apache autoindex-style listing). It is produced by scripts/crawl_pds_archive.py and refreshed the same way:
python scripts/crawl_pds_archive.py --limit 2000 --max-depth 8 --workers 6
python scripts/crawl_pds_archive.py --resume # continue a partial crawl
python scripts/crawl_pds_archive.py --consolidate-only # rebuild asset from JSONL sidecarEach directory node records its relative path, URL, depth, child directory names, file count, min/max child mtime, aggregate file size (when the listing exposes it), and a is_leaf flag marking folders that contain data files and no subdirectories. Crawls are bounded by --limit (directory listings), --max-depth, and an optional --max-time; per-node HTTP errors are recorded and never abort the crawl. The committed asset is a bounded sample (2005 directory nodes, 840 leaf data folders as of the crawl); nodes whose children were not expanded are flagged with children_explored: false.
data/spice_archive_map.json is a crawled map of the NAIF SPICE kernel archive tree (https://naif.jpl.nasa.gov/pub/naif/, an Apache autoindex-style listing). It is produced by scripts/crawl_spice_archive.py (modeled on the PDS crawler, plus an ftplib FTP fallback for directories HTTP cannot serve) and refreshed the same way:
python scripts/crawl_spice_archive.py --limit 2000 --max-depth 8 --workers 6
python scripts/crawl_spice_archive.py --resume # continue a partial crawl
python scripts/crawl_spice_archive.py --consolidate-only # rebuild asset from JSONL sidecarEach directory node records its relative path, URL, depth, child directory names, file count, min/max child mtime, aggregate file size (when the listing exposes it), the SPICE kernel file extensions present, and two classification flags: is_leaf (files, no subdirectories) and is_kernel_leaf (a leaf folder containing at least one kernel file such as .bsp/.bpc/.bc/.tf/.tls/.tsc/.tpc/.ti/.tl/.tm/.mk/.txt). Crawls are bounded by --limit (directory listings), --max-depth, and an optional --max-time; per-node HTTP errors are recorded and never abort the crawl, and --resume re-enqueues the children of parents whose exploration was cut short. The committed asset is a bounded sample (2005 directory nodes, 864 kernel leaf folders as of the crawl — the full NAIF tree is much larger); nodes whose children were not expanded are flagged with children_explored: false and the asset carries "partial": true.
Call spedas_overview().
For a natural-language science request, call search_spedas_data_sources(...) or plan_spedas_observation(...).
Use the data layer:
browse_data_sources(source_type="all")
browse_data_sources(source_type="cdaweb" | "pds" | "spice")
load_data_source(...)
browse_data_parameters(...)
fetch_data_product(...) for CDAWeb/PDS measurement/archive products
Use geometry tools directly for SPICE ephemeris, distance, frame, and coordinate-transform work.
For any real analysis, call create_spedas_analysis_bundle(...) and write fetched files under the generated data/ directory.
Return compact summaries and file paths. Do not paste large science arrays into chat.
git clone https://github.com/spedas/spedas_agent_kit.git
cd spedas_agent_kit
uv sync --extra dev --extra mcp
uv run --extra mcp python -m spedas_agent_kitRun tests and smoke checks:
uv run --extra dev --extra mcp python -m pytest -q
uv run --extra mcp python scripts/smoke_mcp_list_tools.py --jsonThe list-tools smoke starts the stdio MCP server with isolated temporary cache directories, performs MCP initialize + list_tools, and verifies the expected advertised tool names. It does not fetch CDAWeb/PDS data or download SPICE kernels.
The base install is sufficient for the full CDAWeb/PDS/SPICE tool surface; the
optional analysis, hapi, and fdsn extras (and their tools) were removed in
the one-MCP cleanup.
Example stdio configuration:
{
"mcpServers": {
"spedas": {
"command": "uv",
"args": ["run", "--extra", "mcp", "python", "-m", "spedas_agent_kit"],
"cwd": "/path/to/spedas_agent_kit"
}
}
}For plugin-style distribution, the canonical standalone wrappers now live in separate SPEDAS org repos:
https://github.com/spedas/spedas_claude — Claude Code plugin wrapper.
https://github.com/spedas/spedas_codex — Codex plugin wrapper.
The in-repo plugin fixtures were removed in the one-MCP cleanup; runtime-specific
packaging should evolve in the standalone repos while this repository owns the MCP
server itself. The current base list_tools count is 13, plus 8 legacy CDAWeb/PDS
compatibility tools when SPEDAS_AGENT_KIT_COMPAT_TOOLS=1.
spedas_agent_kit should be thick at the SPEDAS data/workflow layer and thin at the backend implementation layer:
Users see one SPEDAS Agent Kit and one data layer.
Data source categories are scientific concepts: CDAWeb, PDS, SPICE/geometry.
Backend packages remain maintainable internal implementation surfaces.
Higher-level tools should encode reusable SPEDAS scientific method: source selection, planning, provenance, and artifact discipline.
See docs/maintainer_note.md and docs/examples/agent_workflow.md for the current framing.
docs/examples/juno_pds_spice_workflow.md — Juno MAG/PDS discovery plus SPICE geometry planning, including current caveats.
The vendored data catalogs (CDAWeb observatory datasets, PDS PPI archive slots,
SPICE kernel manifests) are checked against the live upstream archives by
scripts/scan_drift.py — a stdlib-only scanner (plus requests) that maintains
a heuristic drift manifest per data-folder layer:
layer | catalog root | DRIFT.md | upstream host |
cdaweb |
|
|
|
pds |
|
|
|
spice |
|
|
|
Each scan records every dataset's HTTP status (200/404/redirect), the actual
upstream master filename/casing, and classifies catalog rot as
renamed | case_change | 404 | param_change | date_anomaly.
Results are written incrementally to drift_scan_results.jsonl (resumable on
interrupted runs) and rendered to a committed DRIFT.md snapshot with totals,
the drifted-dataset table, and a new/recovered/persistent scan-history note vs
the previous manifest. Run it as a periodic (e.g. weekly) smoke scan — full
sweeps of all 2917 CDAWeb datasets / 1646 SPICE kernels are slow:
# quick smoke runs (recommended for CI or a cron)
python scripts/scan_drift.py --layer cdaweb --limit 50
python scripts/scan_drift.py --layer pds --limit 50
python scripts/scan_drift.py --layer spice --limit 20
# full sweep (slow; needs network to CDAWeb / PDS PPI / NAIF)
python scripts/scan_drift.py --layer cdaweb--seed-dir DIR (default: $SPEDAS_DRIFT_SEED_DIR, else the temp dir if prior
audit artifacts are present) lets a fresh checkout be seeded best-effort from
previous audit results; pass --no-seed to skip seeding. The initial manifests
were seeded from the 2026-08-03 backend audit artifacts.
A full scheduled scan is intentionally not wired into CI: it needs live network access to the upstream archives and would be flaky/slow in CI. Only the documented smoke commands above (or a maintainer-run cron job) should invoke it.
List CDAWeb observatories with descriptions, dataset counts, and instruments.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully covers the tool's behavior: it lists observatories with specific attributes. For a simple list tool, this is sufficient; no hidden traits or risks are omitted.
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?
Single sentence, perfectly front-loaded, no redundant words. Every word earns its place.
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 zero parameters and existence of output schema, the description completely specifies what the tool does and returns. No further details needed.
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?
No parameters (schema coverage 100%), so baseline 4 applies. Description adds no extra parameter info because none exist.
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 it lists CDAWeb observatories with descriptions, dataset counts, and instruments. It distinguishes from siblings like browse_parameters (parameters) and browse_pds_missions (PDS missions).
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?
No explicit guidance on when to use vs. alternatives, but implied usage is clear. Lacks exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse variables/metadata for one or more CDAWeb dataset IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | ||
| dataset_ids | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies read-only access but does not disclose authentication needs, rate limits, error handling for invalid dataset IDs, or any other behavioral traits beyond the basic action.
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 a single short sentence, making it concise but lacking structure such as sections or bullet points. While efficient, it sacrifices informative detail.
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 presence of an output schema and two parameters with no schema descriptions, the description is insufficient. It does not explain what 'browsing' returns, how to use multiple IDs, or any usage context, leaving the agent with significant ambiguity.
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 explain parameters. It vaguely mentions 'one or more dataset IDs' but does not clarify the distinction between the required dataset_id and optional dataset_ids, nor any constraints like format or mutual exclusivity.
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 uses a specific verb 'Browse' and clearly identifies the resource 'variables/metadata for one or more CDAWeb dataset IDs', distinguishing it from sibling tools like browse_observatories or browse_pds_parameters.
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 no guidance on when to use this tool versus alternatives such as browse_observatories or browse_pds_parameters, nor does it mention any prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List PDS PPI missions/spacecraft with descriptions, dataset counts, and instruments.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose how the query parameter affects results, whether results are paginated, or any authentication requirements. Basic purpose only.
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?
Single sentence with clear action and objects, no unnecessary words. Front-loaded with verb.
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?
With no annotations, no parameter explanation, and an optional query parameter, the description lacks details on return structure, pagination, or query behavior. Incomplete for effective tool selection.
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% and the description does not explain the 'query' parameter. The parameter's meaning and usage are completely undocumented, leaving the agent without guidance.
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 it lists PDS PPI missions/spacecraft with specific details (descriptions, dataset counts, instruments). It uses a specific verb ('list') and resource, differentiating it from siblings like 'load_pds_mission' which is singular.
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?
No explicit guidance on when to use this tool versus alternatives like 'load_pds_mission'. Usage is implied for an overview of missions, but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse variables/metadata for one or more PDS PPI dataset IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | No | ||
| dataset_ids | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full weight. It only says 'browse' but lacks details on output format, pagination, or any constraints. Minimal behavioral information.
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 extremely concise (one sentence) but omits necessary details. While brevity is valued, it should include more behavioral and parameter information.
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 presence of an output schema, return values are covered. However, with two undocumented parameters, no annotations, and multiple sibling tools, the description is incomplete for effective use.
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%. The description does not explain the two parameters (dataset_id, dataset_ids) or their relationship (e.g., single vs. multiple). Parameter semantics are unclear.
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 it browses variables/metadata for PDS PPI dataset IDs. However, it does not distinguish itself from siblings like browse_parameters or browse_observatories.
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?
No guidance is provided on when to use this tool versus alternatives. No when/when-not conditions or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare CDAWeb, PDS, and SPICE roles for a SPEDAS MCP science request.
| Name | Required | Description | Default |
|---|---|---|---|
| science_goal | 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 full burden for behavioral disclosure. It fails to state whether the tool is read-only, destructive, requires authentication, or any side effects. The description provides no behavioral context beyond the vague 'compare' action.
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 a single sentence, which is concise, but it sacrifices necessary detail. It front-loads the verb but fails to provide enough information to be useful. A 3 is appropriate as it is not verbose but is under-specified.
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 low schema coverage (0%), no annotations, and a vague description, the definition is incomplete. An output schema exists but its content is not visible to assess if it compensates. The agent lacks sufficient information to correctly invoke the tool for the given context.
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?
The input schema has 0% schema description coverage, meaning the parameter 'science_goal' has no description in the schema. The tool description does not mention or explain this parameter, leaving the agent without any guidance on how to use it.
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 uses the verb 'compare' which indicates the main action, but the object 'CDAWeb, PDS, and SPICE roles' is vague; 'roles' is ambiguous and does not clarify what aspect (e.g., data availability, access rights) is being compared. The purpose is discernible but lacks specificity.
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?
No guidance is provided on when to use this tool versus its siblings such as fetch_data, fetch_pds_data, or browse_observatories. The description does not mention any prerequisites, alternatives, or context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute distance between two SPICE targets over a time range.
| Name | Required | Description | Default |
|---|---|---|---|
| target1 | Yes | ||
| target2 | Yes | ||
| time_start | Yes | ||
| time_end | Yes | ||
| step | No | 1h |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the transparency burden. It only states the basic operation without disclosing important behavioral traits like output units, error handling, or assumptions about SPICE targets.
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 a single sentence with no extraneous words, but it is too brief and omits critical details. Conciseness is not valuable when it sacrifices completeness.
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 does not explain what the tool returns. The 5 parameters lack descriptions, and the context of SPICE is not elaborated. The description is incomplete for a tool of this complexity.
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%, and the description adds no meaning beyond parameter names. It does not clarify target1/target2 format, time_start/time_end format, or step semantics.
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 the tool computes distance between two SPICE targets over a time range, which is specific and distinguishes it from sibling tools like get_ephemeris or transform_coordinates.
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?
No guidance on when to use this tool versus alternatives. The description does not mention any context or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a lightweight request/provenance bundle for a planned SPEDAS analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| study_name | Yes | ||
| output_dir | Yes | ||
| science_goal | No | ||
| target | No | ||
| start | No | ||
| stop | No | ||
| data_sources | 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 full burden. It only says 'lightweight request/provenance bundle', implying non-destructive, but does not disclose side effects, auth requirements, or state changes. For a creation tool, more detail is needed.
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 a single concise sentence with no filler. Could be slightly expanded to include parameter context without losing conciseness.
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 7 parameters, no schema descriptions, and no annotations, the description is too sparse. Output schema exists but is not explained. The tool's purpose and output remain vague.
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. However, it only mentions 'planned SPEDAS analysis' without explaining any of the 7 parameters (study_name, output_dir, etc.). Parameter names offer some hint but lack specifics.
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 the verb 'Create' and the resource 'lightweight request/provenance bundle for a planned SPEDAS analysis'. It distinguishes from siblings like 'plan_spedas_observation' by specifying provenance, but could be more explicit about the bundle's role.
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?
No guidance on when to use this tool versus alternatives (e.g., plan_spedas_observation or fetch tools). The description implies usage when bundling a planned analysis, but lacks context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch CDAWeb timeseries data, write a file, and return metadata/stats only.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | ||
| parameters | Yes | ||
| start | Yes | ||
| stop | Yes | ||
| output_dir | Yes | ||
| format | No | csv |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions file writing and returning metadata/stats, but lacks details like file naming, overwrite behavior, network usage, authorization, or rate limits. The behavior is partially transparent but insufficient.
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 a single concise sentence of 12 words with no wasted content. However, it omits crucial parameter information, so it's not optimally structured.
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 tool's complexity (6 parameters, 5 required, file writing, external data), the description is too minimal. It does not explain parameter roles, output format, or side effects. An output schema exists but is not referenced, and the description adds little context.
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%, meaning parameters have no documentation. The description does not elaborate on any parameter (e.g., dataset_id, time range format, output_dir role). It adds no meaning beyond the schema's field names.
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 the verb ('Fetch'), the resource ('CDAWeb timeseries data'), and the action ('write a file, and return metadata/stats only'). It distinguishes from siblings that deal with other data sources (e.g., fetch_pds_data) or browsing tasks.
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 no guidance on when to use this tool versus alternatives. It does not mention context, prerequisites, or exclusions, leaving the agent without selection heuristics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch PDS PPI timeseries data, write a file, and return metadata/stats only.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | ||
| parameters | Yes | ||
| start | Yes | ||
| stop | Yes | ||
| output_dir | Yes | ||
| format | No | csv |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions writing a file as a side effect but fails to elaborate on file location, overwrite behavior, or authorization requirements. With no annotations, the description carries the full burden but provides minimal behavioral disclosure.
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 very short (one sentence) but lacks structure. It is concise but omits essential details that could be presented in a more organized manner.
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?
With 6 parameters (5 required), no schema descriptions, and no output schema content (though flagged as present), the description fails to provide adequate context. The return value is vaguely described as 'metadata/stats only' without structure, and no explanation of PDS PPI or data source is given.
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%, and the description does not explain any parameters. Critical fields like dataset_id, parameters, start, stop, output_dir, and format remain undocumented, leaving the agent without guidance on how to fill them.
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 the tool fetches timeseries data, writes a file, and returns metadata/stats. This specific verb+resource combination distinguishes it from sibling tools like browse_* or fetch_data.
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?
No guidance on when to use this tool versus alternatives (e.g., fetch_data, search_spedas_data_sources). The description does not provide context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get single-time state inline or timeseries trajectory written to CSV.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| time | Yes | ||
| frame | No | ECLIPJ2000 | |
| observer | No | SUN | |
| output_file | No | ||
| time_end | No | ||
| step | No | 1h |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It mentions output types (inline vs CSV) but omits side effects, authentication, rate limits, or what happens with omitted optional parameters.
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 very concise (one sentence) but lacks structure. It front-loads the verb but does not clearly separate the two modes or list parameters. Could be more helpful with minimal expansion.
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 7 parameters, 2 required, and an output schema, the description is incomplete. It does not mention the output schema content or the purpose of key parameters like frame and observer. Leaves significant gaps.
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 description must compensate. It indirectly references 'time' (single-time state) and 'time_end'/'step' (timeseries) and 'output_file' (CSV), but fails to explain 'target', 'observer', or 'frame'. Minimal added value.
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 the tool's basic function: retrieving ephemeris data as either a single-time state or a timeseries trajectory output to CSV. It distinguishes two modes, which is helpful.
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?
No guidance is given on when to use this tool versus siblings like compute_distance or fetch_data. No context on prerequisites or excluded scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List supported SPICE coordinate frames and usage notes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 must carry the transparency burden. It states the tool lists frames and usage notes, which is appropriate for a read-only operation. However, it does not disclose any potential side effects or limitations, though none are expected.
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 a single concise sentence that effectively communicates the tool's purpose without any superfluous 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?
The description is adequate for a simple listing tool with no parameters and an output schema. It tells what the tool does and mentions usage notes. However, it could be slightly more explicit about the return format, but that is likely covered by the output schema.
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?
There are no parameters, and schema coverage is 100%. The description does not need to add parameter details, so a baseline of 4 is appropriate.
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 identifies the action (list) and the resource (supported SPICE coordinate frames), plus mentions usage notes. It distinguishes from sibling tools like 'transform_coordinates' and 'list_spice_missions'.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for exploring available frames, but does not mention prerequisites or relationships with transformation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List supported SPICE spacecraft/body missions with NAIF IDs and kernel status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It adequately indicates a read-only listing operation without side effects, but lacks details on performance or special behaviors. For a parameterless tool, this is minimally sufficient but not rich.
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?
A single, front-loaded sentence that efficiently conveys the tool's action and output. No redundant or irrelevant information.
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 simple list tool with no parameters and an existing output schema, the description covers the key aspects. However, the lack of usage guidelines prevents full completeness despite the tool's simplicity.
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?
With zero parameters and 100% schema coverage, the baseline is 4. The description adds value by specifying the output includes NAIF IDs and kernel status, which informs the agent beyond the parameter 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 clearly states the tool lists SPICE spacecraft/body missions along with NAIF IDs and kernel status. The verb 'list' and resource 'supported SPICE missions' are specific, and it distinguishes from sibling tools like browse_pds_missions and list_coordinate_frames.
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?
No guidance is provided on when to use this tool versus alternatives. While sibling tools exist, the description does not specify context or exclusions, leaving the agent without direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load CDAWeb observatory prompt/catalog for a lowercase observatory stem.
| Name | Required | Description | Default |
|---|---|---|---|
| observatory_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as side effects, authorization needs, or whether it modifies state. The verb 'Load' implies a read operation, but detail is insufficient.
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 a single sentence with no unnecessary words. It is concise and front-loaded with the key action.
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?
Although the tool has low complexity (1 param, output schema exists), the description does not clarify what a 'prompt/catalog' is or the expected naming convention for observatory stems. Slightly incomplete for a new user.
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?
With 0% schema coverage, the description compensates partially by specifying that observatory_id should be a 'lowercase observatory stem'. This adds format guidance, but does not explain what a stem is or provide examples, leaving ambiguity.
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 the action ('Load') and resource ('CDAWeb observatory prompt/catalog'), and specifies the input format ('lowercase observatory stem'). However, it does not explicitly distinguish from the sibling tool 'browse_observatories', which likely lists observatories.
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?
No guidance is provided on when to use this tool versus alternatives like browse_observatories. The description lacks context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load PDS PPI mission prompt/catalog for a lowercase mission stem.
| Name | Required | Description | Default |
|---|---|---|---|
| mission_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 must disclose behavior. It only says 'Load' without clarifying side effects, authentication needs, rate limits, or return format. Minimal transparency for a tool with no annotation support.
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?
Single sentence with no wasted words. Front-loaded verb and resource, efficient.
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 output schema but description does not explain what 'prompt/catalog' means or what the return value contains. Given the simple parameter set, the description could provide more context about the expected outcome.
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 has 0% description coverage for mission_id, but description adds meaning by specifying 'lowercase mission stem', which constrains the input format beyond the schema type.
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?
Description states verb 'Load' and resource 'PDS PPI mission prompt/catalog' with a clear constraint 'for a lowercase mission stem', distinguishing it from siblings like browse_pds_missions (list) and fetch_pds_data (data retrieval).
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?
Implicitly guides input format (lowercase stem) but provides no explicit context on when to use this tool vs alternatives (e.g., browse_pds_missions or fetch_pds_data) or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage CDAWeb cache and metadata/catalog refresh operations.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| category | No | all | |
| observatory | No | ||
| dataset_ids | No | ||
| older_than_days | No | ||
| dry_run | No | ||
| detail | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits such as destructiveness (e.g., 'clean' potentially deletes cache), authorization needs, or side effects. With no annotations, the description carries the full burden, which it fails to meet.
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 a single clear sentence, but it is too concise; it sacrifices necessary detail for brevity. The structure is tidy but incomplete.
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 tool with 7 parameters, no annotations, and an output schema, the description is extremely minimal. It lacks essential context about actions, categories, and usage patterns, making it inadequate for an AI agent to use correctly.
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%, yet the description provides no explanation of parameters like action, category, or dry_run. The agent must infer meaning from parameter names only, which is insufficient for correct usage.
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 states it manages CDaWeb cache and metadata/catalog refresh, but uses the vague verb 'Manage' without specifying the specific operations or distinguishing from sibling tools like manage_pds_cache or manage_spice_kernels.
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?
No guidance is provided on when to use this tool versus alternatives. Given the presence of similar cache management tools among siblings, the lack of usage context is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage PDS cache and metadata/catalog refresh operations.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| category | No | all | |
| mission | No | ||
| dataset_ids | No | ||
| older_than_days | No | ||
| dry_run | No | ||
| detail | No | ||
| force | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits like destructiveness. It mentions 'refresh operations' but does not warn that actions like 'clean' or 'build_metadata' may alter or delete data. No information on permissions, side effects, or rate limits.
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 a single sentence and is concise, but it is vague and does not use the space effectively. It could be restructured to front-load more specific behaviors or parameter hints without being verbose.
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 tool's complexity (8 parameters, multiple actions, potential destructiveness) and lack of annotations or schema descriptions, the description is insufficient. It does not explain the output schema or provide enough context for an agent to safely invoke the tool.
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%, and the description adds no information about parameters. The 8 parameters (especially 'action' with 6 enum values, 'category', 'mission', etc.) are left entirely to the schema, which lacks descriptions. The description does not compensate for the schema deficiency.
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 states it manages PDS cache and metadata/catalog refresh operations, which is clear enough but uses the generic verb 'manage'. It distinguishes from siblings like 'manage_cdaweb_cache' by specifying 'PDS', but lacks specificity about the range of actions (status, clean, refresh, etc.).
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?
No guidance on when to use this tool versus alternatives such as 'manage_cdaweb_cache' or when not to use it. The description does not mention prerequisites, preferred contexts, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage SPICE kernels and cache state.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| mission | No | ||
| filenames | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose whether actions are read-only (e.g., status) or mutating (e.g., purge). The single verb 'manage' obscures behavioral differences.
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 only 7 words, but it is under-specified rather than concise. It omits critical details that would fit in a slightly longer description.
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 complexity of three parameters (including an enum with five values) and an output schema, the description provides almost no context. It fails to explain what each action does, how to use optional parameters, or what the output contains.
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%, and the description adds no meaning to the three parameters (action, mission, filenames). The enum values for action are not listed or explained.
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 states 'Manage SPICE kernels and cache state,' which identifies a verb and resource. However, it is vague and does not distinguish from sibling tools like manage_cdaweb_cache or manage_pds_cache, which also manage caches.
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?
No guidance on when to use this tool versus alternatives, or specific contexts for the actions. The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plan a SPEDAS science workflow before using low-level CDAWeb/PDS/SPICE tools.
| Name | Required | Description | Default |
|---|---|---|---|
| science_goal | Yes | ||
| start | No | ||
| stop | No | ||
| target | No | ||
| observables | No | ||
| data_sources | 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 must disclose behavioral traits. It fails to explain what 'plan' entails operationally (e.g., generates a workflow, stores a plan, requires user input). The description is too vague about the tool's effects, output, or side effects, leaving agents uncertain about its exact 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?
The description is a single sentence, making it concise but overly sparse. It lacks structure such as front-loading key information or separating purpose from usage. While brevity is valued, the sentence fails to earn its place as it omits critical details about parameters and behavior.
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 tool has 6 parameters, no annotations, and many siblings, the description is insufficient. It does not explain what the plan looks like or how it feeds into later steps, even though an output schema exists. The agent needs more context to understand the planning scope and output structure.
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?
The input schema has 6 parameters with 0% description coverage. The description adds no meaning beyond the parameter names themselves, which are somewhat self-explanatory (e.g., 'science_goal', 'start'), but the schema has no descriptions or enums. The description should at least indicate how parameters relate to the planning process.
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 the tool's purpose: 'Plan a SPEDAS science workflow'. It specifies the verb 'plan' and the resource 'SPEDAS science workflow', and distinguishes it from sibling tools like fetch_data or browse_parameters by noting it is used 'before using low-level CDAWeb/PDS/SPICE tools'.
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 clear usage context: 'before using low-level tools', indicating when to use this tool. It implies this is a preliminary step, but does not explicitly state when not to use it or mention alternatives among siblings. The guidance is sufficient but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommend whether a SPEDAS request should start with CDAWeb, PDS, SPICE, or a mix.
| Name | Required | Description | Default |
|---|---|---|---|
| question | No | ||
| target | No | ||
| observables | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks disclosure of behavioral traits. No annotations are provided, and the description does not mention side effects, authorization needs, rate limits, or how the recommendation is made (e.g., based on inputs, algorithm).
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 a single sentence, which is concise but somewhat under-specified. It could benefit from additional context without becoming verbose.
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?
With 3 undocumented parameters, no annotations, and no output schema description, the tool description is incomplete. It fails to provide sufficient context for an agent to use it effectively.
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%, meaning no parameters are described in the schema. The description does not explain the meaning or usage of 'question', 'target', or 'observables', leaving the agent to guess.
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 the tool's purpose: to recommend which SPEDAS data source (CDAWeb, PDS, SPICE, or mix) to start with. This is a specific verb-resource combination and distinguishes it from sibling tools that browse, fetch, or compute data.
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?
No guidance on when or when not to use this tool. It does not specify prerequisites, alternatives, or context. Compared to siblings like 'compare_cdaweb_pds_spice', the usage scenario is unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Describe available SPEDAS MCP capabilities and the recommended workflow.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description's verb 'describe' clearly indicates a read-only, non-destructive operation. This adequately discloses the behavioral trait for a tool with no side effects.
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 a single sentence that is concise and front-loaded, stating the core action and scope without any unnecessary 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?
Given zero parameters and an existing output schema, the description adequately conveys the tool's role as an overview. It does not detail output format, but the output schema should cover that.
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?
The input schema has zero parameters, and the description correctly implies no user input is needed. With 100% schema coverage, the description adds no further parameter information, which is appropriate for a parameterless tool.
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 the tool's purpose: describing available SPEDAS MCP capabilities and the recommended workflow. It uses a specific verb ('describe') and resource ('SPEDAS MCP capabilities, workflow'), distinguishing it from sibling tools that perform specific actions like browsing, fetching, or computing.
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?
No explicit guidance on when to use this tool vs. alternatives. It is implied to be a starting point, but the description does not state 'use first' or exclude any contexts. For an overview tool, this is minimally adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transform a 3D vector between SPICE coordinate frames.
| Name | Required | Description | Default |
|---|---|---|---|
| vector | Yes | ||
| time | Yes | ||
| from_frame | Yes | ||
| to_frame | Yes | ||
| spacecraft | 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 must disclose behavior. It only says 'transform' without explaining side effects, error conditions, or requirements like kernel availability. The output schema exists but is not described.
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 a single sentence, which is concise, but it lacks structure and is too minimal. It could be expanded without verbosity.
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 complex task like coordinate frame transformation, the description omits crucial context such as prerequisites (kernel loading), required vector dimensions, and what the output contains. Despite having an output schema, the description is insufficient.
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%, and the description does not explain any parameters. It does not mention that 'vector' must be length 3, what 'time' format is used, or what valid values for frames are. The optional 'spacecraft' parameter is not clarified.
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 it transforms a 3D vector between SPICE coordinate frames, with a specific verb and resource. It distinguishes from siblings like 'list_coordinate_frames' which lists frames, and 'get_ephemeris' which gets positions.
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 no guidance on when to use this tool versus alternatives or prerequisites. It does not mention conditions like needing kernels loaded or not to use for position transformations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose, with separate tools for browsing, fetching, managing caches, SPICE operations, and high-level planning. There is no ambiguity between tools like browse_observatories and browse_pds_missions, as they target different data sources.
All tool names follow a consistent verb_noun pattern using underscores (e.g., browse_observatories, fetch_data, manage_spice_kernels). High-level tools consistently include 'spedas' as a prefix. The naming is predictable and easy to navigate.
With 21 tools, the set is slightly above the ideal range of 3-15, but the number is justified by the need to cover three distinct data sources (CDAWeb, PDS, SPICE) plus planning and management operations. The tools are well-scoped and not excessive.
The tool set covers core workflows: browsing, data fetching, cache management, SPICE computations, and planning. Minor gaps exist, such as the lack of a search tool for datasets by criteria, but overall it supports the main use cases for space physics data analysis.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Hosted MCP server for live public-data APIs and Skills for AI agents.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/spedas/spedas_agent_kit'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
