Time Tools MCP Server

by t-shiratori

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap. For example, convert_datetime_to_unix and convert_unix_to_datetime are inverse operations, get_current_date_time and get_current_date_time_iso provide different formats, and get_elapsed_time calculates differences, making misselection unlikely.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case (e.g., convert_datetime_to_unix, get_current_date_time). The naming is predictable and readable throughout the set, with no deviations in style or convention.
Tool Count5/5
With 7 tools, the count is well-scoped for a time utility server. Each tool serves a specific function in time conversion, retrieval, and calculation, with no redundancy or missing essential operations, making the set efficient and focused.
Completeness4/5
The tool set covers core time operations like conversion, current time retrieval, elapsed time calculation, and timezone handling. Minor gaps might include operations like timezone conversion or date arithmetic, but agents can work around these with the provided tools.
Average 3.1/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 only states the conversion action with an example but does not cover important traits like error handling (e.g., invalid datetime formats), timezone handling implications, or output format details. This leaves significant gaps in understanding the tool's behavior.
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 extremely concise and front-loaded, consisting of a single sentence with a clear example. Every word serves a purpose, making it efficient and easy to parse without any wasted information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a conversion function with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It fails to explain key aspects such as the return value format, error conditions, or how the 'timezone' parameter affects the conversion, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It mentions 'datetime time' and provides an example format, which adds some meaning for the 'time' parameter. However, it does not address the 'timezone' parameter at all, leaving it undocumented. This partial coverage is insufficient for the schema's needs.
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's purpose: converting datetime to unixtime with an example. It specifies the verb 'convert' and the resource 'datetime time to unixtime', making the function unambiguous. However, it does not explicitly differentiate from sibling tools like 'convert_unix_to_datetime' or 'get_unixtime', which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 lacks context such as when this conversion is needed, prerequisites, or comparisons to sibling tools like 'convert_unix_to_datetime' or 'get_unixtime'. This absence of usage instructions leaves the agent without clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 describes the basic conversion behavior but omits key details: default timezone handling, the effect of the isISO parameter, error handling for invalid inputs, and output format specifics. For a tool with 3 parameters and no annotation coverage, this is insufficient.
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 extremely concise and front-loaded, using a single sentence with a clear example. Every word earns its place, making it easy to scan and understand the core purpose without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the output format beyond the example, how parameters interact, or potential errors. For a conversion tool with multiple options, more context is needed to ensure correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions the unixtime parameter implicitly via the example, but provides no information about timezone (e.g., format like 'UTC' or 'America/New_York') or isISO (e.g., whether it outputs ISO 8601 format). This leaves two parameters undocumented, failing to address the coverage gap.
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's function: converting Unix time to datetime format, with a specific example (1746627290 to 2025-01-01 01:01:01). It distinguishes from siblings like convert_datetime_to_unix by specifying the direction of conversion. However, it doesn't explicitly mention all siblings, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 get_current_date_time or get_unixtime. It lacks context about scenarios where Unix time conversion is needed, such as processing timestamps from APIs or logs. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 current time in ISO 8601 format with an example, but doesn't mention if it's read-only, requires permissions, has rate limits, or how it handles the optional timezone parameter. This leaves gaps in understanding the tool's behavior beyond basic output format.
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 extremely concise—a single sentence with a helpful example. It's front-loaded with the core purpose and wastes no words, making it easy for an agent to parse quickly. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single optional parameter, no output schema, no annotations), the description is minimally adequate. It covers the output format with an example, but lacks details on parameter usage, behavioral traits, or differentiation from siblings. For a simple time-fetching tool, it's passable but leaves room for improvement in context.
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 one parameter 'timezone' with 0% description coverage. The tool description doesn't mention parameters at all, failing to compensate for the schema gap. However, with only one optional parameter, the baseline is moderate, but the description adds no value beyond what the bare schema provides.
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 verb 'Get' and the resource 'ISO 8601 time', with an example format provided. It distinguishes from siblings like 'get_current_date_time' by specifying the ISO format, though it doesn't explicitly contrast with all siblings. The purpose 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_current_date_time' or 'get_unixtime'. The description implies usage for obtaining current time in ISO format, but lacks explicit when/when-not instructions or named alternatives, leaving the agent to infer based on format differences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 what the tool does but doesn't describe how it behaves: no information about error handling (e.g., invalid date formats), timezone considerations, rounding behavior, or output format. The example helps but doesn't cover behavioral traits.
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 a single, efficient sentence with a helpful example. It's front-loaded with the core purpose and uses minimal words to convey the essential information without any wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on parameter usage, error handling, and output format. For a time calculation tool, more context on date-time formats and result interpretation would be helpful.
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 description mentions 'two datetimes' which maps to the 'from' and 'to' parameters, and the example shows date-time strings. However, with 0% schema description coverage, it doesn't explain the 'unit' parameter or its enum values. The description adds some meaning but doesn't fully compensate for the schema coverage gap.
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's purpose: 'Get the difference time between two datetimes' with a specific example. It uses a clear verb ('Get') and resource ('difference time'), but doesn't explicitly differentiate from sibling tools like 'get_current_date_time' or 'convert_datetime_to_unix' which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 suggest scenarios where this tool is preferred over others like 'get_current_date_time' for current time or conversion tools for format changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. The description only states what the tool returns ('timezone') without explaining how it determines which timezone, whether it requires any context or permissions, what format the return value uses, or whether it's static or dynamic. For a tool with zero annotation coverage, this is insufficient behavioral context.
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 extremely concise (5 words plus an example) and front-loaded with the core purpose. Every word earns its place - 'Get' specifies the action, 'timezone' specifies the resource, and the example provides helpful clarification. No wasted words or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 kind of timezone is returned (system default? user preference? based on location?), the return format, or any behavioral characteristics. For a tool that might have implementation nuances (e.g., server timezone vs. client timezone), more context is needed despite the simple parameterless design.
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?
The tool has zero parameters, and schema description coverage is 100% (though the schema is empty). The description appropriately doesn't discuss parameters since none exist. It focuses on the return value ('timezone') which is correct for a parameterless tool. Baseline for zero parameters is 4.
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's purpose with a specific verb ('Get') and resource ('timezone'), and provides a helpful example ('Asia/Tokyo'). It distinguishes from siblings by focusing on timezone retrieval rather than datetime conversion or elapsed time calculations. However, it doesn't explicitly differentiate from all siblings (like get_current_date_time which might also return timezone).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With multiple sibling tools for datetime operations (convert_datetime_to_unix, get_current_date_time, etc.), there's no indication whether this returns the system timezone, a user's timezone, or supports location-based lookup. No explicit when/when-not or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states what the tool returns ('unixtime') but doesn't disclose behavioral traits like whether it returns current system time, requires network access, has rate limits, or provides timezone context. The example suggests it returns a numeric timestamp, but that's implied by 'unixtime' itself.
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 extremely concise (one short sentence with a helpful example) and front-loaded with the core purpose. Every word earns its place—'Get' establishes the action, 'unixtime' specifies the resource, and the example clarifies the format without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is minimally adequate. It tells the agent what the tool returns but lacks context about time source, precision, or differences from sibling tools. For a basic time-fetching tool, this might suffice, but gaps remain in behavioral transparency.
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?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the output. This meets the baseline of 4 for zero-parameter tools.
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 verb ('Get') and resource ('unixtime'), providing a concrete example (1746627290) that illustrates the output format. However, it doesn't differentiate from siblings like 'get_current_date_time' or 'convert_datetime_to_unix', which might return similar time-related data in different formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With siblings like 'get_current_date_time' (which might return human-readable time) and conversion tools, the agent has no indication whether this tool is for current time, a specific time, or general Unix time retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states what the tool returns (current datetime with example format) but lacks behavioral details like whether it's real-time, if it uses system time, error handling, or performance characteristics.
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?
Single sentence with zero waste, front-loaded with the core purpose. The example format is efficiently included as parenthetical clarification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 1 parameter, no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and output format but lacks parameter documentation and behavioral context that would be helpful given the absence of structured fields.
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 0%, but the description does not mention the 'timezone' parameter at all. However, with only 1 parameter and no schema descriptions, the baseline is high. The description adds value by specifying the output format example, but misses parameter context.
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 clearly states the verb 'Get' and the resource 'current date and time', with a specific example format. It distinguishes from siblings like get_current_date_time_iso (ISO format) and get_unixtime (Unix timestamp).
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 implies usage for obtaining current datetime in a specific format, but does not explicitly state when to use this vs. alternatives like get_current_date_time_iso or get_unixtime. The context is clear but lacks explicit sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![time-tools-mcp-server MCP server](https://glama.ai/mcp/servers/t-shiratori/time-tools-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/t-shiratori/time-tools-mcp-server)

Score Badge

Copy to your README.md:

[![time-tools-mcp-server MCP server](https://glama.ai/mcp/servers/t-shiratori/time-tools-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/t-shiratori/time-tools-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/t-shiratori/time-tools-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server