Skip to main content
Glama

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

NameRequiredDescriptionDefault
dateNoDate in YYYY-MM-DD format (default: today)

Output Schema

NameRequiredDescriptionDefault
dateYesDate in YYYY-MM-DD format
titleYesTitle of the astronomy picture
hd_urlYesURL to high-definition version or null
copyrightYesCopyright information or null
image_urlYesURL to the image
media_typeYesType of media (image or video)
explanationYesExplanation of the astronomy picture

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • 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"
      +}
  2. Changed2 schema fields changed
    • 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
  3. Changed1 schema field changed
    • 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"
      +}
  4. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "_apiKey": "your-nasa-api-key",
      +    "date": "2024-01-15"
      +  },
      +  {
      +    "_apiKey": "your-nasa-api-key"
      +  }
      +]
  5. First observed

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.