Microapp

year-progress

Read-onlyIdempotent

Calculate how much of a calendar year has elapsed at a given moment. Returns percent elapsed/remaining, day-of-year, seconds elapsed/remaining, leap-year flag, and a 20-char ASCII progress bar. Useful for goal-tracking and 'how much of the year is left' moments.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`at`	No	Reference timestamp as an ISO 8601 string (YYYY-MM-DD or full ISO datetime). If omitted, the handler treats it as 'now' — but engines are pure, so callers should pass an explicit value to keep results reproducible.
`year`	No	Override the year. If omitted, derived from `at`. Use this to compute progress for a year other than the one containing `at` (e.g. ask 'what was 2024's progress on 2024-07-01' explicitly).

Output Schema

TableJSON Schema

Name	Required	Description
`year`	Yes	The year being measured.
`dayOfYear`	Yes	1-indexed day number within the year (Jan 1 = 1).
`isLeapYear`	Yes	True if the year is a leap year (366 days).
`daysElapsed`	Yes	Full days elapsed from Jan 1 00:00 to `at`.
`progressBar`	Yes	20-character ASCII progress bar built from █ (filled) and ░ (empty), e.g. '████████░░░░░░░░░░░░'.
`daysRemaining`	Yes	Full days remaining from `at` to Dec 31 23:59:59.999.
`percentElapsed`	Yes	Percent of the year that has elapsed at `at`, 0-100, rounded to 4 decimals.
`secondsElapsed`	Yes	Seconds elapsed from start-of-year to `at`.
`totalDaysInYear`	Yes	365 in normal years, 366 in leap years.
`percentRemaining`	Yes	Percent of the year remaining after `at`, 0-100, rounded to 4 decimals.
`secondsRemaining`	Yes	Seconds remaining from `at` to end-of-year.

Schema Changelog

Changes observed during successful MCP inspections.

AddedMay 21, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive; the description adds behavioral detail by listing what the tool returns (percent elapsed/remaining, day-of-year, seconds, leap-year flag, ASCII progress bar). It doesn't detail edge cases like timezone handling, but the annotation coverage lowers the burden.

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?

Two sentences, no fluff, front-loaded with the verb, and all sentences earn their place—first states action, second lists outputs and use cases.

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?

For a simple calculation tool with full annotations, a 100%-described schema, and an output schema present, the description fully covers what the tool does, what it returns, and when to use it. No important information appears missing.

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?

The input schema provides 100% description coverage for both `at` and `year`, including format guidance and semantics for the year override. The tool description itself adds no parameter-level nuance beyond the schema, so baseline 3 applies.

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?

Description opens with a specific verb phrase ('Calculate how much of a calendar year has elapsed at a given moment') and enumerates the return fields (percent, day-of-year, seconds, leap-year flag, progress bar). This clearly distinguishes it from date-range siblings like days-between.

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?

States the tool is 'useful for goal-tracking and 'how much of the year is left' moments,' giving concrete use cases. However, it does not explicitly name alternatives or exclusion criteria, so it stops at clear context without full comparative guidance.

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

All Microapp 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?