Sunvane Golden Hour

Compare day length

compare_day_length

Read-only

Use this when the user asks for day length differences and average change per day between two local dates, or the solstices and equinoxes of a year. Returns daylight duration for each date and signed changes. Limits: cities with population 50,000+ (plus Tromso), dates/years 1900–2100, flat sea-level horizon; use either date_a and date_b or year, and not both. Does not forecast weather.

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": {
      "city": "<city>"
    },
    "name": "compare_day_length"
  }
}

Input Schema

Name	Required	Description
`city`	Yes	City name, for example New York. Cities with population 50,000+ are supported; the largest same-name match is used.
`year`	No	Year whose equinox and solstice local dates to compare, for example 2026. Omit date_a/date_b.
`state`	No	Optional US state name or abbreviation, for example NY or New York.
`date_a`	No	First local date for a two-date comparison, for example 2026-03-20. Required with date_b; omit with year.
`date_b`	No	Second local date, for example 2026-06-21. Required with date_a; omit with year.
`country`	No	Optional country name or two-letter code to narrow the match, for example US.

Output Schema

Name	Required	Description	Default
`blue`	No
`date`	No
`days`	No
`mode`	Yes
`civil`	No
`golden`	No
`period`	No
`sunset`	No
`values`	No
`changes`	No
`preview`	No
`request`	Yes
`sunrise`	No
`location`	Yes
`nautical`	No
`timeZone`	No
`dayLength`	No
`dayStatus`	No
`downloads`	No
`solarNoon`	No
`startDate`	No
`eventCount`	No
`definitions`	Yes
`limitations`	Yes
`astronomical`	No
`sunsetAzimuth`	No
`sunriseAzimuth`	No
`dayLengthSeconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnly, non-destructive, closed-world); the description adds substantive behavioral context beyond them: coverage limits (population 50,000+, plus Tromso), date/year bounds 1900–2100, flat sea-level horizon approximation, and the either/or parameter mode. It also states what is returned (daylight duration per date plus signed changes).

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?

Front-loaded with the usage trigger, then return values, then limits and scope exclusion. Four dense sentences with no filler; each clause carries either a trigger, an output statement, or a constraint.

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 an output schema present, return values need only a one-line summary, which it provides. All six parameters are schema-documented and the description covers the mode logic, coverage limits, and approximation caveat — nothing needed to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so per-parameter meaning is already documented. The description nevertheless adds cross-parameter guidance not obvious from the individual fields: use either date_a/date_b or year, not both, which resolves a real ambiguity in mode selection.

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 and resource: day length differences and average change per day between two local dates, or solstices/equinoxes of a year. This is clearly distinct from siblings find_sun_times (point-in-time sunrise/sunset) and plan_golden_hour_shoot (photography planning).

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?

Opens with an explicit trigger ('Use this when the user asks for...') and closes with an explicit exclusion ('Does not forecast weather'). It also names the alternative input mode and the mutual-exclusion rule, leaving little to infer.

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

All Sunvane Golden Hour tools Inspect

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

Need Help?