science

Get Apod

get_apod

Read-onlyIdempotent

Get NASA's Astronomy Picture of the Day with image URL, title, and explanation. Optionally specify a date (e.g., '2024-01-15').

Input Schema

TableJSON Schema

Name	Required	Description	Default
`date`	No	Date in YYYY-MM-DD format (default: today)

Output Schema

TableJSON Schema

Name	Required	Description
`date`	Yes	Date in YYYY-MM-DD format
`title`	Yes	Title of the astronomy picture
`hd_url`	Yes	URL to high-definition version or null
`copyright`	Yes	Copyright information or null
`image_url`	Yes	URL to the image
`media_type`	Yes	Type of media (image or video)
`explanation`	Yes	Explanation of the astronomy picture

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed2 schema fields changedMay 24, 2026

addedInput schema / examples

Added value: +[
+  {
+    "date": "2024-01-15"
+  },
+  {}
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "copyright": {
+      "description": "Copyright information or null",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "date": {
+      "description": "Date in YYYY-MM-DD format",
+      "type": "string"
+    },
+    "explanation": {
+      "description": "Explanation of the astronomy picture",
+      "type": "string"
+    },
+    "hd_url": {
+      "description": "URL to high-definition version or null",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "image_url": {
+      "description": "URL to the image",
+      "type": "string"
+    },
+    "media_type": {
+      "description": "Type of media (image or video)",
+      "type": "string"
+    },
+    "title": {
+      "description": "Title of the astronomy picture",
+      "type": "string"
+    }
+  },
+  "required": [
+    "title",
+    "date",
+    "explanation",
+    "image_url",
+    "hd_url",
+    "media_type",
+    "copyright"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedMay 13, 2026

removedInput schema / examples

Removed value: -[
-  {
-    "_apiKey": "your-nasa-api-key",
-    "date": "2024-01-15"
-  },
-  {
-    "_apiKey": "your-nasa-api-key"
-  }
-]

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "copyright": {
-      "description": "Copyright information for the picture",
-      "type": "string"
-    },
-    "date": {
-      "description": "Date of the astronomy picture in YYYY-MM-DD format",
-      "type": "string"
-    },
-    "explanation": {
-      "description": "Explanation of the astronomy picture",
-      "type": "string"
-    },
-    "hd_url": {
-      "description": "URL to the high-definition version of the picture",
-      "type": "string"
-    },
-    "media_type": {
-      "description": "Type of media (image or video)",
-      "type": "string"
-    },
-    "title": {
-      "description": "Title of the astronomy picture",
-      "type": "string"
-    },
-    "url": {
-      "description": "URL to the astronomy picture",
-      "type": "string"
-    }
-  },
-  "required": [
-    "date",
-    "title",
-    "explanation",
-    "url",
-    "media_type"
-  ],
-  "type": "object"
-}New value: +null

Changed1 schema field changedMay 8, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "copyright": {
+      "description": "Copyright information for the picture",
+      "type": "string"
+    },
+    "date": {
+      "description": "Date of the astronomy picture in YYYY-MM-DD format",
+      "type": "string"
+    },
+    "explanation": {
+      "description": "Explanation of the astronomy picture",
+      "type": "string"
+    },
+    "hd_url": {
+      "description": "URL to the high-definition version of the picture",
+      "type": "string"
+    },
+    "media_type": {
+      "description": "Type of media (image or video)",
+      "type": "string"
+    },
+    "title": {
+      "description": "Title of the astronomy picture",
+      "type": "string"
+    },
+    "url": {
+      "description": "URL to the astronomy picture",
+      "type": "string"
+    }
+  },
+  "required": [
+    "date",
+    "title",
+    "explanation",
+    "url",
+    "media_type"
+  ],
+  "type": "object"
+}

Changed1 schema field changedMay 6, 2026

addedInput schema / examples

Added value: +[
+  {
+    "_apiKey": "your-nasa-api-key",
+    "date": "2024-01-15"
+  },
+  {
+    "_apiKey": "your-nasa-api-key"
+  }
+]

First observedApr 14, 2026

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds that date is optional and that the response includes image URL/title/explanation, but it does not disclose behavior like what happens for an invalid date or rate limits. This is adequate but minimal beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no filler. The first sentence states the primary purpose and outputs, the second explains the optional parameter. Highly efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 optional param, strong annotations, and an output schema), the description is complete enough. It omits edge-case behavior like invalid dates, but that is not critical for a read-only, idempotent single-resource tool. Slightly below perfect due to no mention of fallback or error handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with the date parameter fully described (format and default). The description repeats the format example '2024-01-15', adding no new meaning beyond the schema. Baseline 3 is appropriate when the schema handles parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves NASA's Astronomy Picture of the Day and lists the returned fields (image URL, title, explanation). It is specific and distinct from sibling get_* tools like get_air_quality or get_earthquakes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: use this when you need the APOD, optionally with a specific date. However, it does not explicitly state when not to use it or mention any alternative tools, leaving usage guidance implicit rather than explicit.

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

All science tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0

Disambiguation3/5

Several tools have overlapping purposes, such as ask_pipeworx, ask_pipeworx_grounded, and deep_research all answering questions with slight differences. Also, entity_profile and compare_entities both retrieve company data, and the multitude of Polymarket tools can be confusing. However, many tools have distinct use-cases, so the ambiguity is moderate.

Naming Consistency3/5

Tool names mix consistent patterns (e.g., get_air_quality, get_apod) with less predictable ones (e.g., pipeworx_feedback, polymarket_arbitrage, bet_research). Some follow verb_noun, others are noun_verb or just noun. The inconsistency is noticeable but not chaotic.

Tool Count2/5

With 34 tools, the server feels overloaded for a 'science' domain. Many tools are dedicated to prediction markets (Polymarket) and finance, which seem tangential. The count could be reduced by merging similar query tools or removing domain-specific betting tools to better fit the scientific theme.

Completeness2/5

While the server covers a broad range of data sources (SEC, FDA, FRED, etc.), it lacks core scientific tools for physics, chemistry, or biology. The few science-themed tools (get_apod, get_earthquakes) are minor. The set feels incomplete for a dedicated science server, with emphasis on finance and betting instead.

Get Apod

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources