mcp-time
Server Details
Time MCP server via HTTP
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- mcpcentral-io/mcp-time
- GitHub Stars
- 1
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.1/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose with no overlap: convert_time handles timezone conversion, current_time provides current time, days_in_month gives calendar information, get_timestamp converts to Unix time, get_week_year provides week numbering, and relative_time calculates time differences. An agent can easily distinguish between these operations.
The naming follows a consistent verb_noun pattern throughout (convert_time, current_time, days_in_month, get_timestamp, get_week_year, relative_time), with all tools using snake_case. The minor deviation is that 'relative_time' uses an adjective rather than a verb, but this is still readable and maintains overall consistency.
With 6 tools, this is well-scoped for a time-related server. Each tool earns its place by covering distinct aspects of time operations (conversion, current time, calendar info, timestamping, week numbering, and relative calculations), avoiding both bloat and thin functionality.
The toolset covers core time operations comprehensively, including conversion, current time retrieval, calendar details, timestamping, week info, and relative time. A minor gap is the lack of date arithmetic (e.g., add/subtract days) or time formatting tools, but agents can work around this with existing tools.
Available Tools
6 toolsconvert_timeConvert TimezoneCRead-onlyIdempotentInspect
Converts a time from a source IANA timezone to a target IANA timezone.
| Name | Required | Description | Default |
|---|---|---|---|
| time | Yes | The time to convert (e.g., "2025-03-23 12:30:00") | |
| sourceTimezone | Yes | Source IANA timezone name (e.g., "Asia/Shanghai") | |
| targetTimezone | Yes | Target IANA timezone name (e.g., "Europe/London") |
Output Schema
| Name | Required | Description |
|---|---|---|
| convertedTime | Yes | |
| hourDifference | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the conversion action but lacks critical details: whether it handles daylight saving time, error handling for invalid timezones, input format constraints beyond the example, or output format. For a tool with no annotation coverage, this leaves significant behavioral gaps.
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 a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part ('converts a time from a source timezone to a target timezone') directly contributes to understanding the tool's function, with zero waste or 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?
Given no annotations, no output schema, and 3 parameters, the description is incomplete. It doesn't cover behavioral aspects like error handling or output format, and while the schema documents parameters well, the overall context for safe and effective use is lacking. For a conversion tool with no structured safety or output info, more descriptive guidance is needed.
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%, with each parameter clearly documented in the schema (e.g., time format example, IANA timezone names). The description adds no additional parameter semantics beyond what the schema provides, such as explaining relationships between parameters or edge cases. Baseline 3 is appropriate when the schema does the heavy lifting.
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's purpose: converting time between timezones with specific verbs ('converts') and resources ('time', 'source timezone', 'target timezone'). It distinguishes from siblings like 'current_time' or 'get_timestamp' by focusing on conversion rather than retrieval or calculation. However, it doesn't explicitly differentiate from all siblings (e.g., 'relative_time' might also involve time manipulation), keeping it at 4 instead of 5.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when-not-to-use scenarios, or compare with sibling tools like 'relative_time' for time calculations or 'current_time' for current time retrieval. The agent must infer usage purely from the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
current_timeGet Current TimeBRead-onlyIdempotentInspect
Returns the current time in UTC and a specified or guessed IANA timezone.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Format for the returned time string (default YYYY-MM-DD HH:mm:ss) | |
| timezone | No | IANA timezone name (e.g., "America/New_York"). Defaults to the server's guessed timezone |
Output Schema
| Name | Required | Description |
|---|---|---|
| utcTime | Yes | |
| timezone | Yes | |
| localTime | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the timezone defaults to 'the server's guessed timezone,' which adds some context, but does not cover other traits like error handling, performance, or output format details. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
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 a single, efficient sentence that front-loads the core purpose without unnecessary details. It is appropriately sized and wastes no words, making it easy to parse quickly.
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 low complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and hints at default behavior, but lacks details on output format, error cases, or integration with sibling tools. Without annotations or output schema, more context would be beneficial for full completeness.
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 schema already documents both parameters ('format' and 'timezone') with descriptions and defaults. The description adds marginal value by implying the timezone can be 'specified or guessed,' but does not provide additional semantics beyond what the schema offers. Baseline 3 is appropriate as the schema handles most parameter documentation.
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's purpose: 'Returns the current time in UTC and a specified or guessed timezone.' It specifies the verb ('Returns'), resource ('current time'), and scope ('UTC and a specified or guessed timezone'), but does not explicitly differentiate it from sibling tools like 'get_timestamp' or 'convert_time', which might offer similar time-related functionality.
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 no guidance on when to use this tool versus alternatives. It does not mention sibling tools or contexts where this tool is preferred, such as for real-time queries versus conversions or historical data. Usage is implied by the purpose but lacks explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
days_in_monthGet Days in MonthBRead-onlyIdempotentInspect
Returns the number of days in the month of a given date.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | The date to check (format: YYYY-MM-DD). Defaults to current date |
Output Schema
| Name | Required | Description |
|---|---|---|
| days | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns a number but doesn't specify output format (e.g., integer), error handling (e.g., for invalid dates), or performance considerations. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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 a single, efficient sentence that front-loads the core functionality. It wastes no words and directly communicates the tool's purpose, making it easy to parse and understand quickly.
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 low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on output format, error cases, and usage context. For a simple tool, this might suffice, but it doesn't provide a complete picture for reliable agent invocation.
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, with the 'date' parameter fully documented in the schema. The description adds no additional parameter semantics beyond implying the date is used to determine the month. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate or add value beyond the schema.
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's function: 'Returns the number of days in the month of a given date.' It specifies the verb ('Returns') and resource ('number of days in the month'), making the purpose unambiguous. However, it doesn't explicitly differentiate from siblings like 'get_week_year' or 'convert_time', which handle different temporal calculations.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or contexts where this is preferred over other date-related operations. The user must infer usage from the purpose alone, which is insufficient for clear decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_timestampGet Unix TimestampARead-onlyIdempotentInspect
Converts a date-time string to a Unix timestamp in milliseconds.
| Name | Required | Description | Default |
|---|---|---|---|
| time | No | The time to convert (format: YYYY-MM-DD HH:mm:ss). Defaults to current time |
Output Schema
| Name | Required | Description |
|---|---|---|
| timestamp | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the conversion behavior but lacks details on error handling (e.g., invalid formats), timezone assumptions, or output specifics beyond 'Unix timestamp in milliseconds'. This is a significant gap for a tool with no annotation coverage.
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 a single, efficient sentence that front-loads the core purpose with zero waste. It is appropriately sized for a simple tool and avoids unnecessary elaboration.
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 low complexity (one parameter, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic operation but lacks behavioral context like error handling or timezone details, which are needed for full usability despite the simple schema.
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 schema already documents the 'time' parameter with its format. The description adds no additional parameter details beyond what the schema provides, such as examples or edge cases, meeting the baseline for high schema coverage.
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 specific action ('Converts') and resource ('a date-time string to a Unix timestamp in milliseconds'), distinguishing it from siblings like 'current_time' (which gets current time) or 'convert_time' (which might convert between formats). It precisely defines the transformation without tautology.
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 implies usage for converting date-time strings to timestamps, but does not explicitly state when to use this tool versus alternatives like 'convert_time' or 'relative_time'. It provides basic context but lacks guidance on exclusions or specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_week_yearGet Week of YearBRead-onlyIdempotentInspect
Returns the week number and ISO week number for a given date.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | The date to check (e.g., "2025-03-23"). Defaults to current date |
Output Schema
| Name | Required | Description |
|---|---|---|
| week | Yes | |
| isoWeek | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns week information but doesn't disclose behavioral traits such as error handling for invalid dates, timezone considerations, output format details, or whether it's read-only or has side effects. This leaves significant gaps for a tool with no annotation coverage.
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 a single, efficient sentence that directly states the tool's function without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand quickly.
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 low complexity (one parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose but lacks details on output format, error cases, and usage context, which are needed for full agent understanding despite the simple schema.
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 description adds minimal meaning beyond the input schema, which has 100% coverage for the single parameter 'date'. It implies the parameter is used to check the week number but doesn't provide additional context like date format requirements or examples beyond what the schema already specifies. Baseline 3 is appropriate given the high schema coverage.
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's purpose with a specific verb ('Returns') and resource ('week and ISO week number'), and specifies the input ('for a given date'). However, it doesn't distinguish this from sibling tools like 'get_timestamp' or 'current_time' that also process dates, missing full differentiation.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_timestamp' for timestamps or 'current_time' for current date operations, nor does it specify prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
relative_timeGet Relative TimeCRead-onlyIdempotentInspect
Calculates the relative time from now to a given date-time string.
| Name | Required | Description | Default |
|---|---|---|---|
| time | Yes | The time to compare (format: YYYY-MM-DD HH:mm:ss) |
Output Schema
| Name | Required | Description |
|---|---|---|
| relativeTime | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves—for example, whether it returns a human-readable string, a numeric offset, timezone handling, error conditions, or performance characteristics. This leaves significant gaps for a tool with no annotation coverage.
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 a single, efficient sentence that directly states the tool's function without any fluff. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a string like '2 days ago' or a duration in seconds), error handling, or edge cases. For a time calculation tool with no structured output information, this leaves the agent guessing about the result format.
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, with the 'time' parameter documented in the schema. The description adds no additional meaning beyond implying a comparison to 'now', which is already suggested by the tool's purpose. This meets the baseline of 3 when the schema does the heavy lifting.
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's purpose with a specific verb ('calculates') and resource ('relative time from now to a given time string'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'convert_time' or 'get_timestamp', which might also involve time calculations.
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 no guidance on when to use this tool versus alternatives like 'convert_time' or 'current_time'. It lacks context about typical use cases, prerequisites, or exclusions, leaving the agent to infer usage based on the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!