A
licenseNot graded
qualityD
maintenanceProvides date, time, and timezone tools for AI agents via MCP, including timezone conversion, date calculation, cron parsing, timestamp conversion, and duration formatting.
54
MIT
Epoch Calculator
Server Details
Time and date math for AI agents: Unix timestamp conversion, DST-correct time zone conversion, durations, epoch arithmetic, cron schedules, and holiday countdowns. Eight tools, no key.
Ownership verified
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
8 toolsconvert_timestampARead-onlyIdempotentInspect
Convert a Unix timestamp (seconds or milliseconds; auto-detected unless unit is given) to a human-readable date in a time zone, with ISO 8601, RFC 2822, UTC offset, DST flag, weekday, and a relative phrase like "3 days ago".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| unit | No | Interpretation of timestamp. Default auto. | |
| timezone | No | IANA time zone, e.g. "America/New_York". Defaults to UTC. | |
| timestamp | Yes | Unix timestamp. Values >= 1e11 are treated as milliseconds unless unit is set. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| iso | Yes | ISO 8601 with the zone offset. |
| human | Yes | Readable sentence with weekday, date, time and zone. |
| is_dst | Yes | Whether daylight-saving time is in effect. |
| offset | Yes | UTC offset, e.g. "+09:00". |
| rfc2822 | Yes | RFC 2822 date string. |
| utc_iso | Yes | ISO 8601 in UTC (Z). |
| weekday | Yes | Full weekday name in English. |
| relative | Yes | Relative phrase such as "3 days ago". |
| timezone | Yes | IANA zone name. |
| abbreviation | Yes | Zone abbreviation at that instant, e.g. "BST". |
| epoch_millis | Yes | Unix time in milliseconds. |
| epoch_seconds | Yes | Unix time in seconds. |
| offset_minutes | Yes | UTC offset in minutes. |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only, idempotent, and non-destructive behavior, so the description does not need to repeat those. It adds useful behavioral detail about seconds/milliseconds auto-detection and exact output components, which goes beyond structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core operation is front-loaded in one sentence, and the output format list is informative rather than filler. It is a bit dense, but every clause contributes useful selection or invocation information.
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?
Together with the schema, annotations, and output schema, the description covers what the tool does, accepted input units, time-zone handling, and what the result contains. No critical behavior is missing for a read-only formatting utility; edge-case error handling is left to schema or output docs.
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?
All three parameters are fully described in the input schema (coverage 100%), so the baseline is 3. The description mostly restates unit auto-detection and time-zone semantics that the schema already provides, adding no new parameter-level facts.
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 identifies a specific operation: converting a Unix timestamp into a human-readable date in a time zone, and enumerates the output fields (ISO 8601, RFC 2822, UTC offset, DST flag, weekday, relative phrase). This clearly distinguishes it from sibling tools such as convert_timezone or parse_datetime by centering on Unix timestamp input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the appropriate use case—formatting a Unix timestamp into a calendar date—but does not explicitly name alternative tools or state when not to use it. With siblings like convert_timezone and epoch_math nearby, an agent gets inferred rather than explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert_timezoneARead-onlyIdempotentInspect
Convert a wall-clock date/time from one IANA time zone to another, correctly across daylight-saving transitions. Returns both sides with offsets, the hour difference at that instant, and whether either zone is on DST.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| datetime | Yes | ISO 8601 date/time, e.g. "2026-09-06T09:30". If it has no offset it is read as wall time in from_timezone. | |
| to_timezone | Yes | Target IANA zone, e.g. "Europe/London". | |
| from_timezone | Yes | Source IANA zone, e.g. "Asia/Tokyo". |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| source | Yes | One instant described in one IANA time zone. |
| target | Yes | One instant described in one IANA time zone. |
| difference_hours | Yes | target offset minus source offset, in hours. |
| same_instant_utc | Yes | The shared instant as ISO 8601 UTC. |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, lowering the burden. The description adds meaningful behavioral context by noting DST-safe conversion and listing the return details (offsets, hour difference, DST status), which goes beyond the 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?
Two sentences, no filler, and the core purpose is front-loaded. The second sentence concisely summarizes the return value, earning its place without bloating the description.
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?
The description plus a complete input schema and output schema cover the core usage well. It handles the main DST concern and expected return values, though it could optionally mention edge cases like ambiguous or nonexistent local times; this is not a significant gap.
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?
Schema description coverage is 100%, so the schema already documents all three parameters. The description reinforces the IANA and wall-clock concepts, but it does not add substantial meaning beyond what the schema's parameter descriptions already provide.
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?
States a specific action ('Convert'), a clear resource (wall-clock date/time), and the IANA time zone context. It differentiates itself from siblings like convert_timestamp by emphasizing wall-clock time and DST correctness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool—converting wall-clock times between time zones—and clarifies the DST handling, but it does not explicitly name alternatives or state when not to use it. Usage context is clear, but no exclusions or sibling differentiation guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
cron_next_runsARead-onlyInspect
Explain a 5- or 6-field cron expression in plain English and list its next run times in a time zone (as ISO 8601 and Unix timestamps). Use to answer "when does this cron job run next?" or to validate an expression.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Start evaluating after this date/time (ISO 8601). Defaults to now. | |
| count | No | How many upcoming runs to return. Default 5. | |
| timezone | No | Zone the schedule is evaluated in. Defaults to UTC. | |
| expression | Yes | Cron expression, e.g. "0 9 * * 1-5". |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| timezone | Yes | |
| next_runs | Yes | |
| expression | Yes | |
| description | Yes | Plain-English reading of the expression. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and non-destructive behavior, and the description adds observable behavior: plain-English explanation plus output in both ISO 8601 and Unix timestamps. It does not mention the dynamic 'from' default, but the schema covers defaults and annotations cover safety.
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 focused sentences with no filler: the first states the core function and output format, the second gives concrete use cases. Information is front-loaded and every clause earns its place.
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?
The description is complete for this tool: it explains the purpose, output format, and use cases, while parameters and return structure are covered by a 100% schema-described input and a dedicated output schema. Annotations also cover the safety profile, so no critical context is missing.
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 100%, so the baseline is 3. The description adds extra meaning by specifying '5- or 6-field' cron expressions, which clarifies the expected format beyond the schema's example. Other parameters are not elaborated, but the schema already documents them well.
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 uses a specific verb-resource pair: explain a 5- or 6-field cron expression and list its next run times. It clearly distinguishes this tool from the sibling date/time utilities, none of which handle cron expressions or next-run computation.
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 explicitly gives usage scenarios: answer 'when does this cron job run next?' or validate an expression. It does not explicitly contrast against alternatives, but the sibling tools are clearly different, making the intended context obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
date_durationARead-onlyIdempotentInspect
The exact duration between two dates or date-times: calendar years/months/days, plus total days, hours, minutes and seconds, and the number of weekdays (Mon-Fri). Handles leap years and DST via the IANA database.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | End date/time (ISO 8601 or Unix timestamp). | |
| start | Yes | Start date/time (ISO 8601 or Unix timestamp). | |
| timezone | No | IANA time zone, e.g. "America/New_York". Defaults to UTC. | |
| include_end | No | Count the end date as a full day (adds one day). Default false. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| end | Yes | One instant described in one IANA time zone. |
| days | Yes | |
| hours | Yes | |
| human | Yes | Calendar duration in words, e.g. "1 year, 2 months, 3 days". |
| start | Yes | One instant described in one IANA time zone. |
| years | Yes | |
| months | Yes | |
| minutes | Yes | |
| seconds | Yes | |
| weekdays | Yes | Monday to Friday days in the span. |
| direction | Yes | |
| total_days | Yes | |
| total_hours | Yes | |
| weekend_days | Yes | |
| total_minutes | Yes | |
| total_seconds | Yes |
TDQS
A3.9/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this tool as read-only, idempotent, and non-destructive, so the bar for extra disclosure is lower. The description adds valuable behavioral context by explicitly calling out leap-year handling and DST handling via t IANA database, and it lists what the computation includes. No contradiction with annotations exists.
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 filler; the purpose is front-loaded and the behavioral caveats are compressed into a single closing sentence. Every clause earns its place.
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?
The description covers purpose, supported date types, computation semantics, timezone handling, and output categories. With output schema and annotations covering return shape and safety, nothing important is missing for selecting and invoking the tool.
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?
Schema description coverage is 100%, so the parameter meaning is already fully documented in the input schema. The description does not add any parameter-specific guidance beyond the broader output scope, which is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes the exact duration between two dates/times and enumerates specific output categories (calendar units, total units, weekday count), which distinguishes it from date arithmetic siblings like convert_timestamp or epoch_math. It does not explicitly name a sibling or contrast itself, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used whenever a duration between two dates is needed, especially when calendar-aware totals and weekday counts are required. However, it gives no explicit guidance about when to choose this tool over days_until or other sibling date tools, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
days_untilARead-onlyInspect
Countdown to a holiday or to a date: days, hours and minutes remaining, and the next occurrence date. Pass an event slug (e.g. "christmas", "thanksgiving", "easter", "super-bowl") or a date (YYYY-MM-DD). Call with no arguments to list the known events.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | A target date (YYYY-MM-DD) or date-time (ISO 8601) instead of an event. | |
| event | No | Event slug from the known list, e.g. "christmas". | |
| timezone | No | Zone whose midnight starts the target day. Defaults to UTC. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| days | No | |
| name | No | |
| hours | No | |
| human | No | e.g. "in 12 days, 5 hours". |
| events | No | Known events (only when called with no arguments). |
| target | No | One instant described in one IANA time zone. |
| is_past | No | |
| minutes | No | |
| total_seconds | No |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this read-only and non-destructive. The description adds practical behavioral details beyond those annotations: it reports days, hours, minutes, and next occurrence, and that calling with no arguments lists known events. This is useful context an agent cannot infer from the 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loads the outcome, and uses two sentences to cover purpose, accepted inputs, examples, and the discovery mechanism. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only countdown tool with no required parameters and a full input schema plus an output schema, the description covers the important usage variations: event slug, custom date, timezone, and listing known events. Nothing critical is missing for an agent to invoke it correctly.
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 the schema already documents all three parameters. The description adds complementary meaning by explaining the event-vs-date choice, providing example slugs, specifying the YYYY-MM-DD format, and noting the no-argument behavior, which goes beyond the bare schema descriptions.
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 uses a specific verb and resource: it 'Countdown to a holiday or to a date' and specifies exactly what is returned. It clearly distinguishes this from the sibling time/date tools by focusing on countdown and next occurrence, not conversion or parsing.
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 clear usage modes: pass an event slug, pass a date, or call with no arguments to list known events. It does not explicitly contrast this with sibling tools like date_duration or time_now, but the intended usage is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
epoch_mathARead-onlyInspect
Add to or subtract from a Unix timestamp in calendar-aware units (years, months, weeks, days, hours, minutes, seconds) in a time zone, e.g. "now + 30 days" or "1748736543 - 3 months". Returns the resulting timestamp in every format.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| add | No | Units to add. | |
| subtract | No | Units to subtract. | |
| timezone | No | Zone in which calendar units (months, days across DST) are applied. Defaults to UTC. | |
| timestamp | No | Base Unix timestamp (seconds or milliseconds, auto-detected). Omit for now. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| base | Yes | One instant described in one IANA time zone. |
| result | Yes | One instant described in one IANA time zone. |
| delta_seconds | Yes | result minus base, in seconds. |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: calendar-aware units, timezone sensitivity, and returning the result in every format. However, it does not disclose edge cases such as daylight-saving ambiguity or behavior when both add and subtract are supplied.
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?
The description is one well-constructed sentence that leads with the core operation, then specifies units, timezone, examples, and return behavior. Every clause adds information without redundancy.
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?
The core operation, units, timezone sensitivity, and return richness are all covered, and the output schema handles return-value structure. Minor gaps like behavior when both add and subtract are passed together are not addressed, but do not block correct use for standard calls.
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 has 100% parameter description coverage, so the schema carries the weight for parameter meaning. The description adds value through call examples that show how timestamp, add/subtract, and timezone combine, but it does not elaborate on individual parameters beyond what the schema already states.
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 states a specific operation: adding or subtracting calendar-aware units from a Unix timestamp in a time zone. This distinguishes it clearly from conversion-focused siblings like convert_timestamp and convert_timezone. The concrete examples ('now + 30 days', '1748736543 - 3 months') make the 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context through examples and states what the tool does with a timestamp. It does not explicitly name alternatives or exclusion conditions, but the operation is specific enough that an agent can infer when to use it rather than a converter or scheduler.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
parse_datetimeARead-onlyIdempotentInspect
Parse a date/time string (ISO 8601, RFC 2822, HTTP date, SQL "YYYY-MM-DD HH:mm:ss", or a Unix timestamp) into a Unix timestamp and a normalized description. Strings without an offset are interpreted in the given time zone.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | The date/time text to parse. | |
| timezone | No | Zone to assume when the input carries no offset, and to report the result in. Defaults to UTC. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| iso | Yes | ISO 8601 with the zone offset. |
| human | Yes | Readable sentence with weekday, date, time and zone. |
| input | Yes | The text that was parsed. |
| is_dst | Yes | Whether daylight-saving time is in effect. |
| offset | Yes | UTC offset, e.g. "+09:00". |
| rfc2822 | Yes | RFC 2822 date string. |
| utc_iso | Yes | ISO 8601 in UTC (Z). |
| weekday | Yes | Full weekday name in English. |
| timezone | Yes | IANA zone name. |
| abbreviation | Yes | Zone abbreviation at that instant, e.g. "BST". |
| epoch_millis | Yes | Unix time in milliseconds. |
| epoch_seconds | Yes | Unix time in seconds. |
| offset_minutes | Yes | UTC offset in minutes. |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only and idempotent; the description adds the key behavioral rule that strings without an offset are interpreted in the given time zone, and clarifies supported format families. This context goes beyond the structured fields without contradicting them.
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 compact sentences, with the format inventory front-loaded before the timezone rule. Every clause adds information; no filler or redundant phrasing.
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?
The description covers accepted inputs, timezone behavior, and the shape of the output, and an output schema exists to document return values. It is sufficient for a straightforward parsing tool, though it omits error-handling behavior and explicit sibling comparisons.
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 descriptions already cover both parameters (100%), and the description reinforces the timezone semantics and enriches the input parameter by listing accepted formats. The added format list gives agents a clearer idea of valid 'input' values beyond the schema's generic 'date/time text'.
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 uses a specific verb ('Parse') with a concrete resource (date/time string), enumerates accepted formats, and states the output (Unix timestamp + normalized description). This clearly differentiates it from sibling tools like time_now and convert_timezone by scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for converting arbitrary date/time strings to Unix timestamps, but it does not state when to prefer it over siblings (e.g., convert_timestamp) or when not to use it. No explicit exclusions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
time_nowARead-onlyInspect
The current time: Unix epoch in seconds and milliseconds, ISO 8601, and the local wall-clock time in a given IANA time zone with its current UTC offset and DST status. Use this before any relative date reasoning.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| timezone | No | IANA time zone, e.g. "America/New_York". Defaults to UTC. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| iso | Yes | ISO 8601 with the zone offset. |
| human | Yes | Readable sentence with weekday, date, time and zone. |
| is_dst | Yes | Whether daylight-saving time is in effect. |
| offset | Yes | UTC offset, e.g. "+09:00". |
| rfc2822 | Yes | RFC 2822 date string. |
| utc_iso | Yes | ISO 8601 in UTC (Z). |
| weekday | Yes | Full weekday name in English. |
| timezone | Yes | IANA zone name. |
| abbreviation | Yes | Zone abbreviation at that instant, e.g. "BST". |
| epoch_millis | Yes | Unix time in milliseconds. |
| epoch_seconds | Yes | Unix time in seconds. |
| offset_minutes | Yes | UTC offset in minutes. |
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds return-format details, but these are likely also covered by the output schema, and it does not disclose significant behavioral context beyond what annotations and schema provide.
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?
The description is one focused sentence that leads with the core function and output formats, followed by a single, high-value usage directive. Every word earns its place with no repetition or filler.
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?
This is a simple read-only tool with zero required parameters, 100% schema coverage, an output schema, and annotations covering safety properties. The description, together with those structured signals, is fully sufficient for an agent 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the timezone parameter is already documented with type, IANA example, and default. The description mentions IANA time zones but adds no new parameter semantics beyond the schema, which warrants the baseline score of 3.
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 names the resource precisely — the current time — and enumerates the exact forms returned (Unix epoch in seconds/milliseconds, ISO 8601, wall-clock time with UTC offset and DST status). This clearly distinguishes time_now from the sibling conversion and arithmetic tools.
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 directive 'Use this before any relative date reasoning' gives a clear contextual trigger for invoking this tool. It does not explicitly name alternative tools or state when not to use it, but the guidance is actionable and meaningful for an agent deciding between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
8 tool updates
- Changed
convert_timestamp1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "description": "One instant described in one IANA time zone.", + "properties": { + "abbreviation": { + "description": "Zone abbreviation at that instant, e.g. \"BST\".", + "type": "string" + }, + "epoch_millis": { + "description": "Unix time in milliseconds.", + "type": "integer" + }, + "epoch_seconds": { + "description": "Unix time in seconds.", + "type": "integer" + }, + "human": { + "description": "Readable sentence with weekday, date, time and zone.", + "type": "string" + }, + "is_dst": { + "description": "Whether daylight-saving time is in effect.", + "type": "boolean" + }, + "iso": { + "description": "ISO 8601 with the zone offset.", + "type": "string" + }, + "offset": { + "description": "UTC offset, e.g. \"+09:00\".", + "type": "string" + }, + "offset_minutes": { + "description": "UTC offset in minutes.", + "type": "integer" + }, + "relative": { + "description": "Relative phrase such as \"3 days ago\".", + "type": "string" + }, + "rfc2822": { + "description": "RFC 2822 date string.", + "type": "string" + }, + "timezone": { + "description": "IANA zone name.", + "type": "string" + }, + "utc_iso": { + "description": "ISO 8601 in UTC (Z).", + "type": "string" + }, + "weekday": { + "description": "Full weekday name in English.", + "type": "string" + } + }, + "required": [ + "epoch_seconds", + "epoch_millis", + "iso", + "utc_iso", + "timezone", + "offset", + "offset_minutes", + "abbreviation", + "is_dst", + "weekday", + "rfc2822", + "human", + "relative" + ], + "type": "object" +}
- Changed
convert_timezone1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "difference_hours": { + "description": "target offset minus source offset, in hours.", + "type": "number" + }, + "same_instant_utc": { + "description": "The shared instant as ISO 8601 UTC.", + "type": "string" + }, + "source": { + "description": "One instant described in one IANA time zone.", + "properties": { + "abbreviation": { + "description": "Zone abbreviation at that instant, e.g. \"BST\".", + "type": "string" + }, + "epoch_millis": { + "description": "Unix time in milliseconds.", + "type": "integer" + }, + "epoch_seconds": { + "description": "Unix time in seconds.", + "type": "integer" + }, + "human": { + "description": "Readable sentence with weekday, date, time and zone.", + "type": "string" + }, + "is_dst": { + "description": "Whether daylight-saving time is in effect.", + "type": "boolean" + }, + "iso": { + "description": "ISO 8601 with the zone offset.", + "type": "string" + }, + "offset": { + "description": "UTC offset, e.g. \"+09:00\".", + "type": "string" + }, + "offset_minutes": { + "description": "UTC offset in minutes.", + "type": "integer" + }, + "rfc2822": { + "description": "RFC 2822 date string.", + "type": "string" + }, + "timezone": { + "description": "IANA zone name.", + "type": "string" + }, + "utc_iso": { + "description": "ISO 8601 in UTC (Z).", + "type": "string" + }, + "weekday": { + "description": "Full weekday name in English.", + "type": "string" + } + }, + "required": [ + "epoch_seconds", + "epoch_millis", + "iso", + "utc_iso", + "timezone", + "offset", + "offset_minutes", + "abbreviation", + "is_dst", + "weekday", + "rfc2822", + "human" + ], + "type": "object" + }, + "target": { + "description": "One instant described in one IANA time zone.", + "properties": { + "abbreviation": { + "description": "Zone abbreviation at that instant, e.g. \"BST\".", + "type": "string" + }, + "epoch_millis": { + "description": "Unix time in milliseconds.", + "type": "integer" + }, + "epoch_seconds": { + "description": "Unix time in seconds.", + "type": "integer" + }, + "human": { + "description": "Readable sentence with weekday, date, time and zone.", + "type": "string" + }, + "is_dst": { + "description": "Whether daylight-saving time is in effect.", + "type": "boolean" + }, + "iso": { + "description": "ISO 8601 with the zone offset.", + "type": "string" + }, + "offset": { + "description": "UTC offset, e.g. \"+09:00\".", + "type": "string" + }, + "offset_minutes": { + "description": "UTC offset in minutes.", + "type": "integer" + }, + "rfc2822": { + "description": "RFC 2822 date string.", + "type": "string" + }, + "timezone": { + "description": "IANA zone name.", + "type": "string" + }, + "utc_iso": { + "description": "ISO 8601 in UTC (Z).", + "type": "string" + }, + "weekday": { + "description": "Full weekday name in English.", + "type": "string" + } + }, + "required": [ + "epoch_seconds", + "epoch_millis", + "iso", + "utc_iso", + "timezone", + "offset", + "offset_minutes", + "abbreviation", + "is_dst", + "weekday", + "rfc2822", + "human" + ], + "type": "object" + } + }, + "required": [ + "source", + "target", + "difference_hours", + "same_instant_utc" + ], + "type": "object" +}
- Changed
cron_next_runs1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "description": { + "description": "Plain-English reading of the expression.", + "type": "string" + }, + "expression": { + "type": "string" + }, + "next_runs": { + "items": { + "properties": { + "epoch_seconds": { + "type": "integer" + }, + "iso": { + "type": "string" + }, + "utc_iso": { + "type": "string" + }, + "weekday": { + "type": "string" + } + }, + "required": [ + "iso", + "utc_iso", + "epoch_seconds", + "weekday" + ], + "type": "object" + }, + "type": "array" + }, + "timezone": { + "type": "string" + } + }, + "required": [ + "expression", + "description", + "timezone", + "next_runs" + ], + "type": "object" +}
- Changed
date_duration1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "days": { + "type": "integer" + }, + "direction": { + "enum": [ + "forward", + "backward" + ], + "type": "string" + }, + "end": { + "description": "One instant described in one IANA time zone.", + "properties": { + "abbreviation": { + "description": "Zone abbreviation at that instant, e.g. \"BST\".", + "type": "string" + }, + "epoch_millis": { + "description": "Unix time in milliseconds.", + "type": "integer" + }, + "epoch_seconds": { + "description": "Unix time in seconds.", + "type": "integer" + }, + "human": { + "description": "Readable sentence with weekday, date, time and zone.", + "type": "string" + }, + "is_dst": { + "description": "Whether daylight-saving time is in effect.", + "type": "boolean" + }, + "iso": { + "description": "ISO 8601 with the zone offset.", + "type": "string" + }, + "offset": { + "description": "UTC offset, e.g. \"+09:00\".", + "type": "string" + }, + "offset_minutes": { + "description": "UTC offset in minutes.", + "type": "integer" + }, + "rfc2822": { + "description": "RFC 2822 date string.", + "type": "string" + }, + "timezone": { + "description": "IANA zone name.", + "type": "string" + }, + "utc_iso": { + "description": "ISO 8601 in UTC (Z).", + "type": "string" + }, + "weekday": { + "description": "Full weekday name in English.", + "type": "string" + } + }, + "required": [ + "epoch_seconds", + "epoch_millis", + "iso", + "utc_iso", + "timezone", + "offset", + "offset_minutes", + "abbreviation", + "is_dst", + "weekday", + "rfc2822", + "human" + ], + "type": "object" + }, + "hours": { + "type": "integer" + }, + "human": { + "description": "Calendar duration in words, e.g. \"1 year, 2 months, 3 days\".", + "type": "string" + }, + "minutes": { + "type": "integer" + }, + "months": { + "type": "integer" + }, + "seconds": { + "type": "integer" + }, + "start": { + "description": "One instant described in one IANA time zone.", + "properties": { + "abbreviation": { + "description": "Zone abbreviation at that instant, e.g. \"BST\".", + "type": "string" + }, + "epoch_millis": { + "description": "Unix time in milliseconds.", + "type": "integer" + }, + "epoch_seconds": { + "description": "Unix time in seconds.", + "type": "integer" + }, + "human": { + "description": "Readable sentence with weekday, date, time and zone.", + "type": "string" + }, + "is_dst": { + "description": "Whether daylight-saving time is in effect.", + "type": "boolean" + }, + "iso": { + "description": "ISO 8601 with the zone offset.", + "type": "string" + }, + "offset": { + "description": "UTC offset, e.g. \"+09:00\".", + "type": "string" + }, + "offset_minutes": { + "description": "UTC offset in minutes.", + "type": "integer" + }, + "rfc2822": { + "description": "RFC 2822 date string.", + "type": "string" + }, + "timezone": { + "description": "IANA zone name.", + "type": "string" + }, + "utc_iso": { + "description": "ISO 8601 in UTC (Z).", + "type": "string" + }, + "weekday": { + "description": "Full weekday name in English.", + "type": "string" + } + }, + "required": [ + "epoch_seconds", + "epoch_millis", + "iso", + "utc_iso", + "timezone", + "offset", + "offset_minutes", + "abbreviation", + "is_dst", + "weekday", + "rfc2822", + "human" + ], + "type": "object" + }, + "total_days": { + "type": "integer" + }, + "total_hours": { + "type": "integer" + }, + "total_minutes": { + "type": "integer" + }, + "total_seconds": { + "type": "integer" + }, + "weekdays": { + "description": "Monday to Friday days in the span.", + "type": "integer" + }, + "weekend_days": { + "type": "integer" + }, + "years": { + "type": "integer" + } + }, + "required": [ + "start", + "end", + "direction", + "years", + "months", + "days", + "hours", + "minutes", + "seconds", + "total_days", + "total_hours", + "total_minutes", + "total_seconds", + "weekdays", + "weekend_days", + "human" + ], + "type": "object" +}
- Changed
days_until1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "description": "With an event or date: the countdown fields. With no arguments: only the events list.", + "properties": { + "days": { + "type": "integer" + }, + "events": { + "description": "Known events (only when called with no arguments).", + "items": { + "properties": { + "description": { + "type": "string" + }, + "name": { + "type": "string" + }, + "slug": { + "type": "string" + } + }, + "required": [ + "slug", + "name" + ], + "type": "object" + }, + "type": "array" + }, + "hours": { + "type": "integer" + }, + "human": { + "description": "e.g. \"in 12 days, 5 hours\".", + "type": "string" + }, + "is_past": { + "type": "boolean" + }, + "minutes": { + "type": "integer" + }, + "name": { + "type": "string" + }, + "target": { + "description": "One instant described in one IANA time zone.", + "properties": { + "abbreviation": { + "description": "Zone abbreviation at that instant, e.g. \"BST\".", + "type": "string" + }, + "epoch_millis": { + "description": "Unix time in milliseconds.", + "type": "integer" + }, + "epoch_seconds": { + "description": "Unix time in seconds.", + "type": "integer" + }, + "human": { + "description": "Readable sentence with weekday, date, time and zone.", + "type": "string" + }, + "is_dst": { + "description": "Whether daylight-saving time is in effect.", + "type": "boolean" + }, + "iso": { + "description": "ISO 8601 with the zone offset.", + "type": "string" + }, + "offset": { + "description": "UTC offset, e.g. \"+09:00\".", + "type": "string" + }, + "offset_minutes": { + "description": "UTC offset in minutes.", + "type": "integer" + }, + "rfc2822": { + "description": "RFC 2822 date string.", + "type": "string" + }, + "timezone": { + "description": "IANA zone name.", + "type": "string" + }, + "utc_iso": { + "description": "ISO 8601 in UTC (Z).", + "type": "string" + }, + "weekday": { + "description": "Full weekday name in English.", + "type": "string" + } + }, + "required": [ + "epoch_seconds", + "epoch_millis", + "iso", + "utc_iso", + "timezone", + "offset", + "offset_minutes", + "abbreviation", + "is_dst", + "weekday", + "rfc2822", + "human" + ], + "type": "object" + }, + "total_seconds": { + "type": "integer" + } + }, + "type": "object" +}
- Changed
epoch_math1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "properties": { + "base": { + "description": "One instant described in one IANA time zone.", + "properties": { + "abbreviation": { + "description": "Zone abbreviation at that instant, e.g. \"BST\".", + "type": "string" + }, + "epoch_millis": { + "description": "Unix time in milliseconds.", + "type": "integer" + }, + "epoch_seconds": { + "description": "Unix time in seconds.", + "type": "integer" + }, + "human": { + "description": "Readable sentence with weekday, date, time and zone.", + "type": "string" + }, + "is_dst": { + "description": "Whether daylight-saving time is in effect.", + "type": "boolean" + }, + "iso": { + "description": "ISO 8601 with the zone offset.", + "type": "string" + }, + "offset": { + "description": "UTC offset, e.g. \"+09:00\".", + "type": "string" + }, + "offset_minutes": { + "description": "UTC offset in minutes.", + "type": "integer" + }, + "rfc2822": { + "description": "RFC 2822 date string.", + "type": "string" + }, + "timezone": { + "description": "IANA zone name.", + "type": "string" + }, + "utc_iso": { + "description": "ISO 8601 in UTC (Z).", + "type": "string" + }, + "weekday": { + "description": "Full weekday name in English.", + "type": "string" + } + }, + "required": [ + "epoch_seconds", + "epoch_millis", + "iso", + "utc_iso", + "timezone", + "offset", + "offset_minutes", + "abbreviation", + "is_dst", + "weekday", + "rfc2822", + "human" + ], + "type": "object" + }, + "delta_seconds": { + "description": "result minus base, in seconds.", + "type": "integer" + }, + "result": { + "description": "One instant described in one IANA time zone.", + "properties": { + "abbreviation": { + "description": "Zone abbreviation at that instant, e.g. \"BST\".", + "type": "string" + }, + "epoch_millis": { + "description": "Unix time in milliseconds.", + "type": "integer" + }, + "epoch_seconds": { + "description": "Unix time in seconds.", + "type": "integer" + }, + "human": { + "description": "Readable sentence with weekday, date, time and zone.", + "type": "string" + }, + "is_dst": { + "description": "Whether daylight-saving time is in effect.", + "type": "boolean" + }, + "iso": { + "description": "ISO 8601 with the zone offset.", + "type": "string" + }, + "offset": { + "description": "UTC offset, e.g. \"+09:00\".", + "type": "string" + }, + "offset_minutes": { + "description": "UTC offset in minutes.", + "type": "integer" + }, + "rfc2822": { + "description": "RFC 2822 date string.", + "type": "string" + }, + "timezone": { + "description": "IANA zone name.", + "type": "string" + }, + "utc_iso": { + "description": "ISO 8601 in UTC (Z).", + "type": "string" + }, + "weekday": { + "description": "Full weekday name in English.", + "type": "string" + } + }, + "required": [ + "epoch_seconds", + "epoch_millis", + "iso", + "utc_iso", + "timezone", + "offset", + "offset_minutes", + "abbreviation", + "is_dst", + "weekday", + "rfc2822", + "human" + ], + "type": "object" + } + }, + "required": [ + "base", + "result", + "delta_seconds" + ], + "type": "object" +}
- Changed
parse_datetime1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "description": "One instant described in one IANA time zone.", + "properties": { + "abbreviation": { + "description": "Zone abbreviation at that instant, e.g. \"BST\".", + "type": "string" + }, + "epoch_millis": { + "description": "Unix time in milliseconds.", + "type": "integer" + }, + "epoch_seconds": { + "description": "Unix time in seconds.", + "type": "integer" + }, + "human": { + "description": "Readable sentence with weekday, date, time and zone.", + "type": "string" + }, + "input": { + "description": "The text that was parsed.", + "type": "string" + }, + "is_dst": { + "description": "Whether daylight-saving time is in effect.", + "type": "boolean" + }, + "iso": { + "description": "ISO 8601 with the zone offset.", + "type": "string" + }, + "offset": { + "description": "UTC offset, e.g. \"+09:00\".", + "type": "string" + }, + "offset_minutes": { + "description": "UTC offset in minutes.", + "type": "integer" + }, + "rfc2822": { + "description": "RFC 2822 date string.", + "type": "string" + }, + "timezone": { + "description": "IANA zone name.", + "type": "string" + }, + "utc_iso": { + "description": "ISO 8601 in UTC (Z).", + "type": "string" + }, + "weekday": { + "description": "Full weekday name in English.", + "type": "string" + } + }, + "required": [ + "epoch_seconds", + "epoch_millis", + "iso", + "utc_iso", + "timezone", + "offset", + "offset_minutes", + "abbreviation", + "is_dst", + "weekday", + "rfc2822", + "human", + "input" + ], + "type": "object" +}
- Changed
time_now1 field changed- changed
Output schema / (root)Previous value: -nullNew value: +{ + "description": "One instant described in one IANA time zone.", + "properties": { + "abbreviation": { + "description": "Zone abbreviation at that instant, e.g. \"BST\".", + "type": "string" + }, + "epoch_millis": { + "description": "Unix time in milliseconds.", + "type": "integer" + }, + "epoch_seconds": { + "description": "Unix time in seconds.", + "type": "integer" + }, + "human": { + "description": "Readable sentence with weekday, date, time and zone.", + "type": "string" + }, + "is_dst": { + "description": "Whether daylight-saving time is in effect.", + "type": "boolean" + }, + "iso": { + "description": "ISO 8601 with the zone offset.", + "type": "string" + }, + "offset": { + "description": "UTC offset, e.g. \"+09:00\".", + "type": "string" + }, + "offset_minutes": { + "description": "UTC offset in minutes.", + "type": "integer" + }, + "rfc2822": { + "description": "RFC 2822 date string.", + "type": "string" + }, + "timezone": { + "description": "IANA zone name.", + "type": "string" + }, + "utc_iso": { + "description": "ISO 8601 in UTC (Z).", + "type": "string" + }, + "weekday": { + "description": "Full weekday name in English.", + "type": "string" + } + }, + "required": [ + "epoch_seconds", + "epoch_millis", + "iso", + "utc_iso", + "timezone", + "offset", + "offset_minutes", + "abbreviation", + "is_dst", + "weekday", + "rfc2822", + "human" + ], + "type": "object" +}
8 tool updates
- First observed
convert_timestamp - First observed
convert_timezone - First observed
cron_next_runs - First observed
date_duration - First observed
days_until - First observed
epoch_math - First observed
parse_datetime - First observed
time_now
Frequently Asked Questions
Claiming 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 asio.github.acme/serveralso 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.jsonon 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.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Deterministic time tools for AI agents: timezone conversion, business-day math, cron interpretation.
Current time, timezone conversion & date math for AI agents. On Cloudflare Workers.
60+ units, live FX, timezones, and date arithmetic for AI agents.
A real clock for AI agents: current time, timezone conversion, and DST facts from the IANA tzdb.
Related MCP Servers
- AlicenseAqualityBmaintenanceProvides comprehensive date, time, timezone, and calendar operations powered by Luxon, enabling AI agents to perform time calculations, timezone conversions, and temporal data handling across 400+ IANA timezones.224MIT
- AlicenseAqualityCmaintenanceEnables timezone conversion, astronomical calculations, and date utilities through natural language, supporting sunrise/sunset, moon phases, business days, and more.91351ISC
- FlicenseNot gradedqualityCmaintenanceProvides current time, relative time, timezone conversion, timestamps, and more for LLMs.-
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.1/5.0
Disambiguation5/5
Each tool targets a distinct date/time operation: conversion, timezone shifting, cron scheduling, duration, countdown, arithmetic, parsing, and current time. Even the inverse operations (convert_timestamp vs parse_datetime) are clearly separated by input/output direction.
Naming Consistency3/5
Names are uniformly snake_case and readable, but they mix verb_noun patterns (convert_timestamp, parse_datetime) with noun-phrase or query-style names (date_duration, time_now, days_until, epoch_math, cron_next_runs). This is consistent in style but not in grammatical pattern.
Tool Count5/5
Eight tools is well-scoped for a date/time and epoch calculator. Each tool covers a distinct facet of the domain without redundancy or bloat.
Completeness5/5
The tool surface covers the full lifecycle of date/time operations: current time, parsing, formatting, timezone conversion, arithmetic, duration, countdowns, and cron scheduling. No significant gaps that would block common use cases.