Skip to main content
Glama

sun_daylight

How long each sun is up on a date, and between which times of day. THE CURVE IS DECLARED BY THE SPEC, NEVER INFERRED, and that is the point of this tool: a shortest day, a longest day and a solstice do not say what happens between them — a sinusoid and a straight line honour all three and disagree everywhere else, by nearly a whole bell at the quarter points — so the spec names the shape ('sinusoid', 'linear', or 'table' given point by point) and this evaluates it exactly. It is NOT astronomy: no latitude, no axial tilt, no orbit, and no attempt at plausibility. It is exactly what the calendar describes, the same promise moon_phases makes. 'rise' and 'set' sit either side of each sun's own noon, so several suns can be up at different hours; both are null when a sun is up all day or not at all, which 'always_up' and 'never_up' say. 'wraps' means a sun's span runs through the turn of the day. 'lit' is the UNION of every sun's span, not the sum: two suns sharing the sky make one lit stretch, and adding them would claim a day longer than it is. Each lit stretch is half-open, so its 'to' is the tick the light stops at and is never wrapped round: a sun up the whole day closes at one whole day, not at nought. A sun that does not keep to the year declares a 'period' in whole days and a dated 'epoch' instead of a solstice; its noon then drifts through the day once per cycle — on its own 'noon_period' where the spec gives one — and 'cycle' says where in its DAYLIGHT cycle the date falls (null for a sun that keeps to the year). Any number of suns. Fails rather than guessing if the calendar declares no suns, or no 'day' block to measure them in. Pass 'dates' for more than one. Answers up to 1000 in one call, in the order given, as {count, ok, results}. Prefer this over one call per item: the spec travels once instead of once each.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNo
datesNo
calendarYes
on_errorNofail

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and delivers extensively: curve shapes are 'DECLARED BY THE SPEC, NEVER INFERRED'; rise/set are 'null when a sun is up all day or not at all'; lit is 'the UNION of every sun's span, not the sum'; stretches are 'half-open'; non-year suns get period/epoch/noon_period/cycle semantics; return shape '{count, ok, results}' and failure mode are stated. This is exemplary disclosure for a complex tool.

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

Conciseness3/5

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

The core purpose is front-loaded, and every sentence does carry real information, but the body is one unbroken wall of text with ALL-CAPS emphasis and a long rhetorical analogy ('a sinusoid and a straight line honour all three and disagree everywhere else, by nearly a whole bell at the quarter points'). The prose is convoluted in places ('closes at one whole day, not at nought') and would be considerably clearer broken into segmented guidance.

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?

For a tool with zero annotations, zero schema coverage, no output schema, and nested-object parameters, the description covers purpose, return format, error behavior, batching limits, and a large set of edge-case semantics (wraps, always_up/never_up, half-open lit stretches, period/epoch/cycle). Residual gaps: the concrete calendar object structure is only described conceptually, and on_error semantics are not explained. Very complete, with minor omissions an agent would have to infer.

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 description coverage is 0%, so the description must compensate, and it does for the dominant parameters: it explains what the calendar must declare (shape names, day block, suns), distinguishes date vs dates ('Pass dates for more than one'), and sets the batch ceiling ('Answers up to 1000 in one call, in the order given'). However, the on_error parameter is left entirely unexplained beyond the schema default, and the calendar's exact field names are only alluded to conceptually.

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 opening sentence, 'How long each sun is up on a date, and between which times of day,' states a concrete verb+resource+scope. It further differentiates the tool by declaring 'It is NOT astronomy: no latitude, no axial tilt, no orbit,' and by aligning its promise with sibling 'moon_phases' — so an agent can tell what this tool is and is not.

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 gives explicit operating conditions: 'Pass dates for more than one,' 'Answers up to 1000 in one call,' 'Prefer this over one call per item,' and failure conditions ('Fails rather than guessing if the calendar declares no suns, or no day block'). It does not, however, name a specific sibling to route to under a specific alternative scenario — the moon_phases reference is an analogy, not a conditional exclusion.

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.

TDQS

A3.9/5.0
Disambiguation4/5

Each tool targets a distinct calendar operation, and the descriptions carefully draw boundaries between related concepts. There is modest overlap: convert_date also reports a named period, and calendar_events can answer nth-weekday questions that overlap with nth_weekday_of_month, so an agent might occasionally pick the wrong entry point.

Naming Consistency3/5

All names are readable and consistently snake_case, but the set mixes verb-led names like convert_date and render_timeline with noun-led names like calendar_events and moon_phases, plus one prepositional verb in add_to_date. This is a readable mixture rather than a uniform verb_noun pattern.

Tool Count5/5

Fifteen tools sits at the upper end of the typical well-scoped range, but every tool fills a distinct role for an almanac-style server: date math, conversion, calendar queries, formatting, parsing, rendering, lunar and solar calculations, generation, and validation. The batched plural parameters also make the count feel intentional rather than bloated.

Completeness4/5

The surface covers the domain unusually well: conversion, arithmetic, events, periods, weekdays, format/parse, SVG rendering, moon phases, daylight, scattering, and validation all have dedicated tools. The main gap is introspection—there is no direct way to list a calendar spec's months, eras, week structure, periods, or formats beyond what other tools reveal through errors and outputs.

Resources