Loading ToolBench
A comprehensive MCP server for NASA's open APIs. Provides access to APOD, Mars rovers, asteroids, and NASA media library.
NASA MCP Server has 11 tools with basic descriptions and parameter schemas, but falls short of production quality in multiple critical dimensions. Tool naming is consistent and action-oriented (all start with 'get_' or 'search_'), which is positive. However, parameter descriptions are minimal or absent, output schemas are undocumented, error handling lacks recovery guidance, and critical patterns like tool annotations (readOnlyHint/destructiveHint/idempotentHint) are missing. The code shows good internal practices (logging, caching, rate-limit awareness) but these implementation details do not compensate for weak tool interface design. This server would require significant work before production deployment.
Browse NEO database with pagination.
Get NASA's Astronomy Picture of the Day. Args: date: Date in YYYY-MM-DD format (defaults to today) Returns: APOD data including image URL, explanation, and metadata
Get APOD entries for a date range. Args: start_date: Start date in YYYY-MM-DD format end_date: End date in YYYY-MM-DD format (defaults to today) Returns: List of APOD entries for the date range
Get Near Earth Objects feed (includes hazardous flag).
Get the most recent Mars rover photos.
Get Mars rover photos by Earth date.
Output schemas not documented. Tools return complex API responses (APOD data, rover photos, asteroid details) but provide no formal documentation of return fields, types, or structure. LLMs cannot plan downstream operations or extract specific fields without inferring structure from examples. This violates the documented output schema pattern and forces agents to guess.
Parameter descriptions are minimal or missing critical details. Examples: 'get_mars_photos_by_sol' has 'rover' with description 'Rover name (curiosity, opportunity, spirit)' but does not clarify whether only one of these is valid or if all are interchangeable. 'camera' is marked optional but no guidance on valid camera names is provided. LLMs cannot validate input without explicit constraints and examples of valid values.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | <=2025-11-25 | v2 |
Get Mars rover photos by Martian sol (day).
Get random APOD entries. Args: count: Number of random entries (1-100) Returns: List of random APOD entries
Get Mars rover mission details and status.
Get detailed asteroid information by ID or name.
Search NASA's media library.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. All 11 tools are read-only operations but this is not formally declared in tool metadata. Risk annotation is marked in the metadata ('Risk: READ_ONLY') but not integrated into the MCP protocol response. This forces LLMs to infer safety from descriptions alone, increasing hallucination risk for irreversible operations if tooling evolves.
Error handling lacks recovery guidance. Source code shows try-catch blocks return generic error messages like {'error': str(e)} or {'error': f'API error: {e.response.status_code}'}. These do not guide LLMs on what to do next. For example, 'No APOD available for date 1990-01-01. APOD started on 1995-06-16.' is good, but most error paths are bare. Agents cannot self-correct or retry intelligently.
Pagination not fully documented or implemented in parameter descriptions. 'browse_asteroids' accepts 'page' and 'size' parameters but descriptions do not state minimum/maximum values, whether page numbering starts at 0 or 1, or what the default size is. This matches the pattern baseline issue: tools returning lists should accept page/offset and limit and return a total count or next_cursor. The tool likely returns results but the response structure and total count are not documented.
Parameter constraints not formally declared. Numeric parameters like 'count' in 'get_random_apod' state the range '(1-100)' in the description text but not in schema format (minItems, maxItems). Similarly, date parameters do not declare a regex pattern or format validator. LLMs cannot programmatically validate input without formal schema constraints.
Enum values not declared for constrained parameters. 'rover' and 'camera' parameters accept specific sets of values but are defined as free-form strings. This invites hallucinated values (e.g. 'rover': 'perseverance' which does not exist in NASA's current rover set). Proper enum schemas would prevent this.