Superseded listing, not a dead server. This entry was imported from an early Glama registration under com.moltlinestudio.mcp; the same server is listed under its official MCP Registry name — use com.moltlinestudio/timeops. Endpoint unchanged: https://mcp.moltlinestudio.com/timeops — still live, still free on the free tier. Only this duplicate entry is deprecated.
Deterministic date math agents get wrong, done in code over MCP: business_days adds and counts working days with holiday awareness, meeting_overlap finds shared windows across UTC offsets including half-hour zones, recurrence_expand generates concrete dates, with deadline_planner and sla_due in the premium tier. Every failure mode returns a structured error.
Do business-day math that skips weekends and your holiday list. FREE.
Either add N business days to start_date (set add_days), or count the business days between start_date and end_date (set end_date). Typical input {"start_date": "2026-03-02", "add_days": 10} returns {"result_date": "2026-03-16", "result_weekday": "Monday", ...}; with end_date set it returns {"business_days_between": N, "from": ..., "to": ...}.
Use when the span must exclude weekends and named holidays. Not for plain calendar-day differences, which are a direct subtraction, and not for scheduling backward from a fixed deadline (deadline_planner). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "dates must be YYYY-MM-DD"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| add_days | No | Business days to add; negative subtracts. Range -5000 to 5000. Ignored when end_date is provided. | |
| end_date | No | Optional end date, ISO YYYY-MM-DD. When set, the tool counts business days between start_date and end_date instead of adding. | |
| holidays | No | Optional list of ISO YYYY-MM-DD dates to treat as non-working days, e.g. ["2026-12-25"]. | |
| start_date | Yes | Anchor date in ISO format YYYY-MM-DD, e.g. "2026-03-02". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable context beyond annotations: the tool never raises protocol errors, instead returns a structured error object with fix instructions. It also explains that retries are safe after correction, which aligns with idempotency. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured paragraphs: first states core function and format, second gives concrete examples, third provides usage guidance and error handling. Every sentence serves a purpose—no fluff. Front-loaded with the key idea 'skip weekends and your holiday list'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low parameter count (4), 100% schema coverage, and an output schema (not shown but referenced), the description is highly complete. It covers purpose, usage modes, error behavior, idempotency, and sibling differentiation. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaning by explaining the two complementary input modes (add_days vs end_date) and gives typical examples with expected outputs. It clarifies that add_days is ignored when end_date is provided, which isn't explicit in the schema. However, it doesn't detail edge cases like negative values beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Do business-day math', 'skip weekends and your holiday list') and clearly differentiates the two modes (adding N days or counting between). The examples illustrate typical input/output, making the purpose unambiguous. It also distinguishes from sibling tools like deadline_planner, reinforcing its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when the span must exclude weekends and named holidays'. It also tells when not to use: 'Not for plain calendar-day differences... and not for scheduling backward from a fixed deadline (deadline_planner).' This gives clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plan a task schedule backward from a hard deadline in business days. PREMIUM (license).
Given ordered tasks with business-day durations, returns each task's start/end dates, the latest safe start, and slack from today. Typical input {"due_date": "2026-06-01", "tasks": [{"name": "Draft", "days": 3}, {"name": "Review", "days": 2}]} returns {"schedule": [...], "latest_safe_start": "YYYY-MM-DD", "slack_business_days_from_today": N, "verdict": "..."}.
Use when the end date is fixed and steps must be placed backward from it. Not for forward counting from a start date (business_days) and not for response-time targets (sla_due). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "due_date must be YYYY-MM-DD"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| tasks | Yes | Ordered list of task objects, each {"name": str, "days": int} where days is the business-day duration (1-365); the first 30 tasks are scheduled. | |
| due_date | Yes | The deadline, ISO YYYY-MM-DD. | |
| holidays | No | Optional list of ISO YYYY-MM-DD dates treated as non-working days. | |
| buffer_days | No | Business days of safety margin kept free before due_date, clamped to 0-365. Default 1. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reinforces and expands on annotations: it states 'Every call is read-only and idempotent' (matching readOnlyHint and idempotentHint) and adds critical detail about error behavior—'never raises a protocol error—it returns {"error": ...}'. This plus the 'PREMIUM (license)' notice provides important context beyond annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is around 150 words and front-loads the core purpose, then flows through usage, example, error handling, and safety note. Every sentence serves a purpose, though minor tightening (e.g., removing the repeated 'PREMIUM' mention) could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (2 required), an output schema, and no nested objects, the description covers all aspects: what it does, when to use it, input format via example, output shape, error responses, and safety guarantees. It is sufficient for an agent to correctly select and invoke the tool without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description adds a concrete JSON example that illustrates the structure of the 'tasks' array and the response format, which aids comprehension beyond the schema's textual descriptions. While not transformative, the example is a meaningful addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific action and resource: 'Plan a task schedule backward from a hard deadline in business days.' It clearly distinguishes from sibling tools by explicitly stating it is not for forward counting (business_days) or response-time targets (sla_due). This leaves no ambiguity about the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'when to use' ('Use when the end date is fixed and steps must be placed backward from it') and 'when not to use' with references to specific alternative tools. This gives the agent clear decision boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the shared meeting window across time zones inside working hours. FREE.
Give one UTC offset per participant and an optional working-hours window. Typical input {"offsets_utc": [-8, 1, 5.5]} returns {"overlap_utc": ["HH:MM", "HH:MM"], "overlap_minutes": N, "local_windows": [...]}; when no shared window exists it returns {"overlap": null, "verdict": "..."}.
Use when people in different zones need one shared slot. Not for converting a single known time between zones, and not for expanding a recurring series (recurrence_expand). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "times must be HH:MM"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| work_end | No | Working day end, 24h HH:MM; must be later than work_start. Default "17:00". | 17:00 |
| work_start | No | Working day start, 24h HH:MM local in every zone. Default "09:00". | 09:00 |
| offsets_utc | Yes | One UTC offset per participant, each between -14 and +14; fractional offsets allowed, e.g. [-8, 1, 5.5]. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds value by detailing the error handling behavior ('never raises a protocol error – returns an error object') and retry safety. It also shows a sample output with the verdict key for no-overlap cases. Minor deduction: the description could mention the local_windows format more precisely, but this is already covered by the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is about 150 words – somewhat verbose but every part earns its place. It is front-loaded with the core purpose and free offering. Minor deduction: the description could be tightened slightly (e.g., 'FREE' could be integrated into the first sentence or omitted), and the error handling explanation is slightly redundant with the example. Still, it is well-structured and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, 1 required, 100% schema coverage, output schema present), the description covers all essential aspects: purpose, input format with examples, output format with examples, success and no-overlap cases, error handling, retry safety, and alternatives. No gaps remain for an agent to misinterpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. However, the description adds substantial meaning: it shows typical input format as a JSON snippet, explains what offsets_utc means ('one UTC offset per participant'), clarifies work_start/work_end defaults, and gives an example return value. This goes well beyond what the schema provides by demonstrating usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds shared meeting windows across time zones inside working hours. It distinguishes itself from siblings by explicitly noting it is not for converting a single time (business_days, sla_due likely handle date math) and not for expanding recurring series (recurrence_expand). The verb 'find the shared meeting window' plus resource 'time zones inside working hours' is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool ('people in different zones need one shared slot') and when not to ('not for converting a single known time... not for expanding a recurring series'). It names the alternative recurrence_expand directly. This provides complete guidance for an agent to select the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | How many dates to generate; values outside 1-60 are clamped into that range. Default 10. | |
| weekly_on | No | Weekday names to recur on, e.g. ["mon", "thu"]; full names like "monday" also work. | |
| every_days | No | Interval in days between occurrences; use this OR weekly_on, not both. | |
| start_date | Yes | First date of the series, ISO YYYY-MM-DD. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by detailing error handling behavior: it never raises protocol errors but returns an error object describing what is wrong and how to fix it. It also explicitly confirms the tool is read-only and idempotent, mirroring annotations but adding concrete user-facing details. The annotations already indicate readOnlyHint and idempotentHint, so this adds extra confidence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using short sentences and a clear example. It front-loads the core purpose and a free keyword, then succinctly covers usage constraints, sibling disambiguation, error handling, and safety guarantees. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's moderate complexity (4 parameters, output schema present), the description is fully complete. It covers purpose, parameters, error behavior, idempotency, and retry safety. The output schema would describe the return shape, so the description need not repeat that. The sibling list and annotations fill in remaining context, making this a well-rounded definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, explaining each parameter clearly. The description adds value by showing a concrete example of using 'every_days' and 'count' together, and implicitly differentiating between 'every_days' and 'weekly_on'. However, it does not add much beyond what the schema already provides, so a small deduction is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool expands a recurrence rule into concrete ISO dates, using specific parameters like 'every_days' or 'weekly_on'. It distinguishes itself from siblings like 'business_days' and 'meeting_overlap' by explicitly stating what it is not for, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool ('Use when a recurrence rule has to become concrete dates'), and when not to ('Not for counting working days... business_days and not for finding a slot... meeting_overlap'), naming specific sibling alternatives. It also gives a typical input example, setting clear expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute when a ticket's SLA falls due, wall-clock or business-hours. PREMIUM (license).
Typical input {"opened_at": "2026-03-02T15:30", "sla_hours": 8, "business_hours_only": true} returns {"due": "2026-03-03T15:30", "mode": "business hours 09:00-17:00"}; with business_hours_only false the mode is "wall-clock".
Use when a response or resolution clock has started and one due moment is needed. Not for multi-step project schedules (deadline_planner). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": ""} (for example {"error": "opened_at must be ISO YYYY-MM-DDTHH:MM"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| day_end | No | Business day end, 24h HH:MM; must be later than day_start. Default "17:00". | 17:00 |
| holidays | No | Optional list of ISO YYYY-MM-DD dates that never count as working days. | |
| day_start | No | Business day start, 24h HH:MM. Default "09:00". | 09:00 |
| opened_at | Yes | When the SLA clock started, ISO datetime YYYY-MM-DDTHH:MM. | |
| sla_hours | Yes | SLA length in hours; greater than 0, at most 24000; fractions allowed, e.g. 7.5. | |
| business_hours_only | No | If true, only time inside day_start-day_end on business days counts toward the SLA. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds critical error behavior: 'never raises a protocol error — it returns {"error": "..."}' and clarifies that every call is read-only and idempotent, making retry safe. This is substantial behavioral context not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence serves a purpose: purpose, example, usage guidelines, error handling, idempotency. The description is concise (~100 words), front-loaded, and well-structured. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 6 parameters, output schema existence, and sibling tools, the description covers all critical aspects: what it computes, when to use it, error behavior, retry safety, and a concrete example. An AI agent has all necessary information to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. The description adds value by showing a typical input example and explaining how 'business_hours_only' affects the output mode, which is not in the schema. While schema is already strong, the example and relationship clarification merit a slight boost above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes SLA due times for tickets, using either wall-clock or business hours. It immediately distinguishes itself from the sibling 'deadline_planner' by noting it is not for multi-step project schedules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use when a response or resolution clock has started and one due moment is needed. Not for multi-step project schedules (deadline_planner).' It also explains error handling and retry safety, leaving no ambiguity about when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
business_daysdeadline_plannermeeting_overlaprecurrence_expandsla_dueClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Each tool targets a distinct time-related operation: business day math, backward scheduling, timezone overlap, recurrence rules, and SLA due times. The descriptions include 'Use when ... Not for ...' sections that clearly differentiate them, though business_days and deadline_planner both involve business days and could be confused for near-simple tasks.
All tool names use a consistent snake_case pattern with clear, descriptive verb+noun or noun_verb combinations (business_days, deadline_planner, meeting_overlap, recurrence_expand, sla_due). The naming is predictable and intuitive for the domain.
Five tools is a well-scoped set for a time operations server, covering core scheduling needs without being too few or too many. Each tool addresses a distinct use case and the count is appropriate for the server's purpose.
The tool set covers major temporal operations: date arithmetic, backward planning, timezone coordination, recurrence, and SLA tracking. A minor gap is the lack of a plain calendar-day difference tool (as noted in business_days description), but the core domain is well covered and agents can work around this gap.