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

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

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

A4.2/5.0
Disambiguation5/5

Each tool targets a distinct date/calendar operation: arithmetic, conversion, weekday lookup, period membership, moon phase, daylight, event queries, formatting/parsing, and two different rendering outputs. Even superficially similar tools (calendar_weekday vs nth_weekday_of_month, calendar_events vs calendar_periods) ask clearly different questions that the descriptions make unambiguous.

Naming Consistency4/5

Names are all lowercase snake_case and mostly follow a verb_first or noun_query pattern, but there is a mix: add_to_date, convert_date, and parse_calendar_date are imperative, while moon_phases, sun_daylight, and calendar_events are noun phrases describing what they return. The calendar_ prefix on three tools and consistent rendering parse/format pairs help readability, so this is a minor deviation, not chaos.

Tool Count5/5

15 tools sits at the upper bound of the ideal range for a focused domain toolkit. Every tool addresses a genuine calendar use case (define, convert, query, render, validate, generate), and none feels redundant or extraneous.

Completeness5/5

The set covers the full lifecycle of working with a custom calendar: validation before use, conversion between representations, date arithmetic and intervals, weekday and period queries, recurring events and daylight/moon data, formatting/parsing, and visual rendering. No obvious dead ends or missing operations come to mind for the stated domain.

Resources