Skip to main content
Glama
Sign In
chuk-mcp-celestial

chuk-mcp-celestial

by IBM
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_earth_seasons

Calculate Earth's seasonal and orbital events for any year, including equinoxes, solstices, perihelion, and aphelion with timezone support.

Instructions

Get Earth's seasons and orbital events for a year.

Returns dates and times for equinoxes (equal day/night), solstices (longest/shortest days), and Earth's perihelion (closest to sun) and aphelion (farthest from sun).

Args: year: Year to query (1700-2100) timezone: Timezone offset from UTC in hours. If not provided, UTC (0) is used. dst: Whether to apply daylight saving time adjustment.

Returns: SeasonsResponse with equinoxes, solstices, perihelion, and aphelion.

Tips for LLMs: - Typically 6 events per year (2 equinoxes, 2 solstices, perihelion, aphelion) - Seasons are opposite in Northern and Southern hemispheres - Earth's 23.5 degree axial tilt causes seasons, not distance from sun

Example: seasons = await get_earth_seasons(2024) for event in seasons.data: print(f"{event.phenom}: {event.month}/{event.day}/{event.year} at {event.time}")

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "year": "<year>"
    },
    "name": "get_earth_seasons"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearYes
timezoneNo
dstNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.4

TDQS

A4.4/5.0
Behavior4/5

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 effectively describes what the tool returns (dates and times for specific astronomical events), includes practical tips about event frequency and hemispheric differences, and provides an example of usage and output format. However, it doesn't mention potential limitations like computational constraints or error conditions.

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

Conciseness4/5

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

The description is well-structured with clear sections (purpose, returns, args, tips, example) and front-loaded with the core functionality. While comprehensive, some information in the 'Tips for LLMs' section (like the explanation of axial tilt) could be considered slightly beyond what's strictly necessary for tool invocation.

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 complexity (astronomical calculations with 3 parameters) and no annotations or output schema, the description provides substantial context including parameter details, return value explanation, usage tips, and an example. However, without an output schema, the description doesn't fully document the SeasonsResponse structure beyond listing its components.

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

Parameters5/5

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

With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation in the 'Args' section. It explains each parameter's purpose (year to query, timezone offset, DST adjustment), provides value ranges (1700-2100 for year), and default behavior (UTC if timezone not provided). This adds significant meaning beyond the bare schema.

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's purpose: 'Get Earth's seasons and orbital events for a year' with specific resources (equinoxes, solstices, perihelion, aphelion). It distinguishes from siblings like get_moon_phases or get_planet_events by focusing exclusively on Earth's seasonal and orbital events.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool (for Earth's seasons and orbital events), but doesn't explicitly state when not to use it or name specific alternatives among siblings. The 'Tips for LLMs' section implies usage scenarios but doesn't provide explicit exclusion criteria.

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

Deploy Server

Other Tools