Provides access to the NASA Exoplanet Archive, the authoritative database of every confirmed exoplanet, candidate planet, and host star, with tools for searching, retrieving details, resolving names, exploring tables, and executing ADQL queries.
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., "@nasa-exoplanet-mcp Find rocky planets in the habitable zone within 50 parsecs"
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.
An MCP server that gives AI assistants direct access to NASA's Exoplanet Archive — the authoritative database of every confirmed exoplanet, candidate planet, and host star. Built on the archive's TAP (Table Access Protocol) service with full ADQL query support.
Once connected, you can ask your AI assistant questions like:
"Find rocky planets in the habitable zone within 50 parsecs of Earth"
"What do we know about the TRAPPIST-1 system?"
"How many exoplanets has TESS discovered? Break it down by year."
"Show me planets with atmospheric spectroscopy data available"
"Compare the orbital parameters of all planets around Kepler-90"
"What's the mass-radius distribution of transiting planets discovered after 2020?"
Here's a short video of it in action:
https://github.com/user-attachments/assets/ee4d6823-08fc-4c32-802f-c88d34032d3d
Related MCP server: Jilebi
Tool | Description |
search_planets | Search confirmed exoplanets with flexible filters (radius, mass, temperature, distance, discovery method, facility, year, and more). The primary tool for most questions. |
get_planet | Get comprehensive details for a single planet — orbital, physical, stellar, and discovery properties with uncertainties. |
resolve_name | Translate any name or catalog ID (TIC, KOI, Gaia, 2MASS, HD, HIP) to the canonical archive name. Handles common issues like missing spaces in planet names. |
list_tables | Discover all 40+ tables in the archive — confirmed planets, TESS candidates, Kepler KOIs, transit spectroscopy, microlensing, time series, and more. |
list_columns | Explore the 300+ available columns for any table, filterable by category (orbital, physical, stellar, discovery, system, photometry). |
run_query | Execute raw ADQL queries for full flexibility — aggregations, JOINs, spatial/cone searches, or querying any table in the archive. |
Python 3.10+
uv (recommended) or pip
git clone https://github.com/saikrmet/nasa-exoplanet-mcp.git
cd nasa-exoplanet-mcp
uv venv && uv pip install -e .Local (stdio) — for Claude Desktop, Claude Code, or any local MCP client:
nasa-exoplanet-mcpRemote (HTTP) — for hosted deployments or remote MCP clients:
nasa-exoplanet-mcp serve
nasa-exoplanet-mcp serve --port 9000
nasa-exoplanet-mcp serve --host 127.0.0.1 --port 9000The server will be available at http://your-host:8000/mcp.
Requires uv to be installed.
Open your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"nasa-exoplanet": {
"command": "uvx",
"args": ["nasa-exoplanet-mcp"]
}
}
}Restart Claude Desktop — the 6 exoplanet tools appear automatically.
claude mcp add nasa-exoplanet -- uvx nasa-exoplanet-mcpAny client that supports stdio MCP servers works. Use uvx as the command and ["nasa-exoplanet-mcp"] as the args.
If you're hosting the server (e.g. as a web app), start it with the serve subcommand:
nasa-exoplanet-mcp serve
nasa-exoplanet-mcp serve --host 0.0.0.0 --port 8000Then point your MCP client at the URL:
{
"mcpServers": {
"nasa-exoplanet": {
"url": "http://your-host:8000/mcp"
}
}
}The primary tool for most exoplanet questions. All parameters are optional and combinable.
Parameter | Type | Description |
name | string | Planet name (partial match) |
hostname | string | Host star name — returns all planets in the system |
discovery_method | string | Transit, Radial Velocity, Microlensing, Imaging, etc. |
facility | string | Discovery facility (TESS, Kepler, etc., partial match) |
min_radius / max_radius | float | Planet radius in Earth radii (Earth=1.0, Jupiter~11.2) |
min_mass / max_mass | float | Planet mass in Earth masses (Earth=1.0, Jupiter~317.8) |
min_period / max_period | float | Orbital period in days |
min_temperature / max_temperature | float | Equilibrium temperature in K (habitable zone ~200-320K) |
min_distance / max_distance | float | Distance in parsecs (1 pc ~ 3.26 light-years) |
year_min / year_max | int | Discovery year |
min_planets_in_system | int | For multi-planet systems (use 2+) |
columns | list | Columns to return (defaults to curated set of 12) |
order_by | string | Sort column, prefix with |
limit | int | Max results, 1-500 (default 25) |
offset | int | Skip N results for pagination |
Returns comprehensive data for a single planet, organized into categories:
Identity: name, host star, catalog IDs (TIC, Gaia, HD, HIP)
Orbital: period, semi-major axis, eccentricity, inclination (with uncertainties)
Physical: radius, mass, density, equilibrium temperature, insolation flux
Transit: depth, duration, midpoint, impact parameter
Stellar: spectral type, temperature, mass, radius, metallicity, age
Discovery: method, year, facility, telescope, instrument
System: number of planets/stars, distance, coordinates
Data availability: counts of available spectra and observations
For queries that need full ADQL power. Examples:
-- Discovery statistics by year
SELECT disc_year, COUNT(*) AS n FROM pscomppars
WHERE disc_year IS NOT NULL GROUP BY disc_year ORDER BY disc_year DESC
-- Cone search: planets within 5 degrees of coordinates
SELECT pl_name, hostname, ra, dec, sy_dist FROM pscomppars
WHERE CONTAINS(POINT('ICRS',ra,dec), CIRCLE('ICRS',291.0,48.0,5.0))=1
-- TESS candidates with specific disposition
SELECT * FROM toi WHERE tfopwg_disp = 'PC' ORDER BY toi
-- Transit spectroscopy data for a planet
SELECT * FROM transitspec WHERE plntname = 'WASP-39 b'
-- Planets with both mass and radius measurements (for density studies)
SELECT pl_name, pl_rade, pl_bmasse, pl_dens FROM pscomppars
WHERE pl_rade IS NOT NULL AND pl_bmasse IS NOT NULL AND pl_dens IS NOT NULLThis server queries the NASA Exoplanet Archive operated by IPAC at Caltech, under contract with NASA as part of the Exoplanet Exploration Program. The archive is the official NASA repository for exoplanet data and is updated weekly.
No API key is required. The archive is free and open to everyone.
Key tables accessible through this server:
Table | Contents | Rows |
pscomppars | Confirmed planets (composite best values) | ~6,300 |
ps | All published measurements (multiple per planet) | ~39,900 |
stellarhosts | Host star properties | ~47,600 |
toi | TESS candidate planets | ~7,900 |
cumulative | Kepler Objects of Interest | ~9,600 |
k2pandc | K2 planets and candidates | ~4,000 |
ml | Microlensing planets | ~880 |
transitspec | Transit spectroscopy (atmospheric) | ~5,900 |
emissionspec | Emission spectroscopy | ~2,400 |
Use the MCP Inspector to test the server interactively:
npx @modelcontextprotocol/inspector uvx nasa-exoplanet-mcpServer logs are written to stderr and won't interfere with the stdio transport.
git clone https://github.com/saikrmet/nasa-exoplanet-mcp.git
cd nasa-exoplanet-mcp
uv venv && uv pip install -e ".[dev]"
# Run the server locally
nasa-exoplanet-mcp
# Open FastMCP dev inspector
mcp dev src/server.py:mcp
# Run tests
uv run pytest
# Lint
uv run ruff check src/This project has three layers of tests:
Layer | Command | What it tests |
Unit |
| Query building, error parsing, validation. No network. Fast (<1s). |
Integration |
| Live calls to the NASA Exoplanet Archive. Verifies real data. ~2 min. |
LLM scenarios |
| End-to-end: an LLM agent reads tool descriptions, picks tools, returns answers. ~7 min, opt-in. |
The first two run without any setup. The LLM layer requires an API key.
These tests spin up an LLM agent that reads only the MCP tool descriptions, then verifies it correctly chooses tools and returns factually correct answers for 44 natural-language scenarios spanning 8 categories (simple lookup, filtered search, aggregation, multi-step queries, name resolution, error recovery, ambiguous questions, out-of-scope questions).
Install the LLM test dependencies:
uv pip install -e ".[llm]"Configure your provider by creating a .env file at the project root (see .env.example). Supported providers:
# OpenAI
TEST_MODEL=openai:gpt-4o-mini
OPENAI_API_KEY=sk-...
# Anthropic
TEST_MODEL=anthropic:claude-haiku-4-5
ANTHROPIC_API_KEY=sk-ant-...
# Google Gemini
TEST_MODEL=google-gla:gemini-2.5-flash
GOOGLE_API_KEY=...
# Azure OpenAI
TEST_MODEL=azure:<your-deployment-name>
AZURE_OPENAI_API_KEY=...
AZURE_OPENAI_ENDPOINT=https://<resource>.cognitiveservices.azure.com
AZURE_OPENAI_API_VERSION=2025-04-01-previewRun the suite:
pytest -m llm -vIf TEST_MODEL is not set, all LLM tests auto-skip — pytest still runs cleanly without them.
Adding new scenarios is straightforward — append a Scenario(...) entry to tests/llm/scenarios.py.
src/
server.py # FastMCP server instance and entry point
client.py # Async HTTP client for TAP and Alias APIs
config.py # Default columns, table metadata, valid enums
errors.py # Error types and TAP XML error parser
tools/
search.py # search_planets
planet.py # get_planet
names.py # resolve_name
schema.py # list_tables, list_columns
query.py # run_queryMIT
Get comprehensive details for a single confirmed exoplanet by exact name. Returns all available properties organized into categories: orbital parameters, physical properties, stellar host properties, discovery information, system properties, and counts of available follow-up data.
Use this after search_planets to get full details on a specific result, or when the user asks about a specific known planet. The planet name must be exact (e.g., 'Kepler-22 b', not 'Kepler-22b'). If unsure of the exact name, use resolve_name first to find the canonical archive name.
Returns data from the Planetary Systems Composite Parameters table (best-available values across all published measurements).
| Name | Required | Description | Default |
|---|---|---|---|
| planet_name | Yes | Exact planet name as it appears in the archive (e.g., 'Kepler-22 b', 'TRAPPIST-1 e', 'HD 209458 b'). Case-sensitive. Use resolve_name if unsure of exact spelling. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context beyond that: it states the data source ('Planetary Systems Composite Parameters table') and the best-available nature of values, plus the distinction that only confirmed exoplanets are included. It does not contradict annotations, and the extra context about data provenance is valuable.
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 structured in three focused paragraphs: purpose and return categories, usage guidance and naming constraints, and data source. Each sentence earns its place, no fluff. It is front-loaded with the core purpose, and the additional details are directly useful.
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 a single parameter, full schema coverage, rich annotations, and an output schema, the description adds complementary context: usage after search, exact name handling, and the composite data table. It covers all necessary aspects for an agent to select and invoke this tool correctly, without needing to explain return values since the output schema exists.
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 100%: the input schema fully describes planet_name with exact spelling, case-sensitivity, and guidance to use resolve_name. The description repeats these details (e.g., 'must be exact,' 'Kepler-22 b, not Kepler-22b') without adding new meaning beyond what the schema already provides. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Get') and resource ('comprehensive details for a single confirmed exoplanet by exact name'), clearly distinguishing it from siblings like search_planets (which searches) and resolve_name (which canonicalizes names). It explicitly frames this tool as the follow-up to search_planets for full details on a single result, making its purpose unmistakable.
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 gives explicit when-to-use guidance: 'Use this after search_planets to get full details on a specific result, or when the user asks about a specific known planet.' It also provides a clear alternative: 'If unsure of the exact name, use resolve_name first.' This is excellent contextual guidance that names the alternative tool and the condition for choosing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available columns for a table in the NASA Exoplanet Archive, with data types, descriptions, and units. Use this to discover what data fields exist before selecting specific columns in search_planets or writing ADQL queries with run_query.
The main planet table (pscomppars) has 300+ columns. Use the category filter to narrow results to a manageable set. You do not need this for basic queries — search_planets returns a useful default column set. Use this when the user asks about specific properties that may not be in the defaults, or before formulating a run_query call.
| Name | Required | Description | Default |
|---|---|---|---|
| table | No | Table name (default: 'pscomppars'). Use list_tables to see all available tables. | pscomppars |
| category | No | Filter columns by category. One of: orbital (period, eccentricity, inclination), physical (radius, mass, density, temperature), stellar (host star properties), discovery (method, year, facility), system (distance, coordinates, counts), photometry (magnitudes in various bands). If omitted, queries the archive for all columns in the table. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds valuable behavioral context, noting that the main planet table has 300+ columns and suggesting the category filter to narrow results, which implies a potentially large output and gives the agent guidance on managing it. This goes beyond the bare annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, leading with the core action, then usage guidance, then supplementary context about the large table and when the tool is unnecessary. It is slightly long but every sentence adds relevant information; no waste.
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 clear sibling differentiators, the description covers all necessary aspects: what the tool lists, when to use it, when not to, and how to handle its potentially large result set. It also properly references the default table and lists the category options implicitly via the 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?
Schema description coverage is 100%; both parameters (table and category) already have detailed descriptions including examples and defaults. The tool description adds a rationale for using the category filter ('to narrow results to a manageable set') but does not meaningfully enhance parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and object: 'List available columns for a table in the NASA Exoplanet Archive, with data types, descriptions, and units.' This clearly distinguishes the tool from siblings like search_planets (which searches data) and list_tables (which lists tables). The purpose is further reinforced by 'discover what data fields exist' and its relation to search_planets/run_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: 'Use this to discover what data fields exist before selecting specific columns in search_planets or writing ADQL queries with run_query.' It also states when it is not needed: 'You do not need this for basic queries — search_planets returns a useful default column set.' This directly addresses usage versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available tables in the NASA Exoplanet Archive with descriptions. Returns table names, descriptions, approximate row counts, and guidance on what each table is used for.
Use this to discover what data is available before writing queries with run_query. The most commonly used tables are: pscomppars (one row per confirmed planet, used by search_planets and get_planet), ps (all published measurements with multiple rows per planet), stellarhosts (host star properties), and toi (TESS candidate planets not yet confirmed).
This tool returns a curated list of the most important tables. The archive has 40+ tables in total. To discover all of them, use run_query with: SELECT table_name, description FROM TAP_SCHEMA.tables ORDER BY table_name
You do not need this tool for basic planet searches — search_planets already queries the right table. Use this when you need to query specialized tables like transit spectroscopy, microlensing, Kepler KOIs, or time series data via run_query.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, not destructive), the description adds critical behavioral context: it returns a curated list of the most important tables, not all 40+ tables, and explains how to get the full list via run_query. It also clarifies the tool's relationship to other tools and the nature of the data returned, which is valuable beyond static hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, usage guidance, and important caveats. Each sentence provides distinct value—no fluff or repetition. The length is justified given the need to explain the curated nature and the distinction from sibling tools.
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 an output schema present and no parameters, the description fully covers what an agent needs to know: what the tool returns, how to use it, its limitations, and how to access the full table list. It also provides specific examples of common tables, making it complete for practical 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?
The tool has zero parameters, so there is nothing for the description to explain. Per the baseline rule for 0-param tools, a score of 4 is appropriate. The description does not need to add parameter semantics, and it doesn't.
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 with a specific verb and resource: 'List all available tables in the NASA Exoplanet Archive with descriptions.' It also enumerates the return contents (names, descriptions, approximate row counts, guidance), making it immediately obvious what the tool does. It distinguishes itself from siblings by explicitly noting when search_planets or run_query are more appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use this to discover what data is available before writing queries with run_query.' It also states when NOT to use it ('You do not need this tool for basic planet searches') and offers an alternative for discovering all tables via run_query with a specific query. This is textbook usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve any planet or star name, alias, or catalog identifier to its canonical name in the NASA Exoplanet Archive. Returns all known aliases grouped by catalog (Gaia, TIC, KOI, 2MASS, HD, HIP, etc.) and lists all confirmed planets in the system.
Use this BEFORE get_planet or search_planets when the user provides a name that might not match the archive's naming convention. Common cases: missing spaces ('Kepler-22b' vs 'Kepler-22 b'), catalog IDs ('TIC 150428135'), alternate designations ('GJ 1214' vs 'Gliese 1214'), or informal names.
Also useful when the user wants to know all designations for a star or system.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Any planet name, star name, or catalog identifier to look up (e.g., 'Kepler-22b', 'TIC 150428135', 'GJ 1214', 'HD 209458'). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/openWorld/idempotent safety, so the description adds value by disclosing return behavior: aliases grouped by catalog (Gaia, TIC, KOI, etc.) and confirmed planets in the system. This goes beyond the annotations without contradicting them, though it could have mentioned any pagination or error behavior if relevant.
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 efficiently written in three short paragraphs, each earning its place: the first states the purpose and return value, the second gives usage context with concrete examples, and the third covers an additional use case. No redundant or filler content appears.
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 simplicity (one parameter), the presence of an output schema, and comprehensive annotations, the description covers all essential operational context: what it resolves, what it returns, when to prefer it over siblings, and an extra scenario ('all designations'). It fully equips an agent to invoke it 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?
The schema already provides 100% coverage for the single 'name' parameter with its own examples and description. The tool description reinforces the same concepts but adds no new semantic detail beyond what the schema already conveys, so the baseline 3 applies.
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 specifies the tool's action ('Resolve') and resource ('any planet or star name, alias, or catalog identifier') and states the outcome ('canonical name'). It explicitly distinguishes itself from sibling tools by instructing to use it BEFORE get_planet or search_planets, making its unique role clear.
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?
It provides explicit when-to-use guidance ('when the user provides a name that might not match the archive's naming convention') and cites specific problem cases like missing spaces and alternate designations. It also names the alternative tools (get_planet, search_planets) that this should precede, fulfilling the when/alternatives requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a raw ADQL query against the NASA Exoplanet Archive TAP service. ADQL is an SQL-like language for astronomical databases. Use this for complex queries that search_planets cannot handle: GROUP BY aggregations, COUNT statistics, JOINs across tables, spatial/cone searches, queries against non-planet tables (toi, transitspec, emissionspec, ml, Kepler KOI tables), or any query needing full SQL-like flexibility.
Use list_tables and list_columns first to discover available tables and column names. Common tables: pscomppars (one row per confirmed planet), ps (all published solutions — filter with default_flag=1 for one per planet), stellarhosts (host stars), toi (TESS candidates), transitspec (atmospheric transit spectra), emissionspec (atmospheric emission spectra), ml (microlensing planets).
ADQL supports: SELECT, WHERE, ORDER BY, GROUP BY, COUNT, JOIN, LIKE, BETWEEN, IS NULL, IS NOT NULL, TOP, mathematical functions, and spatial functions (CONTAINS, POINT, CIRCLE for cone searches). Example cone search: WHERE CONTAINS(POINT('ICRS',ra,dec), CIRCLE('ICRS',291.0,48.0,5.0))=1
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum rows to return (1-1000, default 100). Applied as maxrec parameter. You can also use TOP N in your ADQL SELECT clause. | |
| query | Yes | ADQL query string. Example: SELECT pl_name, pl_rade, pl_bmasse FROM pscomppars WHERE pl_rade < 2 AND pl_bmasse IS NOT NULL ORDER BY pl_rade |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, open-world, idempotent, and non-destructive. The description adds substantial behavioral context: it's a raw ADQL executor with SQL-like flexibility, lists supported functions, provides a cone-search example, and clarifies table semantics. It does not contradict annotations, though it stops short of detailing rate limits or error 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 appropriately detailed for a complex query tool. It is front-loaded with the core purpose, then systematically covers when to use, prerequisites, table inventory, supported syntax, and an example—every sentence adds value without fluff.
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 two parameters, an output schema, and rich annotations, the description is outstandingly complete. It covers the query language, common table names, example queries, and explicitly differentiates from sibling tools. The agent has everything needed to invoke it correctly and interpret results.
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 100%, so baseline is 3. The description goes beyond schema by explaining the ADQL dialect, giving a cone-search example, and describing common tables and their meanings—all of which help the agent construct a correct 'query' string. The 'limit' parameter is effectively explained via 'maxrec' and 'TOP N' mention.
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 opens with a specific verb and resource: 'Execute a raw ADQL query against the NASA Exoplanet Archive TAP service.' It clearly distinguishes the tool from search_planets by listing advanced use cases like GROUP BY, JOINs, and spatial/cone searches that the simpler tool cannot handle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided on when to use this tool versus alternatives: 'Use this for complex queries that search_planets cannot handle' with concrete examples. It also advises a discovery workflow ('Use list_tables and list_columns first') and names common tables, giving clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for exoplanets in NASA's Exoplanet Archive with flexible filters. Returns matching planets from the Planetary Systems Composite Parameters table (one row per confirmed planet, best-available measurements).
This is the primary tool for most exoplanet questions. All filter parameters are optional and can be combined. If no filters are given, returns the most recently discovered planets.
For single-planet lookups by exact name, use get_planet instead. For complex queries needing GROUP BY, JOIN, spatial/cone searches, or querying tables other than the main planet catalog, use run_query instead.
If a name-based search returns no results, the name may need resolving — try resolve_name first to find the canonical archive name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Planet name to search for. Supports partial matching (e.g., 'Kepler-22' matches 'Kepler-22 b'). For exact single-planet lookup with full details, use the get_planet tool instead. | |
| limit | No | Maximum results to return (1-500, default 25). | |
| offset | No | Number of results to skip, for pagination. | |
| columns | No | Columns to return. Defaults to a curated set of key properties. Use list_columns to discover all 300+ available columns. | |
| facility | No | Discovery facility or mission name (e.g., 'Transiting Exoplanet Survey Satellite (TESS)', 'Kepler', 'W. M. Keck Observatory'). Partial match supported. | |
| hostname | No | Host star name (e.g., 'TRAPPIST-1', 'Kepler-442'). Returns all planets in that system. | |
| max_mass | No | Maximum planet mass in Earth masses. | |
| min_mass | No | Minimum planet mass in Earth masses. Earth=1.0, Neptune~17.1, Jupiter~317.8. Uses best-available mass (true mass if known, otherwise minimum mass M*sin(i)). | |
| order_by | No | Column to sort by. Prefix with '-' for descending order. Examples: 'sy_dist' (nearest first), '-sy_dist' (farthest first), '-disc_year' (most recent first), 'pl_rade' (smallest first), '-pl_rade' (largest first), '-pl_bmasse' (most massive first), '-pl_eqt' (hottest first), 'pl_eqt' (coolest first), '-pl_orbeccen' (most eccentric first), '-pl_dens' (densest first). | |
| year_max | No | Latest discovery year (e.g., 2025). | |
| year_min | No | Earliest discovery year (e.g., 2020). | |
| max_period | No | Maximum orbital period in days. | |
| max_radius | No | Maximum planet radius in Earth radii. | |
| min_period | No | Minimum orbital period in days. Earth~365.25, Jupiter~4333. | |
| min_radius | No | Minimum planet radius in Earth radii. Earth=1.0, Neptune~3.9, Jupiter~11.2. | |
| max_distance | No | Maximum distance from Earth in parsecs. | |
| min_distance | No | Minimum distance from Earth in parsecs. 1 parsec ~ 3.26 light-years. | |
| max_temperature | No | Maximum equilibrium temperature in Kelvin. | |
| min_temperature | No | Minimum equilibrium temperature in Kelvin. Earth~255K. Habitable zone roughly 200-320K. | |
| discovery_method | No | How the planet was detected. One of: Transit, Radial Velocity, Microlensing, Imaging, Transit Timing Variations, Eclipse Timing Variations, Orbital Brightness Modulation, Pulsar Timing, Astrometry, Disk Kinematics, Pulsation Timing Variations. | |
| min_planets_in_system | No | Minimum number of planets in the system. Use 2+ for multi-planet systems. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds useful context: the data source table, one row per confirmed planet with best-available measurements, and default behavior of returning most recently discovered planets when no filters are given. This goes beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured into four concise paragraphs: overview, primary usage, alternatives, and an edge-case hint. Every sentence carries meaningful information without padding, making it easy for an agent to parse quickly.
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 21 optional parameters, an output schema, and multiple sibling tools, the description fully covers what the tool does, when to use it, how it behaves by default, and how to recover from empty name searches. The existence of an output schema means return-value details are not necessary here, so no significant gaps remain.
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 100% and each parameter has a detailed description with examples, so the baseline is 3. The description adds extra semantic guidance by stating that all filter parameters are optional and combinable, and by noting that no filters returns recent discoveries. This enriches parameters as a group even though individual parameter details live in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Search for exoplanets in NASA's Exoplanet Archive with flexible filters') and identifies the exact data table returned. It clearly distinguishes itself from siblings by calling itself 'the primary tool for most exoplanet questions' and pointing to get_planet and run_query for alternative use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when/when-not guidance is provided: use for general exoplanet searches, use get_planet for single-planet exact lookups, use run_query for complex queries, and try resolve_name when name searches fail. This goes beyond vague usage hints and names specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_planetlist_columnslist_tablesresolve_namerun_querysearch_planetsEach tool targets a distinct operation: exact lookup (get_planet), filtered search (search_planets), name resolution (resolve_name), metadata discovery (list_tables, list_columns), and raw ADQL access (run_query). The descriptions clearly delineate when to use each, with explicit cross-references to prevent confusion.
All tool names follow the verb_noun convention: get_planet, search_planets, resolve_name, list_tables, list_columns, run_query. The naming is consistent, lowercase with underscores, and each verb clearly indicates the action.
With 6 tools, the server is well-scoped for its purpose of accessing NASA's exoplanet archive. Each tool serves a distinct and necessary role, covering basic and advanced querying, name resolution, and metadata exploration without unnecessary redundancy.
The tool set provides comprehensive coverage of the exoplanet archive domain: searching, retrieving detailed planet data, resolving aliases, exploring available tables and columns, and executing arbitrary ADQL queries for advanced needs. No obvious gaps exist—raw query access fills any niche not covered by the higher-level tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server for live public-data APIs and Skills for AI agents.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
An MCP server that gives your AI access to the source code and docs of all public github repos
Real-time planetary signal engine and Model Context Protocol (MCP) server for autonomous AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/saikrmet/nasa-exoplanet-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
