The NASA MCP Server provides a standardized interface to access various NASA APIs and data sources. With this server, you can:
Fetch NASA's Astronomy Picture of the Day (APOD)
Retrieve Mars Rover photos from Curiosity, Opportunity, Spirit, or Perseverance
Access Near Earth Object (NEO) data and close approaches
View Earth Polychromatic Imaging Camera (EPIC) images
Download satellite imagery from Global Imagery Browse Services (GIBS) and Landsat
Search NASA's Common Metadata Repository (CMR) for data collections
Get fire data from the Fire Information for Resource Management System (FIRMS)
Search NASA's Image and Video Library for media
Query the NASA Exoplanet Archive for data on planets beyond our solar system
Access space weather data from the DONKI database
Track natural events with the Earth Observatory Natural Event Tracker (EONET)
Fetch meteorological data from the POWER API
Access asteroid and comet data from JPL's Small-Body Database (SBDB)
Retrieve fireball and atmospheric impact event data
Convert between Julian Day numbers and calendar dates
Generate ephemeris data for solar system objects with JPL Horizons
Query JPL's Three-Body Periodic Orbits Database
Access data files for NASA Open Science Data Repository (OSDR) studies
Provides access to 20+ NASA data sources including APOD, Mars Rover Photos, EPIC, DONKI, NEO, EONET, TLE, JPL Solar System Dynamics, Earth Data APIs, and POWER, allowing AI models to retrieve and process space imagery, celestial object data, and Earth observation information through a standardized interface.
Implements input validation and sanitization for NASA API requests using Zod schemas to ensure proper formatting and security.
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 MCP Server show me today's astronomy picture of the day"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for NASA APIs, providing a standardized interface for AI models to interact with NASA's vast array of data sources. This server implements the official Model Context Protocol specification.
Big thanks to the MCP community for their support and guidance!
Access to 20+ NASA data sources through a single, consistent interface
Standardized data formats optimized for AI consumption
Automatic parameter validation and error handling
Rate limit management for NASA API keys
Comprehensive documentation and examples
Support for various NASA imagery formats
Data conversion and formatting for LLM compatibility
Cross-platform support (Windows, macOS, Linux)
Related MCP server: NASA APOD MCP Server
This project is not affiliated with, endorsed by, or related to NASA (National Aeronautics and Space Administration) or any of its subsidiaries or its affiliates. It is an independent implementation that accesses NASA's publicly available APIs. All NASA data used is publicly available and subject to NASA's data usage policies.
env NASA_API_KEY=YOUR_API_KEY npx -y @programcomputer/nasa-mcp-server@latestYou can also pass the API key as a command line argument:
npx -y @programcomputer/nasa-mcp-server@latest --nasa-api-key=YOUR_API_KEY# Clone the repository
git clone https://github.com/ProgramComputer/NASA-MCP-server.git
# Install dependencies
cd NASA-MCP-server
npm install
# Run with your API key
NASA_API_KEY=YOUR_API_KEY npm startReplace YOUR_API_KEY with your NASA API key from https://api.nasa.gov/.
The server can be configured with the following environment variables:
Variable | Description |
| Your NASA API key (get at api.nasa.gov) |
| Transport mode: |
| Host for Streamable HTTP mode (default: |
| Port for Streamable HTTP mode (default: |
| MCP endpoint path for Streamable HTTP mode (default: |
By default, the server runs over stdio for local MCP clients such as Cursor and Claude Desktop.
To run the optional Streamable HTTP transport:
MCP_TRANSPORT=http MCP_HTTP_PORT=3000 NASA_API_KEY=YOUR_API_KEY npm startThe Streamable HTTP endpoint will be available at:
http://127.0.0.1:3000/mcpThis MCP server integrates the following NASA APIs:
NASA Open API (api.nasa.gov):
APOD (Astronomy Picture of the Day)
EPIC (Earth Polychromatic Imaging Camera)
DONKI (Space Weather Database Of Notifications, Knowledge, Information)
Insight (Mars Weather Service)
Mars Rover Photos
NEO (Near Earth Object Web Service)
EONET (Earth Observatory Natural Event Tracker)
TLE (Two-Line Element)
NASA Image and Video Library
Exoplanet Archive
NASA Sounds API (Beta)
POWER (Prediction Of Worldwide Energy Resources)
JPL Solar System Dynamics API (ssd-api.jpl.nasa.gov):
SBDB (Small-Body DataBase)
SBDB Close-Approach Data
Fireball Data
Scout API
Earth Data APIs:
GIBS (Global Imagery Browse Services)
CMR (Common Metadata Repository) - Enhanced with advanced search capabilities
EPIC (Earth Polychromatic Imaging Camera)
FIRMS (Fire Information for Resource Management System)
Each NASA API is exposed through standardized MCP methods:
{
"method": "nasa/apod",
"params": {
"date": "2023-01-01", // Optional: YYYY-MM-DD format
"count": 5, // Optional: Return a specified number of random images
"thumbs": true // Optional: Return URL of video thumbnail
}
}{
"method": "nasa/mars-rover",
"params": {
"rover": "curiosity", // Required: "curiosity", "opportunity", or "spirit"
"sol": 1000, // Either sol or earth_date is required
"earth_date": "2023-01-01", // YYYY-MM-DD format
"camera": "FHAZ" // Optional: Filter by camera type
}
}{
"method": "nasa/neo",
"params": {
"start_date": "2023-01-01", // Required: YYYY-MM-DD format
"end_date": "2023-01-07" // Required: YYYY-MM-DD format (max 7 days from start)
}
}{
"method": "nasa/gibs",
"params": {
"layer": "MODIS_Terra_CorrectedReflectance_TrueColor", // Required: Layer ID
"date": "2023-01-01", // Required: YYYY-MM-DD format
"format": "png" // Optional: "png" or "jpg"
}
}{
"method": "nasa/power",
"params": {
"parameters": "T2M,PRECTOTCORR,WS10M", // Required: Comma-separated list
"community": "re", // Required: Community identifier
"latitude": 40.7128, // Required: Latitude
"longitude": -74.0060, // Required: Longitude
"start": "20220101", // Required: Start date (YYYYMMDD)
"end": "20220107" // Required: End date (YYYYMMDD)
}
}For complete documentation of all available methods and parameters, see the API reference in the /docs directory.
The server includes comprehensive logging:
Operation status and progress
Performance metrics
Rate limit tracking
Error conditions
Request validation
Example log messages:
[INFO] NASA MCP Server initialized successfully
[INFO] Processing APOD request for date: 2023-01-01
[INFO] Fetching Mars Rover data for Curiosity, sol 1000
[WARNING] Rate limit threshold reached (80%)
[ERROR] Invalid parameter: 'date' must be in YYYY-MM-DD formatThis MCP server implements security best practices following the Model Context Protocol specifications:
Input validation and sanitization using Zod schemas
No execution of arbitrary code
Protection against command injection
Proper error handling to prevent information leakage
Rate limiting and timeout controls for API requests
No persistent state that could be exploited across sessions
# Clone the repository
git clone https://github.com/ProgramComputer/NASA-MCP-server.git
# Install dependencies
npm install
# Copy the example environment file and update with your API keys
cp .env.example .env
# Build the TypeScript code
npm run build
# Start the development server
npm run dev
# Run tests
npm testThe NASA MCP Server includes a script to help you test the APIs using the MCP Inspector:
# Run the provided test script
./scripts/test-with-inspector.shThis will:
Build the project to ensure the latest changes are included
Start the MCP Inspector with the NASA MCP server running
Allow you to interactively test all the NASA APIs
The repository includes example test requests for each API that you can copy and paste into the MCP Inspector:
# View the example test requests
cat docs/inspector-test-examples.mdFor detailed examples, see the Inspector Test Examples document.
This server follows the official Model Context Protocol. For local clients, use the default stdio configuration shown above. For Streamable HTTP mode, start the server with MCP_TRANSPORT=http, then connect with the MCP SDK:
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js";
import { CallToolResultSchema } from "@modelcontextprotocol/sdk/types.js";
const transport = new StreamableHTTPClientTransport(
new URL("http://127.0.0.1:3000/mcp")
);
const client = new Client({
name: "mcp-client",
version: "1.0.0",
});
await client.connect(transport);
// Example: Get today's Astronomy Picture of the Day
const apodResult = await client.request({
method: "tools/call",
params: {
name: "nasa/apod",
arguments: {}
}
}, CallToolResultSchema);
// Example: Get Mars Rover photos
const marsRoverResult = await client.request({
method: "tools/call",
params: {
name: "nasa/mars-rover",
arguments: { rover: "curiosity", sol: 1000 }
}
}, CallToolResultSchema);
// Example: Search for Near Earth Objects
const neoResults = await client.request({
method: "tools/call",
params: {
name: "nasa/neo",
arguments: {
start_date: "2023-01-01",
end_date: "2023-01-07"
}
}
}, CallToolResultSchema);
// Example: Get satellite imagery from GIBS
const satelliteImage = await client.request({
method: "tools/call",
params: {
name: "nasa/gibs",
arguments: {
layer: "MODIS_Terra_CorrectedReflectance_TrueColor",
date: "2023-01-01"
}
}
}, CallToolResultSchema);
// Example: Use the new POWER API
const powerData = await client.request({
method: "tools/call",
params: {
name: "nasa/power",
arguments: {
parameters: "T2M,PRECTOTCORR,WS10M",
community: "re",
latitude: 40.7128,
longitude: -74.0060,
start: "20220101",
end: "20220107"
}
}
}, CallToolResultSchema);Fork the repository
Create your feature branch
Run tests: npm test
Submit a pull request
ISC License - see LICENSE file for details
Asteroid and comet close approaches to the planets in the past and future
| Name | Required | Description | Default |
|---|---|---|---|
| dist_max | No | Maximum approach distance (e.g., 0.05, 10LD). Default: 0.05 au | |
| dist_min | No | Minimum approach distance. Default: none | |
| date_min | No | Start date for search (YYYY-MM-DD). Default: now | |
| date_max | No | End date for search (YYYY-MM-DD). Default: +60 days | |
| body | No | Body to find close approaches to (e.g., Earth, Mars, ALL). Default: Earth | |
| sort | No | Sort field: date, dist, dist-min, v-inf, v-rel, h, object. Default: date | |
| des | No | Object designation (e.g., '2000 SG344' or '433') | |
| spk | No | Object SPK-ID (e.g., '2000433') | |
| neo | No | Limit to NEOs. Default: true | |
| fullname | No | Include full object name in result. Default: false |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but reveals nothing about rate limits, authentication requirements, data freshness, pagination, error conditions, or response format. For a tool with 10 parameters and no output schema, this is a significant transparency gap.
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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for the tool's complexity and gets straight to the point with zero 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?
For a tool with 10 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns, how results are structured, or provide any context about data sources or limitations. The description alone leaves too many unanswered questions for effective tool 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 description adds no parameter information beyond what's already in the schema (which has 100% coverage). It doesn't explain relationships between parameters, provide examples of valid combinations, or clarify parameter interactions. With complete schema documentation, the baseline score of 3 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 states the tool's purpose: finding asteroid and comet close approaches to planets in past and future. It specifies the resource (asteroids/comets) and action (finding close approaches), but doesn't distinguish it from sibling tools like jpl_sentry or nasa_neo which might have overlapping functionality.
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. With sibling tools like jpl_sentry (impact risk assessment), jpl_scout (NEO detection), and nasa_neo (NEO data), there's clear potential overlap, but the description offers no comparison or context for choosing this specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fireball data - atmospheric impact events
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return | |
| date_min | No | Start date (YYYY-MM-DD) | |
| date_max | No | End date (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what data is retrieved without mentioning any behavioral traits such as rate limits, authentication needs, data freshness, or response format. For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding how it operates.
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 with a single phrase, 'Fireball data - atmospheric impact events', which efficiently conveys the core purpose. It's front-loaded and wastes no words, though it could benefit from slightly more detail to improve clarity without sacrificing brevity.
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 a data retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the returned data looks like, any limitations (e.g., date ranges, data sources), or how it integrates with sibling tools. This leaves the agent with insufficient context to use the tool effectively beyond basic parameter input.
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 100% description coverage, with clear documentation for all three parameters (limit, date_min, date_max). The description adds no additional meaning beyond what the schema provides, such as default values or usage examples. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
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 as retrieving 'fireball data - atmospheric impact events', which is specific about the resource (fireball data) and domain (atmospheric impact events). However, it doesn't distinguish this tool from its siblings (like nasa_neo or nasa_donki which might also handle space-related events), so it doesn't fully differentiate from alternatives.
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 doesn't mention any specific context, prerequisites, or exclusions, and with multiple sibling tools available (e.g., nasa_neo for near-Earth objects, nasa_donki for space weather), there's no indication of how this tool fits into the broader set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JPL Horizons - Solar system objects ephemeris data
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Response format (json, text) | |
| COMMAND | Yes | Target object identifier (e.g., '499' for Mars, '1' for Ceres, 'C/2020 F3' for Comet NEOWISE) | |
| OBJ_DATA | No | Include object data | |
| MAKE_EPHEM | No | Generate ephemeris | |
| EPHEM_TYPE | No | Type of ephemeris (OBSERVER, VECTORS, ELEMENTS) | |
| CENTER | No | Coordinate center (e.g., '500@399' for Earth) | |
| START_TIME | No | Start time for ephemeris (e.g., '2023-01-01') | |
| STOP_TIME | No | Stop time for ephemeris (e.g., '2023-01-02') | |
| STEP_SIZE | No | Step size for ephemeris points (e.g., '1d' for daily, '1h' for hourly) | |
| QUANTITIES | No | Observable quantities to include (e.g., 'A' for all, or '1,2,20,23' for specific ones) | |
| OUT_UNITS | No | Output units for vector tables |
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 mentions 'ephemeris data', implying a read-only query, but doesn't specify rate limits, authentication needs, data freshness, or error handling. For a tool with 11 parameters and no output schema, this lack of operational context is a significant gap.
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—a single phrase that efficiently conveys the core function. It's front-loaded with no wasted words, making it easy to parse. This is appropriate given the detailed schema, though it may be too brief for full context.
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 (11 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what ephemeris data includes, how results are structured, or typical use cases. While the schema covers inputs, the lack of output details and behavioral context makes this inadequate for a tool of this sophistication.
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%, so parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond implying ephemeris generation. This meets the baseline of 3, as the schema does the heavy lifting, but the description doesn't compensate with examples or clarification of complex parameters like 'CENTER' or 'QUANTITIES'.
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: 'JPL Horizons - Solar system objects ephemeris data'. It specifies the verb (providing ephemeris data) and resource (solar system objects), making it understandable. However, it doesn't differentiate from siblings like 'jpl_horizons_file' or 'jpl_sbdb', which likely serve related but distinct purposes in the JPL ecosystem.
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. With many sibling tools (e.g., 'jpl_cad', 'jpl_sbdb', 'nasa_neo'), there's no indication of context, prerequisites, or exclusions. This leaves the agent to guess based on tool names alone, which is insufficient for effective selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JPL Horizons - Solar system objects ephemeris data (File Input)
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Response format (json, text) | |
| COMMAND | Yes | Target object identifier (e.g., '499' for Mars, '1' for Ceres, 'C/2020 F3' for Comet NEOWISE) | |
| OBJ_DATA | No | Include object data | |
| MAKE_EPHEM | No | Generate ephemeris | |
| EPHEM_TYPE | No | Type of ephemeris (OBSERVER, VECTORS, ELEMENTS) | |
| CENTER | No | Coordinate center (e.g., '500@399' for Earth) | |
| START_TIME | No | Start time for ephemeris (e.g., '2023-01-01') | |
| STOP_TIME | No | Stop time for ephemeris (e.g., '2023-01-02') | |
| STEP_SIZE | No | Step size for ephemeris points (e.g., '1d' for daily, '1h' for hourly) | |
| QUANTITIES | No | Observable quantities to include (e.g., 'A' for all, or '1,2,20,23' for specific ones) | |
| OUT_UNITS | No | Output units for vector tables |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'File Input' but doesn't clarify what that entails—whether it generates downloadable files, requires file uploads, or has specific output handling. There's no information on rate limits, authentication needs, error conditions, or what the tool returns (since no output schema exists). The description is too minimal for a tool with 11 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 a single, efficient phrase that gets straight to the point without unnecessary words. It's appropriately sized for a tool name but could be more informative. However, it's front-loaded and wastes no space on repetition or 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?
Given the complexity (11 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the tool's behavior, output format, or how it differs from similar tools. For a data retrieval tool with many configuration options, more context is needed to help an agent use it effectively, especially without annotations or output schema to fill 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 description coverage is 100%, so the schema already documents all parameters thoroughly with descriptions and enums. The description adds no additional parameter semantics beyond what's in the schema—it doesn't explain relationships between parameters, default behaviors, or practical examples. With high schema coverage, the baseline is 3, but the description doesn't compensate with extra insights.
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 the tool provides 'Solar system objects ephemeris data (File Input)' from JPL Horizons, which indicates it retrieves positional/observational data for celestial bodies. However, it's vague about what 'File Input' means specifically and doesn't differentiate from sibling tools like 'jpl_horizons' (which likely provides similar functionality). The description lacks a clear verb and specific resource scope.
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. With multiple JPL Horizons-related siblings (e.g., 'jpl_horizons', 'jpl_cad', 'jpl_sbdb'), the description doesn't explain what makes this tool unique or when it's the appropriate choice. There's no mention of prerequisites, constraints, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Julian Day number to/from calendar date/time converter
| Name | Required | Description | Default |
|---|---|---|---|
| jd | No | Julian date to convert to calendar date | |
| cd | No | Calendar date to convert to Julian date (YYYY-MM-DD or YYYY-MM-DDThh:mm:ss format) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the conversion function but doesn't cover error handling, input validation, performance characteristics, or output format. For a tool with no annotations, this leaves significant gaps in understanding how it behaves beyond the basic operation.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent to quickly understand the core functionality.
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 no annotations, no output schema, and a tool that performs conversions (which may involve error cases or format specifics), the description is incomplete. It doesn't explain what the output looks like, how to handle invalid inputs, or any limitations, making it inadequate for full contextual understanding.
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%, so the schema already documents both parameters (jd and cd) with their purposes and formats. The description adds no additional parameter semantics beyond what's in the schema, such as examples, constraints, or interdependencies, meeting the baseline for high schema coverage.
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 function as a converter between Julian Day numbers and calendar date/time, using specific verbs ('to/from converter'). It distinguishes from most siblings by focusing on date conversion rather than astronomical data retrieval or imagery, though it doesn't explicitly differentiate from similar conversion tools if any exist.
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. The description doesn't mention prerequisites, typical use cases, or how it compares to other date conversion methods or tools in the sibling list, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Human-accessible NEOs (Near-Earth Objects) data
| Name | Required | Description | Default |
|---|---|---|---|
| dv | No | Minimum total delta-V (km/s). Values: 4-12, default: 12 | |
| dur | No | Minimum total mission duration (days). Values: 60-450, default: 450 | |
| stay | No | Minimum stay time (days). Values: 8, 16, 24, 32, default: 8 | |
| launch | No | Launch window (year range). Values: 2020-2025, 2025-2030, 2030-2035, 2035-2040, 2040-2045, 2020-2045, default: 2020-2045 | |
| h | No | Object's maximum absolute magnitude (mag). Values: 16-30 | |
| occ | No | Object's maximum orbit condition code. Values: 0-8 | |
| des | No | Object designation (e.g., '2000 SG344' or '433') | |
| spk | No | Object SPK-ID (e.g., '2000433') | |
| plot | No | Include base-64 encoded plot image |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'human-accessible' data, which hints at usability but does not specify whether this is a read-only operation, what data format is returned, potential rate limits, or authentication needs. For a tool with 9 parameters and no annotations, this is a significant gap in transparency.
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, efficient phrase: 'Human-accessible NEOs (Near-Earth Objects) data'. It is front-loaded and wastes no words, making it highly concise and well-structured for its limited content.
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 (9 parameters, no output schema, no annotations), the description is incomplete. It does not explain what the tool returns (e.g., data format, structure), how to interpret results, or behavioral aspects like error handling. This leaves significant gaps for an agent to use the tool 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?
The input schema has 100% description coverage, with detailed explanations for each parameter (e.g., 'dv' as minimum delta-V, 'plot' for including an image). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 where 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 'Human-accessible NEOs (Near-Earth Objects) data' states the resource (NEO data) but lacks a specific verb indicating what action the tool performs (e.g., retrieve, filter, analyze). It distinguishes from siblings like 'jpl_cad' or 'nasa_neo' by specifying 'human-accessible' and 'NEOs', but the purpose remains vague without an action verb.
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 any context, prerequisites, or exclusions, nor does it differentiate from sibling tools like 'jpl_sentry' or 'nasa_neo' that might also handle NEO data. This leaves the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JPL Three-Body Periodic Orbits Database
| Name | Required | Description | Default |
|---|---|---|---|
| sys | Yes | Three-body system (e.g., earth-moon, sun-earth) | |
| family | Yes | Orbit family name (e.g., halo, dro, lyapunov) | |
| libr | No | Libration point (1-5, required for some families) | |
| branch | No | Branch within family (N/S, E/W, etc., required for some families) | |
| periodmin | No | Minimum period | |
| periodmax | No | Maximum period | |
| periodunits | No | Units for period (s, h, d, TU) | |
| jacobimin | No | Minimum Jacobi constant | |
| jacobimax | No | Maximum Jacobi constant | |
| stabmin | No | Minimum stability index | |
| stabmax | No | Maximum stability index |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to do so. It doesn't describe whether this is a read-only query, a data retrieval operation, or if it has any side effects like rate limits or authentication needs. For a tool with 11 parameters and no output schema, this lack of transparency is a significant gap.
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 phrase, which is concise but under-specified rather than efficiently informative. It's front-loaded but lacks substance, failing to earn its place with useful details. While not verbose, it's too brief to be helpful, balancing between conciseness and inadequacy.
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 (11 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns, how results are structured, or any behavioral traits. For a database query tool with rich input parameters, more context is needed to guide the agent effectively, making this description insufficient for the tool's scope.
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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond what the schema provides, such as explaining relationships between parameters (e.g., how 'libr' interacts with 'family'). Baseline 3 is appropriate since the schema does the heavy lifting, but the description doesn't compensate or enhance understanding.
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 'JPL Three-Body Periodic Orbits Database' restates the tool name with minimal elaboration, making it tautological. It lacks a specific verb or action (e.g., 'query', 'search', 'retrieve'), leaving the tool's function vague. While it hints at accessing a database, it doesn't clarify what the tool actually does with the data, distinguishing it poorly from siblings like 'jpl_horizons' or 'nasa_neo'.
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 doesn't mention any context, prerequisites, or exclusions, such as when to choose it over other JPL or NASA tools for orbital data. This absence leaves the agent without direction for appropriate tool selection among the many siblings listed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Small-Body Database (SBDB) - asteroid and comet data
| Name | Required | Description | Default |
|---|---|---|---|
| sstr | Yes | Search string (e.g., asteroid name, number, or designation) | |
| cad | No | Include close approach data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what data is accessed without describing how: no information about rate limits, authentication requirements, data freshness, error conditions, or response format. For a data query tool with zero annotation coverage, this leaves significant behavioral gaps.
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 - just one phrase stating the tool's purpose. It's front-loaded with the essential information. However, given the complexity of astronomical data tools and lack of behavioral context, this brevity might be under-specified rather than optimally concise.
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 data query tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what data is returned, in what format, or any limitations. Given the rich sibling tool ecosystem and the complexity of astronomical data, more context about the scope and boundaries of this specific tool would be helpful.
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 100% description coverage, so both parameters are well-documented in the schema. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
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: accessing asteroid and comet data from the Small-Body Database (SBDB). It specifies the resource (asteroid/comet data) and source (SBDB), but doesn't distinguish it from sibling tools like 'jpl_horizons' or 'nasa_neo' which might also provide asteroid data. The description is accurate but lacks sibling differentiation.
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. With multiple sibling tools potentially offering related astronomical data (e.g., 'jpl_horizons', 'nasa_neo'), there's no indication of when this specific SBDB tool is appropriate versus others. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scout - NEOCP orbits, ephemerides, and impact risk data
| Name | Required | Description | Default |
|---|---|---|---|
| tdes | No | Object temporary designation (e.g., P21Eolo) | |
| orbit_id | No | Scout internal orbit ID | |
| limit | No | Limit number of results | |
| file | No | Type of data file to return (summary, ephem, obs, crit, all) | |
| plot | No | Include plots in the response | |
| summary | No | Include summary data in the response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the types of data returned but lacks critical details such as authentication requirements, rate limits, error handling, or whether this is a read-only or mutating operation. For a tool with no annotation coverage, this is a significant gap.
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, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence earns its place by specifying the data types retrieved, making it appropriately sized and well-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, no output schema, no annotations), the description is minimally adequate. It states what data is retrieved but lacks details on behavioral traits, usage context, and output format. With no output schema, it should ideally explain return values more, but the purpose is clear enough for basic 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 input schema has 100% description coverage, so the schema already documents all six parameters thoroughly. The description does not add any additional meaning or context beyond what the schema provides, such as explaining relationships between parameters or usage examples. Baseline 3 is appropriate when 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 clearly states the tool's purpose as retrieving 'NEOCP orbits, ephemerides, and impact risk data' with the verb 'Scout', which is specific and informative. However, it doesn't explicitly differentiate from sibling tools like 'jpl_sentry' or 'nasa_neo' that might handle similar Near-Earth Object data, missing full sibling distinction.
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. With many sibling tools available (e.g., jpl_sentry, nasa_neo), there is no mention of specific contexts, prerequisites, or exclusions for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JPL Sentry - NEO Earth impact risk assessment data
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return | |
| date_min | No | Start date (YYYY-MM-DD) | |
| date_max | No | End date (YYYY-MM-DD) | |
| des | No | Object designation (e.g., '2011 AG5' or '29075') | |
| spk | No | Object SPK-ID | |
| h_max | No | Maximum absolute magnitude (size filter) | |
| ps_min | No | Minimum Palermo Scale value | |
| ip_min | No | Minimum impact probability | |
| removed | No | Get objects removed from Sentry monitoring | |
| all | No | Get all virtual impactors data |
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. The description mentions 'data' but doesn't specify whether this is a read-only query, what format the data returns (e.g., JSON, risk tables), whether there are rate limits, authentication requirements, or what happens with the various filtering parameters. For a 10-parameter query tool with no annotation coverage, this is a significant gap in behavioral context.
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, efficient sentence that states the tool's purpose and domain. It's appropriately sized for a data query tool and front-loaded with the key information. There's no wasted verbiage or unnecessary elaboration, though it could potentially benefit from slightly more context about the data format or source.
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 (10 parameters, no annotations, no output schema), the description is insufficiently complete. It doesn't explain what kind of data structure to expect, whether results are paginated, what the default behavior is when no parameters are provided, or how the various filters interact. For a rich query tool with multiple filtering options and no output schema, more contextual information is needed to help an agent 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 description coverage is 100%, so all 10 parameters are documented in the schema itself. The description adds no additional parameter semantics beyond the schema's descriptions (e.g., it doesn't explain what 'Palermo Scale' or 'virtual impactors' mean in context). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't need to since 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 clearly states the tool provides 'NEO Earth impact risk assessment data' which specifies the resource (Near-Earth Object risk data) and domain (JPL Sentry system). It distinguishes from siblings like jpl_cad or jpl_horizons by focusing on impact risk rather than orbital data or ephemerides. However, it doesn't specify the exact verb (e.g., 'retrieve' or 'query') which prevents a perfect score.
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. With siblings like jpl_neo, jpl_scout, and nasa_neo that might overlap with NEO data, there's no indication of what makes Sentry unique (e.g., focused on impact risk assessment versus general NEO catalog). No explicit when/when-not statements or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch NASA's Astronomy Picture of the Day
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | The date of the APOD image to retrieve (YYYY-MM-DD) | |
| count | No | Count of random APODs to retrieve | |
| start_date | No | Start date for date range search (YYYY-MM-DD) | |
| end_date | No | End date for date range search (YYYY-MM-DD) | |
| thumbs | No | Return URL of thumbnail for video content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'fetch', implying a read operation, but does not disclose behavioral traits like rate limits, authentication needs, response format, or whether it's a safe operation. This is a significant gap for a tool with no annotation coverage.
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, efficient sentence with zero waste, front-loaded and appropriately sized for its purpose. Every word earns its place, making it highly concise and well-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 no annotations and no output schema, the description is incomplete. It does not explain return values, error handling, or behavioral context, which is inadequate for a tool with 5 parameters and potential complexity in fetching data. More detail is needed to compensate for the lack of structured data.
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%, so the schema fully documents all 5 parameters. The description adds no additional meaning beyond the schema, such as explaining interactions between parameters (e.g., 'date' vs. 'start_date'/'end_date'). Baseline 3 is appropriate as the schema handles 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 clearly states the verb 'fetch' and the resource 'NASA's Astronomy Picture of the Day', making the purpose specific and understandable. However, it does not differentiate from sibling tools like 'nasa_images' or 'nasa_epic', which might also fetch NASA images, so it lacks explicit sibling distinction.
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 sibling tools like 'nasa_images' or 'nasa_epic'. There is no mention of context, exclusions, or prerequisites, leaving usage entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NASA Common Metadata Repository - search for NASA data collections
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Search keyword | |
| search_type | Yes | Search type (collections or granules) | collections |
| format | Yes | Response format | json |
| limit | No | Maximum number of results to return | |
| page | No | Page number for pagination | |
| sort_key | No | Field to sort results by |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but only states it's a search tool. It doesn't mention whether this is a read-only operation, what authentication might be required, rate limits, pagination behavior beyond the page parameter, or what the response structure looks like. For a search tool with 6 parameters and no annotations, this is inadequate.
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 - a single sentence that efficiently communicates the core purpose. There's no wasted language or unnecessary elaboration, making it easy 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 search tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what kind of results to expect, how pagination works, what the different search types mean, or provide any context about the NASA CMR system. The agent would need to guess about important behavioral aspects.
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 description doesn't add any parameter-specific information beyond what's already in the schema (which has 100% coverage). It doesn't explain the relationship between parameters like search_type and format, or provide examples of keyword usage. With complete schema coverage, the baseline is 3, but no additional value is added.
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 as searching for NASA data collections in the Common Metadata Repository, specifying both the action (search) and resource (NASA data collections). However, it doesn't explicitly differentiate this from sibling tools like nasa_images or nasa_apod, which also involve NASA data but serve different purposes.
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 doesn't mention when this search tool is appropriate compared to other NASA data tools in the sibling list, nor does it specify any prerequisites or exclusions for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Space Weather Database Of Notifications, Knowledge, Information
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Type of space weather event | |
| startDate | No | Start date (YYYY-MM-DD) | |
| endDate | No | End date (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, the description fails to describe any behavioral traits such as whether this is a read-only or mutating operation, what permissions or authentication might be required, rate limits, or what the output format looks like. It only states what the database contains without explaining how the tool interacts with it, making it inadequate for a tool with no annotation coverage.
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 phrase that is under-specified rather than concise. It fails to front-load critical information such as the tool's action or purpose, and the phrase does not earn its place by adding value beyond the tool name. While it is brief, it lacks the structure and informative content needed for effective tool selection, making it inefficient rather than appropriately concise.
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 a space weather database tool with 3 parameters, no annotations, and no output schema, the description is incomplete. It does not explain what the tool does, how to use it, what behavior to expect, or what the output will contain. The lack of annotations and output schema means the description should compensate by providing more context, but it fails to do so, leaving significant gaps for the agent.
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 100% description coverage, with clear documentation for all three parameters (type, startDate, endDate). The description does not add any meaning beyond what the schema provides, as it does not mention parameters at all. According to the rules, when schema_description_coverage is high (>80%), the baseline score is 3 even with no parameter info in the description, which applies here.
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 'Space Weather Database Of Notifications, Knowledge, Information' is essentially a tautology that restates the tool name 'nasa_donki' (which stands for 'Database Of Notifications, Knowledge, Information'). It does not specify what action the tool performs (e.g., 'retrieve', 'search', 'list') or what resource it operates on beyond the vague 'space weather' reference. While it hints at a database related to space weather, it lacks a clear verb+resource statement that distinguishes it from sibling tools like 'nasa_apod' or 'nasa_neo'.
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 any context, prerequisites, or exclusions for usage, nor does it reference sibling tools. For example, it does not clarify if this is for querying historical data, real-time alerts, or specific types of space weather events compared to other NASA tools. This leaves the agent with no explicit or implied usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Earth Observatory Natural Event Tracker - natural events data
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Event category (wildfires, volcanoes, etc.) | |
| days | No | Number of days to look back | |
| source | No | Data source | |
| status | No | Event status (open, closed) | |
| limit | No | Maximum number of events to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states it's a tracker for natural events data, without detailing whether it's read-only, has rate limits, authentication needs, or what the output format might be. This is insufficient for a tool with 5 parameters and no output schema, leaving key behaviors unspecified.
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 concise with a single phrase, front-loaded with the tool's name and purpose. However, it could be more structured by explicitly stating the action (e.g., 'retrieve' or 'search') to improve clarity without adding unnecessary length.
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 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain return values, error handling, or usage context, which are critical for an agent to invoke the tool correctly. More detail is needed to compensate for the lack of structured data.
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%, so the input schema fully documents all 5 parameters. The description adds no additional meaning beyond the schema, such as explaining relationships between parameters or default behaviors. Baseline 3 is appropriate since the schema handles parameter documentation adequately.
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 'Earth Observatory Natural Event Tracker - natural events data' states the tool's purpose but is vague. It identifies the domain (natural events data) and hints at tracking, but lacks a specific verb like 'retrieve' or 'search' and doesn't distinguish from siblings like nasa_firms or nasa_donki. It's not tautological but lacks precision.
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. The description doesn't mention context, prerequisites, or exclusions, and sibling tools like nasa_firms or nasa_donki might overlap in natural event tracking without clarification. This leaves the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Earth Polychromatic Imaging Camera - views of Earth
| Name | Required | Description | Default |
|---|---|---|---|
| collection | No | Image collection (natural or enhanced) | |
| date | No | Date of the image (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'views of Earth' but does not specify whether this is a read-only operation, what the output format is (e.g., images, metadata), or any constraints like rate limits or authentication needs. The description is minimal and lacks critical behavioral details for a tool with 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 with a single phrase, making it efficient and front-loaded. However, it is under-specified rather than optimally concise, as it lacks necessary details for clarity and usage. Every word earns its place, but the description is too brief to be fully helpful.
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 2 parameters, no annotations, and no output schema, the description is incomplete. It does not explain what the tool returns (e.g., image URLs, metadata), how to interpret results, or any behavioral aspects. For a data retrieval tool with parameters, this minimal description leaves significant gaps in understanding.
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%, so the input schema fully documents the two parameters ('collection' and 'date'). The description adds no additional meaning beyond what the schema provides, such as explaining valid collection types or date ranges. With high schema coverage, the baseline score is 3, as the description does not compensate but also does not detract.
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 'Earth Polychromatic Imaging Camera - views of Earth' identifies the resource (Earth imagery from EPIC) but lacks a specific action verb. It distinguishes from siblings like 'nasa_apod' or 'nasa_images' by specifying the EPIC source, but the purpose remains vague without stating what the tool does (e.g., retrieve, list, or display images).
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. The description does not mention context, prerequisites, or exclusions, and it fails to differentiate from sibling tools like 'nasa_images' or 'nasa_gibs' that might also provide Earth imagery. Usage is implied only by the tool name and description, with no explicit instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NASA Exoplanet Archive - data about planets beyond our solar system
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Database table to query | |
| select | No | Columns to return | |
| where | No | Filter conditions | |
| order | No | Ordering of results | |
| limit | No | Maximum number of results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what data the tool accesses, without mentioning how it behaves—such as whether it's read-only, requires authentication, has rate limits, or what format the results are in. For a data query tool with no annotation coverage, this leaves significant gaps in understanding its operational traits.
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 and front-loaded, consisting of a single sentence that directly states the tool's purpose. There is no wasted language or unnecessary elaboration, making it efficient and easy 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?
Given the complexity of a data query tool with 5 parameters and no annotations or output schema, the description is incomplete. It lacks details on behavior, usage context, and result format, which are crucial for effective tool invocation. While the schema covers parameters well, the overall context for using the tool 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?
The description adds no information about parameters beyond what the input schema provides. Since schema description coverage is 100%, the baseline score is 3. The schema already documents all parameters (table, select, where, order, limit) with clear descriptions, so the description doesn't need to compensate, but it also doesn't enhance understanding of parameter usage or examples.
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: accessing data from the NASA Exoplanet Archive about exoplanets. It specifies the resource (NASA Exoplanet Archive) and the type of data (planets beyond our solar system), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'nasa_apod' or 'nasa_neo', which also access NASA data but for different topics.
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 doesn't mention any specific scenarios, prerequisites, or comparisons to sibling tools like 'jpl_cad' or 'nasa_neo', which might also provide planetary data. Without such context, users must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NASA Fire Information for Resource Management System - fire data
| Name | Required | Description | Default |
|---|---|---|---|
| latitude | Yes | Latitude coordinate | |
| longitude | Yes | Longitude coordinate | |
| days | No | Number of days of data to retrieve |
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 describe key traits: whether this is a read-only query, if it requires authentication, rate limits, data freshness, or output format. The phrase 'fire data' is vague, offering no insight into what the tool returns or how it behaves, leaving the agent uninformed.
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 concise but under-specified, consisting of a single phrase. While it avoids verbosity, it lacks front-loaded clarity and fails to convey essential information efficiently. Every word earns its place, but the content is insufficient, making it more of a label than a helpful 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 a 3-parameter tool with no annotations and no output schema, the description is incomplete. It does not compensate for missing behavioral context or output details. While the schema covers parameters well, the description lacks purpose, usage, and transparency, making it inadequate for effective tool selection and invocation.
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%, with clear parameter descriptions in the schema (latitude, longitude, days). The description adds no meaning beyond this, as it does not explain parameter interactions, units, or constraints. However, with high schema coverage, the baseline score is 3, as the schema adequately documents parameters without need for description enhancement.
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 'NASA Fire Information for Resource Management System - fire data' restates the tool name with minimal elaboration. It identifies the domain (NASA FIRMS) and mentions 'fire data', but lacks a specific verb indicating what the tool does (e.g., retrieve, query, or analyze). It does not distinguish from sibling tools like 'nasa_eonet' or 'nasa_donki', which also handle NASA data but for different purposes.
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. The description does not mention context, prerequisites, or exclusions. Given sibling tools like 'nasa_eonet' for natural events or 'jpl_fireball' for meteor data, there is no indication of when fire data from FIRMS is appropriate, leading to potential misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Global Imagery Browse Services - satellite imagery
| Name | Required | Description | Default |
|---|---|---|---|
| layer | Yes | Layer name (e.g., MODIS_Terra_CorrectedReflectance_TrueColor) | |
| date | Yes | Date of imagery (YYYY-MM-DD) | |
| format | No | Image format (png, jpg, jpeg) | |
| resolution | No | Resolution in pixels per degree |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions 'satellite imagery' without detailing aspects like rate limits, authentication needs, output format (e.g., image URL or data), or any constraints (e.g., date ranges, availability). This leaves significant gaps in understanding how the tool behaves.
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 brief ('Global Imagery Browse Services - satellite imagery'), which is efficient and front-loaded. However, it's under-specified rather than concise, as it lacks necessary details for a tool with 4 parameters and no annotations, slightly reducing its effectiveness.
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 (4 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what the tool returns (e.g., image data, metadata), usage constraints, or how it differs from siblings, making it inadequate for an AI agent to use effectively without additional 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 100%, so the input schema fully documents all parameters. The description adds no additional meaning beyond what's in the schema (e.g., no examples beyond the schema's layer example, no explanation of resolution units). This meets the baseline for high schema coverage.
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 'Global Imagery Browse Services - satellite imagery' states the general domain (satellite imagery) and service name but lacks a specific verb or action. It doesn't clearly distinguish what this tool does (e.g., fetch, retrieve, browse) compared to sibling tools like 'nasa_images' or 'nasa_epic', making the purpose vague.
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. The description doesn't mention any context, prerequisites, or exclusions, leaving the agent without direction on selecting this tool over similar ones in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NASA Image and Video Library - search NASA's media archive
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query | |
| media_type | No | Media type (image, video, audio) | |
| year_start | No | Start year for results | |
| year_end | No | End year for results | |
| page | No | Page number for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions searching an archive but doesn't cover key aspects like whether this is a read-only operation, potential rate limits, authentication needs, or what the response format looks like (e.g., paginated results). This leaves significant gaps for a tool with 5 parameters and no output schema.
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, efficient sentence that front-loads the core purpose ('NASA Image and Video Library - search NASA's media archive'). There is no wasted text, making it highly concise and well-structured for quick understanding.
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 (5 parameters, no annotations, no output schema), the description is incomplete. It lacks behavioral details, usage context, and output information, which are crucial for an agent to effectively use this search tool. The high schema coverage helps with parameters, but overall guidance 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?
The input schema has 100% description coverage, so the schema already documents all 5 parameters (e.g., 'q' for search query, 'media_type' for filtering). The description adds no additional meaning beyond what's in the schema, such as examples or constraints, but since schema coverage is high, a baseline score of 3 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 states the tool's purpose as searching NASA's media archive, which is a specific verb ('search') and resource ('NASA's media archive'). However, it doesn't explicitly differentiate from sibling tools like 'nasa_apod' (Astronomy Picture of the Day) or 'nasa_mars_rover' (Mars rover images), which might also involve NASA media but serve different functions.
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 doesn't mention any context, exclusions, or comparisons to sibling tools, such as 'nasa_apod' for daily astronomy images or 'nasa_mars_rover' for Mars-specific media, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NASA Mars Rover Photos - images from Mars rovers
| Name | Required | Description | Default |
|---|---|---|---|
| rover | Yes | Name of the rover (curiosity, opportunity, spirit, perseverance) | |
| sol | No | Martian sol (day) of the photos | |
| earth_date | No | Earth date of the photos (YYYY-MM-DD) | |
| camera | No | Camera name | |
| page | No | Page number for pagination |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions retrieving photos but doesn't cover key traits like whether it's a read-only operation, rate limits, authentication needs, pagination behavior (implied by 'page' parameter but not explained), or error handling. This leaves significant gaps for a tool with 5 parameters and no output schema.
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 concise with a single sentence that directly states the tool's purpose. It's front-loaded and wastes no words, though it could be slightly more informative without losing efficiency.
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 (5 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain return values, behavioral constraints, or usage context, making it inadequate for an agent to fully understand how to invoke and interpret results from this 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 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond implying photo retrieval, which is already clear from the tool name and schema. Baseline score of 3 is appropriate as the schema handles 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 states the tool retrieves 'images from Mars rovers', which is a clear purpose, but it's vague about the specific action (e.g., 'fetch', 'search', 'retrieve') and doesn't differentiate from sibling tools like 'nasa_images' or 'nasa_apod', which might also handle images. It's not tautological 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 alternatives, such as other NASA tools for images or data. The description doesn't mention prerequisites, exclusions, or context for selection, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Near Earth Object Web Service - information about asteroids
| Name | Required | Description | Default |
|---|---|---|---|
| start_date | Yes | Start date for asteroid search (YYYY-MM-DD) | |
| end_date | Yes | End date for asteroid search (YYYY-MM-DD) | |
| asteroid_id | No | ID of a specific asteroid |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states it provides 'information' without detailing aspects like rate limits, authentication needs, response format, or whether it's a read-only operation. It lacks critical behavioral traits needed for safe and effective use.
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, efficient sentence that directly states the tool's general purpose. It is front-loaded and wastes no words, though it could be more specific to improve clarity without sacrificing 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 the tool has 3 parameters, no annotations, and no output schema, the description is incomplete. It does not explain the return values, how to interpret results, or the tool's behavior in different scenarios (e.g., using asteroid_id with dates), leaving significant gaps for an AI agent to use 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?
Schema description coverage is 100%, so the schema already documents all parameters (start_date, end_date, asteroid_id) with clear descriptions. The description does not add any meaning beyond this, such as explaining relationships between parameters (e.g., that asteroid_id can be used optionally for specific lookups) or additional constraints.
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 the tool provides 'information about asteroids' using the 'Near Earth Object Web Service', which gives a general purpose but lacks specificity about what kind of information (e.g., search results, details) or the exact operation (e.g., search, lookup). It distinguishes from some siblings like 'nasa_apod' but not clearly from other asteroid-related tools like 'jpl_sbdb' or 'jpl_sentry'.
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. The description does not mention any context, prerequisites, or exclusions, leaving it unclear how it differs from sibling tools such as 'jpl_sbdb' (which might also handle asteroid data) or when date ranges versus asteroid IDs are appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NASA OSDR - Get data files for an OSD study
| Name | Required | Description | Default |
|---|---|---|---|
| accession_number | Yes | OSD study accession number (e.g., '87') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Get data files' but doesn't disclose behavioral traits such as authentication needs, rate limits, response format, or whether it's read-only or mutative. This is inadequate for a tool with no annotation coverage.
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, efficient sentence that front-loads the key information ('NASA OSDR - Get data files for an OSD study'). There's no wasted text, making it appropriately sized and well-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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'data files' entail (e.g., format, size, or structure of the return), leaving gaps in understanding the tool's behavior and output for a data retrieval operation.
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%, so the input schema fully documents the 'accession_number' parameter. The description adds no additional meaning beyond what's in the schema, such as examples or constraints, but the baseline is 3 since the schema handles 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 clearly states the verb ('Get') and resource ('data files for an OSD study'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'nasa_cmr' or 'nasa_images', which might also retrieve NASA data, so it lacks sibling distinction.
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. The description doesn't mention prerequisites, exclusions, or compare it to other NASA-related tools in the sibling list, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prediction of Worldwide Energy Resources - meteorological data
| Name | Required | Description | Default |
|---|---|---|---|
| parameters | Yes | Comma-separated data parameters | |
| community | Yes | User community (RE, SB, AG, etc.) | |
| longitude | Yes | Longitude coordinate | |
| latitude | Yes | Latitude coordinate | |
| start | Yes | Start date (YYYYMMDD) | |
| end | Yes | End date (YYYYMMDD) | |
| format | No | Response format (json, csv, etc.) |
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. However, it fails to describe any behavioral traits—it doesn't indicate whether this is a read-only query, a computational prediction tool, or something else. It doesn't mention authentication needs, rate limits, data formats beyond the schema, or what kind of output to expect. The description is essentially non-functional in this regard.
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 phrase that is under-specified rather than concise. It doesn't front-load critical information—it's essentially a tagline that fails to communicate the tool's function. While brief, it lacks the structure needed for effective tool selection, making it inefficient despite its short length.
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 7 parameters (6 required) and no annotations or output schema, the description is completely inadequate. It doesn't explain what the tool does, how to use it, what it returns, or any behavioral aspects. For a data retrieval tool with multiple geographic and temporal parameters, this minimal description leaves too many gaps for effective agent 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 100%, so the schema already documents all 7 parameters thoroughly. The description adds no additional meaning about parameters—it doesn't explain what 'parameters' might include (e.g., temperature, radiation), what 'community' codes represent, or provide examples. With high schema coverage, the baseline is 3, and the description doesn't compensate with extra insights.
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 'Prediction of Worldwide Energy Resources - meteorological data' is vague and tautological, essentially restating the tool name 'nasa_power' without specifying what action it performs. It mentions 'meteorological data' but doesn't clarify if this tool retrieves, analyzes, or processes that data. Compared to sibling tools like 'nasa_apod' (Astronomy Picture of the Day) or 'nasa_neo' (Near Earth Objects), this description lacks a clear verb+resource combination.
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 doesn't mention any specific use cases, prerequisites, or how it differs from sibling tools like 'nasa_cmr' or 'nasa_gibs' that might also handle NASA data. Without any context about its intended application, users must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct NASA data source or service with clear, non-overlapping purposes. For example, jpl_sbdb provides asteroid/comet data, nasa_apod fetches daily astronomy images, and nasa_firms offers fire data, ensuring agents can easily differentiate them.
All tool names follow a consistent prefix-based pattern: 'jpl_' for JPL data sources and 'nasa_' for NASA services, with descriptive suffixes (e.g., _cad, _apod, _firms). This uniformity makes the set predictable and easy to navigate.
With 23 tools, the server is comprehensive for its broad domain of NASA and JPL data, but it borders on being slightly heavy. The count is reasonable given the scope, though some consolidation might improve usability without significant loss of functionality.
The tool set provides extensive coverage of NASA's data offerings, including astronomy, Earth observation, space weather, and planetary science. There are no obvious gaps; agents can access diverse datasets like images, ephemerides, and impact risks, supporting a wide range of queries.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Real-time planetary signal engine and Model Context Protocol (MCP) server for autonomous AI agents.
NASA MCP — wraps NASA Open APIs (api.nasa.gov)
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Geospatial AI MCP server — satellite imagery, embeddings, weather, GNS governance
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ProgramComputer/NASA-MCP-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server