mcp-datetime

Server Quality Checklist

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

Latest release: v1.0.4
Disambiguation4/5
Most tools have distinct purposes, but date_diff, countdown, and business_days all involve date differences, creating potential confusion. Descriptions help clarify boundaries, but the overlap between date_diff and countdown remains somewhat vague.
Naming Consistency2/5
Tool names use a mix of verb_noun (convert_timezone, format_date, explain_cron), noun phrases (date_math, unix_timestamp, business_days, countdown, date_info), and a bare keyword (now). No consistent convention is followed.
Tool Count5/5
10 tools is well-scoped for a datetime utility server, covering current time, conversions, arithmetic, formatting, business days, and cron explanation without unnecessary bloat.
Completeness4/5
The set covers most core datetime operations, but lacks a general date string parser (only unix_timestamp converts to/from ISO) and business_days excludes holidays, not just weekends. These are minor gaps that agents can work around.
Average 3.7/5 across 10 of 10 tools scored. Lowest: 2.9/5.
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, the description carries full responsibility for behavioral disclosure. It only states the basic calculation direction, but does not mention output format (e.g., days, milliseconds, human-readable), timezone handling, or any edge cases (e.g., past vs future targets). This lack of detail leaves significant ambiguity for an agent invoking the tool.
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, concise sentence that is front-loaded with the key action ('Calculate time remaining') and efficiently communicates the tool's dual purpose. There is no redundant or filler content.
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?
The tool is simple, but due to the absence of an output schema and annotations, the description should have explained what the tool returns (e.g., duration unit, format). It does not, leaving a significant gap. The mention of 'from' as optional reference is not in the description, further limiting completeness for non-default usage.
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%, with clear descriptions for both parameters ('Reference date (default: now)' and 'Target date (ISO 8601)'). The tool description adds minimal value beyond the schema, only implying the relationship between target and from. Since the schema already documents parameters well, a baseline of 3 is appropriate.
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: calculate time remaining or elapsed relative to a target date. It uses a specific verb ('Calculate') and resource ('time remaining... target date'). While it doesn't explicitly distinguish itself from sibling tools like date_diff, the focus on 'until' and 'since' implies a reference to now, providing moderate differentiation.
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. The description does not mention sibling tools or scenarios where date_diff or formatters would be preferred. The usage context is implied by the tool's name and basic function, but not explicit.
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, the description carries the full burden of behavioral disclosure, but it only restates the basic conversion operation. It does not reveal the output format, handling of invalid timezones, DST behavior, or any side effects, which are significant gaps for an agent.
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 concise sentence with no filler, directly stating the tool's purpose in a front-loaded manner. Every word earns its place.
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 absence of annotations and output schema, this description is too minimal. It does not specify the return value format or edge-case behavior, leaving ambiguity about what the agent should expect after invocation. Sibling tools are not referenced to provide further 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 already covers all parameters with descriptions, including examples for from_tz and 'now' for datetime. The description adds no additional parameter details, so the schema provides sufficient semantics. Baseline 3 applies.
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 'Convert' and the resource 'date/time from one timezone to another', which unambiguously distinguishes it from sibling tools like format_date or unix_timestamp. It is specific and immediately understandable.
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 does not mention any exclusions, prerequisites, or alternative tools, leaving the agent to infer usage solely from the tool name and generic description.
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. It states the operation and units but does not mention return format, timezone handling, or edge cases like invalid dates. For a calculation tool, this leaves important behavioral aspects undisclosed.
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 concise sentence that front-loads the core operation. It wastes no words and is easy to parse quickly.
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?
The tool has a nested object and no output schema, so the description should explain the return value or typical use cases. It only covers the operation, leaving the agent uncertain about what the tool returns (e.g., an ISO string) and how it handles edge cases. For a moderately complex tool with no annotations, this is incomplete.
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 already describes both parameters with 100% coverage, including the date format and the add object's negative-value behavior. The description's enumeration of units adds minimal value beyond the schema, so the baseline score of 3 is appropriate.
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 ('add or subtract') and resource ('time from a date'), and enumerates the supported units. This clearly distinguishes it from sibling tools like date_diff (which computes differences) and format_date (which formats dates).
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 usage for date offset calculations but does not explicitly state when to use this tool versus alternatives like date_diff or business_days. No exclusions or alternative tool references are provided, so the guidance remains implicit.
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, the description carries full responsibility for behavioral disclosure. It mentions that the result includes multiple units, but it does not explain the output format (e.g., whether it returns an object with all units, a single choice, or a signed difference), the behavior when 'from' is later than 'to', or special handling of 'now'. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence that delivers the core purpose and supported units without any filler. It is well-formatted and front-loaded with the primary action, making it easy to parse quickly.
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?
The tool is simple with only two parameters, all documented in the schema. However, the absence of an output schema and annotations means the description should at least indicate the return structure or notable behaviors. The current text states units but not how they are returned, leaving the description slightly incomplete for a tool that yields a multi-unit result.
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 schema provides 100% coverage with clear descriptions for both parameters ('Start date (ISO 8601 or now)' and 'End date (ISO 8601 or now)'). The description adds no additional parameter semantics beyond restating that there are two dates, so the baseline of 3 applies.
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 action 'calculate the difference between two dates' with a specific resource (dates). It lists the output units (days, hours, minutes, seconds, weeks, business days), distinguishing it from sibling tools like business_days or date_math. The verb+resource structure leaves no ambiguity about the tool's purpose.
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 when needing a date difference, but provides no explicit comparison to alternatives like business_days or date_math. There is no mention of when-not-to-use or a recommended choice among siblings, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 lists the type of information returned but does not disclose behavior for 'now', timezone assumptions, error handling for invalid dates, or that it is a read-only operation. The list of outputs is helpful but under-specified.
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 sentence that starts with the verb and resource, followed by examples of the returned data. Every word is substantive; there's no filler.
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?
For a simple one-parameter tool, the description covers the main purpose and sample outputs, but 'and more' is vague and there is no mention of timezone handling or the structure of the response. Since there is no output schema, the description could be more explicit about the return format, but it is largely adequate.
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 already documents the single 'date' parameter with description 'ISO 8601 or now', providing 100% coverage. The description adds no extra semantic detail beyond what the schema already states, so baseline 3 applies.
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 ('Get') and resource ('detailed information about a date'), listing concrete attributes (day of week, ISO week number, day of year, leap year, quarter), which clearly distinguishes it from sibling tools like date_math, date_diff, and format_date.
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 on when to use this tool versus alternatives is provided. The description doesn't mention when users should prefer date_info over date_math or format_date, nor does it note any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose the key weekend-exclusion rule. Yet it omits details about holiday handling, endpoint inclusivity for 'between', and behavior for reversed date ranges, which are important for accurate usage.
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 concise, front-loaded sentences with no redundant wording. Every phrase contributes meaning, making it easy to scan.
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?
For a simple tool with a well-described schema, the description covers core functionality and the weekend rule. It lacks return-type details and a holiday caveat, but these are not critical given the tool's simplicity.
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 already describes all four parameters with 100% coverage. The description adds only minor reinforcement of operation semantics, but does not provide new information about parameter formats or constraints beyond the schema.
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 two specific operations: counting business days between dates and adding business days to a date. It names the resource (dates) and distinguishes itself from siblings like date_diff by specifying weekend exclusion.
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 when to use it (when business days are needed) and explains the two operation types. However, it does not explicitly mention alternatives or when not to use it, leaving differentiation to the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the token set (YYYY, MM, etc.), which is useful, but it does not mention timezone handling, invalid input behavior, or other edge cases that could affect formatting.
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 sentence with a compact token list. It is front-loaded with the core purpose and wastes no words.
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?
For a simple two-parameter tool, the description plus schema cover the essential usage. The only notable gap is timezone behavior, but this may not be critical given the token set. No output schema exists, so return value explanation is not required.
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, so the baseline is 3. The description adds the list of valid tokens, which directly enriches the format parameter's meaning and goes beyond the schema example.
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 tool formats a date/time using a format string, which is a specific verb+resource. It also enumerates the supported tokens, making it distinct from sibling tools like convert_timezone or date_diff.
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 formatting dates with custom tokens, but it does not explicitly mention when to prefer this over alternative date tools or any exclusions. No comparison to siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 does disclose the return formats (ISO 8601, Unix timestamp, human-readable), but it does not explicitly state that the tool is read-only or free from side effects. For a simple 'now' tool, the implicit 'Get' suggests non-destructive behavior, but more direct disclosure would elevate the score.
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 precise and front-loaded: two sentences, no filler. Every word contributes to understanding the tool's purpose and output format. It is appropriately concise for the tool's simplicity.
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?
Given the tool's trivial nature (one optional parameter, no output schema), the description covers the essential aspects: what it does and what it returns. It does not describe the exact structure of the return value for multiple timezones, but this is not critical given the simple use case. The description is nearly complete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the sole parameter 'timezones' is described in the schema. The description adds the notion of 'one or more' and gives examples, but this is marginal value over the schema's default documentation. The baseline score of 3 applies because the schema already carries the semantics.
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 the specific verb 'Get' and clearly states the resource as 'the current date and time', scoped to 'one or more timezones'. This distinguishes it from sibling tools like unix_timestamp, format_date, and date_diff, which focus on conversion or calculation rather than retrieval of the current instant.
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 clearly implies the tool is for retrieving current date/time across multiple timezones, which is a distinct use case among siblings. It does not explicitly state exclusions or alternatives, but the context is clear enough that an agent would know when to select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does explain the bidirectional conversion behavior, which is good. But it omits details about the 'now' special value (mentioned in the schema) and does not discuss edge cases like error handling or ambiguous inputs. For such a simple tool, this is adequate but not comprehensive.
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, front-loaded sentence that states the tool's purpose and usage without wasted words. Every clause earns its place, making it highly concise and well-structured.
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?
Given the tool's low complexity (one parameter, no output schema, no nested objects), the description covers the essential behavior well. It explains the two conversion directions and implicitly covers the accepted input types. It could have mentioned the 'now' special value from the schema, but the schema itself handles that, so the description's coverage is sufficient for an agent to use the tool 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% for the single parameter 'value', so the baseline is 3. The description adds value by explaining the input-output relationship ('Pass a timestamp to get ISO, or a date to get timestamp'), which goes beyond the schema's type enumeration. It clarifies that the direction of conversion depends on the input format, which the schema does not explicitly convey.
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 opens with 'Convert between Unix timestamps and ISO 8601 dates', which is a specific verb+resource pair. It clearly distinguishes this from sibling tools like 'convert_timezone' (timezone conversion) and 'format_date' (date formatting), making the purpose unambiguous.
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 provides clear usage direction: 'Pass a timestamp to get ISO, or a date to get timestamp.' This tells the agent exactly what input leads to what output. However, it does not explicitly mention when not to use this tool versus alternatives like 'convert_timezone' or 'date_math', so it lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states the supported input format ('standard 5-field cron format') and the output nature ('plain English'). This adds valuable context about constraints, though it could mention error handling or unsupported variants. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the purpose and followed by a precise format specification. Every word earns its place; no redundancy or fluff.
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?
For a tool with one parameter and no output schema, the description sufficiently covers the core function and output type ('plain English'). It also communicates the accepted input format. It could touch on edge cases (e.g., invalid expressions), but the described scope is clear and complete for typical usage.
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 schema already describes the 'expression' parameter with examples (100% coverage), so the baseline is 3. The description adds meaning by explicitly enumerating the field order ('minute hour dom month dow'), which is not in the schema. This enriches understanding beyond the parameter description.
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: 'Explain a cron expression in plain English.' It clearly distinguishes from sibling date/time tools (now, date_diff, etc.) by targeting cron expression interpretation. The supported format is also specified, adding precision.
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 makes it clear when to use the tool: whenever a cron expression needs to be translated into human-readable text. It does not explicitly name alternatives or exclusions, but the context is evident from the sibling list and the description's clarity. No misleading guidance.
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:

[![mcp-datetime MCP server](https://glama.ai/mcp/servers/hlteoh37/mcp-datetime/badges/card.svg)](https://glama.ai/mcp/servers/hlteoh37/mcp-datetime)

Score Badge

Copy to your README.md:

[![mcp-datetime MCP server](https://glama.ai/mcp/servers/hlteoh37/mcp-datetime/badges/score.svg)](https://glama.ai/mcp/servers/hlteoh37/mcp-datetime)

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/hlteoh37/mcp-datetime'

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