Skip to main content
Glama

Moltline TimeOps

by com.moltlinestudio

Recurrence Expand

recurrence_expand
Read-onlyIdempotent

Expand a recurrence rule into a concrete list of ISO dates. FREE.

Set every_days for a fixed interval, or weekly_on for specific weekdays. Typical input {"start_date": "2026-01-05", "every_days": 14, "count": 3} returns {"dates": ["2026-01-05", "2026-01-19", "2026-02-02"]}.

Use when a recurrence rule has to become concrete dates. Not for counting working days in a span (business_days) and not for finding a slot across zones (meeting_overlap). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "start_date must be YYYY-MM-DD"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoHow many dates to generate; values outside 1-60 are clamped into that range. Default 10.
weekly_onNoWeekday names to recur on, e.g. ["mon", "thu"]; full names like "monday" also work.
every_daysNoInterval in days between occurrences; use this OR weekly_on, not both.
start_dateYesFirst date of the series, ISO YYYY-MM-DD.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description reinforces these and adds critical behavioral detail: the tool never raises a protocol error on invalid input, instead returning a structured error object with fix instructions. This is valuable beyond annotations.

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?

Every sentence earns its place: purpose, example, usage guidance, error behavior, safety note. The description is front-loaded with the core action and is no longer than needed. Ideal structure.

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?

Given the richness of annotations, input schema, and presence of an output schema, the description covers all necessary aspects: input format, example, usage scope, error handling, and safety guarantees. No gaps remain.

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 baseline is 3. The description adds value by providing a typical input example, clarifying the mutual exclusivity of 'every_days' and 'weekly_on', and explaining the error format. This helps the agent understand parameter relationships and output structure.

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 description starts with a clear verb+resource: 'Expand a recurrence rule into a concrete list of ISO dates.' It provides an example and distinguishes from siblings like 'business_days' and 'meeting_overlap', making the tool's exact purpose unmistakable.

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?

Explicitly states when to use ('when a recurrence rule has to become concrete dates') and when not to use, naming two sibling tools as alternatives. This gives clear, actionable guidance for selection.

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

All Moltline TimeOps toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

Every tool targets a clearly distinct temporal operation: business-day arithmetic, backward project scheduling, time-zone meeting overlap, recurrence expansion, and SLA due computation. The descriptions explicitly state what each tool is not for, making confusion unlikely.

Naming Consistency3/5

All names use underscores, but the structure varies: business_days (noun_noun), deadline_planner (noun_verb), meeting_overlap (noun_noun), recurrence_expand (noun_verb), sla_due (abbreviation+adjective). No consistent verb_noun or action_resource pattern, making prediction harder.

Tool Count5/5

With five tools, the set covers core time-ops needs—business days, deadlines, meetings, recurrences, and SLAs—without bloat. Each tool earns its place, and the count is ideal for focused servers.

Completeness4/5

The surface is well-scoped for the stated domain, covering business-day logic, planning, meeting scheduling, recurrence, and SLA timing. Minor gaps exist (e.g., no timezone conversion or general date difference) but are arguably out of scope or trivially handled externally.

Resources