Skip to main content
Glama

thirdtrail

by io.github.thirdtrail
OverviewDiscussionsAdmin

Solar position and irradiance

get_solar_position
Read-onlyIdempotent

The sun's position at one instant: azimuth, altitude, zenith, declination, hour angle and equation of time, plus clear-sky irradiance (GHI, DNI and DHI in W/m²) when include asks for it and the plan covers it. Use it for where the sun is at a given moment; for its track through a whole day use get_solar_path, and for rise and set times use get_sun_moon_times. timestamp defaults to now. Positions are NREL SPA-equivalent on JPL DE421; irradiance comes from the Bird clear-sky model. Requires an API key on a paid Solar plan.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tzNoIANA timezone for output timestamps, e.g. Europe/Dublin. Defaults to UTC.
latYesLatitude in decimal degrees.
lonYesLongitude in decimal degrees.
includeNoposition (default) or position,irradiance.
elevationNoMetres above sea level. Supply it when known: at altitude the sun rises measurably earlier than the sea-level answer. Omit only if the elevation is genuinely unknown.
timestampNoISO 8601 instant, e.g. 2026-06-21T12:00:00Z. Defaults to now.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / include / description
      Previous value: -"Comma-separated sections, e.g. position,irradiance."New value: +"position (default) or position,irradiance."
    • addedInput schema / properties / include / enum
      Added value: +[
+  "position",
+  "position,irradiance"
+]
    • changedInput schema / properties / timestamp / description
      Previous value: -"ISO 8601 instant, e.g. 2026-06-21T12:00:00Z."New value: +"ISO 8601 instant, e.g. 2026-06-21T12:00:00Z. Defaults to now."
    • changedInput schema / properties / tz / description
      Previous value: -"IANA timezone for output timestamps, e.g. Europe/Dublin."New value: +"IANA timezone for output timestamps, e.g. Europe/Dublin. Defaults to UTC."
  2. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: an API key on a paid Solar plan is required, and results are NREL SPA-equivalent on JPL DE421 with Bird clear-sky irradiance — provenance that affects trust in the numbers.

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?

Front-loaded with the payload and the sibling routing, then defaults and provenance. Every clause carries information, though the run-on sentence packing the include/plan condition with the output list costs some readability.

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

Completeness5/5

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

With no output schema, the description enumerates the returned fields and their units, states the default for timestamp, and discloses the plan/auth prerequisite. An agent has everything needed to call it correctly and interpret the response.

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%, so all six parameters including timestamp's 'defaults to now' and elevation's guidance are already documented. The description adds only the conditional gate that irradiance appears 'when include asks for it and the plan covers it', which is marginal beyond the enum in the 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?

States a specific verb+resource ('the sun's position at one instant') and enumerates the exact quantities returned (azimuth, altitude, zenith, declination, hour angle, equation of time, GHI/DNI/DHI). It further distinguishes itself from get_solar_path and get_sun_moon_times by scope, so an agent can route without opening a schema.

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

Usage Guidelines5/5

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

Explicit when-to-use ('where the sun is at a given moment') plus named alternatives for adjacent needs: get_solar_path for a full day's track and get_sun_moon_times for rise/set. Nothing is left to inference.

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

All thirdtrail toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources