@findtime/mcp-server

Server Quality Checklist

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

Latest release: v3.27.0
Disambiguation4/5
Tools are well-differentiated with clear instructions. The answer_time_question tool is explicitly designated for relative-date queries, while specific tools like convert_time, get_current_time, and find_meeting_time are for exact dates or current moment. Some potential confusion between time_snapshot and get_current_time, which both return time-related payloads, but descriptions help distinguish them.
Naming Consistency4/5
Most tools follow a verb_noun pattern (get_current_time, convert_time, search_timezones, etc.). One deviation is time_snapshot, which is noun_verb, and answer_time_question follows the pattern. Overall, the naming is consistent and readable, with only a minor deviation.
Tool Count4/5
11 tools is a reasonable number for a time-intelligence server. The set includes core operations (conversion, current time, overlap, meeting time), utility (search, location lookup), diagnostics, help, and an entry point. There is slight redundancy between time_snapshot and get_current_time, but the count is not excessive or insufficient.
Completeness4/5
The tool set covers the major time-related workflows: current time, conversion, DST schedule, overlap, meeting suggestions, and location resolution. It also includes diagnostics and help for enterprise deployment. It lacks some advanced features like timezone math or calendar integration, but for its stated purpose it appears comprehensive.
Average 3.8/5 across 11 of 11 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are present, so the description carries the full transparency burden. It does not disclose what the snapshot payload contains, how query and locations interact, or any edge cases or limitations. Only the basic return action and scope are stated.
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 no filler, and the primary operation is front-loaded. It is as concise as possible, though the brevity trades away contextual depth.
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?
With six parameters, no output schema, and no annotations, the description is too thin: it never explains the payload shape, the relationship between query and locations, or the intended use case. An agent may struggle to select this tool over get_current_time or combine parameters 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?
Most parameter meaning is provided by the input schema, which documents query, locations, country code hints, and includeTransitions. The description only restates the one/location list dimension and adds little beyond what the schema already covers.
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 names a clear action ('Return'), a specific resource ('production time snapshot payload'), and a scope ('one location or a list of locations'). It is distinct enough from siblings like get_current_time, though it does not explicitly name an alternative.
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 given about when to use this tool versus get_current_time, get_dst_schedule, convert_time, or search_timezones. The phrase 'snapshot payload' implies raw data retrieval, but there are no explicit usage conditions, prerequisites, or exclusions.
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 only says 'search' and does not disclose whether the operation is read-only, how countryCode affects ranking/disambiguation, return format, or behavior like limit enforcement. These gaps are significant for a tool with no annotation safety profile.
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 with no filler. Every phrase adds meaning, and it is appropriately sized for a straightforward search tool.
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 search tool with full schema coverage, the core purpose is communicated. However, with no annotations and no output schema, the description leaves unspecified return shape, result limits, and ordering — gaps that keep it from being fully complete for an agent.
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 query, limit, countryCode, and _endUserId. The description adds only that searches can be by 'city, country, or timezone-related query,' which aligns with query but adds no syntax or behavior detail beyond the schema; baseline 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 uses a specific verb ('Search') and identifies the resource ('production location records') with clear query dimensions (city, country, timezone). It distinguishes itself from sibling tools like get_current_time or convert_time, though it does not explicitly name alternatives, so it falls just short of a 5.
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: use this tool when you need to find location records via a text query. However, it does not explicitly state when not to use it or name alternatives such as get_location_by_id for exact ID lookups, making the guidance only implicitly clear.
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 bears full responsibility. It reveals that the tool returns documentation/help content, not operational data, which is useful. However, it doesn't state whether it performs network calls, caches, or has any side effects, but for a help tool this is acceptable. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that lists the key content areas, which is concise and front-loaded. It's not overly verbose, but could be slightly more structured (e.g., bullets), but as a paragraph it's acceptable.
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 one optional parameter and no output schema, so the description suffices to convey its purpose and content. It could be improved by adding a note about the output format (e.g., plain text vs JSON), but given low complexity, it is adequately complete.
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 does not mention the single parameter '_endUserId'. However, schema coverage is 100%: the schema already explains that it's an optional end-user attribution token and warns against sending PII. Thus, the description adds no extra value here, and 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 returns usage help for findtime.io MCP, listing several specific content types (time-intelligence intents, answer API examples, ambiguity handling, deployment guidance). This is distinct from sibling tools that perform time operations like answering questions or finding meeting times, though it doesn't explicitly name them.
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 this tool is for learning how to use the MCP, but it doesn't explicitly state when to use it versus alternatives. Given siblings like answer_time_question and find_meeting_time, a user might need this help before using those, but the description doesn't say that directly.
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 must carry the full burden of behavioral disclosure. It only says 'production meeting search endpoint', which implies a live query but does not explicitly state read-only behavior, side effects, authentication requirements, or other operational traits. It also does not disclose potential failure modes or rate limits.
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, immediately stating the purpose and then giving a critical routing rule. It is front-loaded with the main action 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain the return format. It only says 'ranked meeting suggestions', which is vague and does not specify the structure, ranking criteria, or pagination. There is no mention of error handling or edge cases, and with no annotations the agent gets little guidance for production 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?
Schema description coverage is 50%, so the description should compensate for the remaining parameters. It adds minimal value: it only hints that 'date' should be absolute by routing relative dates elsewhere, but does not explain semantics for locations, countryCodes, or _endUserId beyond what the schema already states. The description does not clarify constraints, formats, or relationships between parameters.
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 it returns ranked meeting suggestions from a specific endpoint, using a specific verb ('return') and resource ('production meeting search endpoint'). It also distinguishes itself from the sibling tool answer_time_question by explicitly mentioning the routing condition for relative-date inputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: for relative-date inputs ('this week', 'next Friday', 'tomorrow'), it instructs routing to answer_time_question. This is a clear when-not-to-use condition, and the mention of 'production search endpoint' implicitly defines its intended use for absolute dates. The alternative tool is named.
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 behavioral burden. 'Hydrate' implies a read-only, idempotent fetch of a full record, and 'production' signals real vs. test data — useful context. But failure modes for unknown/missing IDs, response shape, and absence of side effects are left unstated.
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?
A single 11-word sentence front-loads the verb and packs in matching precision ('exact'), data environment ('production'), and keying mechanism ('stable findtime id'). Every word earns its place with zero waste.
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 single-required-param lookup with 100% schema coverage, the description is nearly sufficient. The notable gap is that with no output schema, it does not state what a 'location record' contains (e.g., offset, DST info, aliases) or error behavior for unknown IDs — moderate gaps for an agent deciding whether this tool answers a time question.
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%: the id parameter includes a concrete format example ('findtime:victoria|CA|America/Vancouver') and _endUserId has a thorough privacy- and provenance-oriented description. The tool description adds only 'stable findtime id,' which reinforces but does not exceed the schema, so the 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 ('Hydrate'), resource ('exact production location record'), and method ('by stable findtime id'), clearly stating an exact-ID lookup rather than a search. This distinguishes it from the closest sibling, search_timezones, which finds locations without a stable ID.
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 'by stable findtime id' phrase implies the caller must already possess a findtime ID, so context is inferable. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named (e.g., 'use search_timezones to find an ID first').
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 of explaining behavior. It discloses what the tool returns and something about its content, but it does not mention default behavior when no optional parameters are provided, handling of ambiguous locations, or error/fallback 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 two sentences, front-loaded with the core purpose, and the second sentence provides an actionable routing rule. Every sentence earns its place without fluff.
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 tool with 7 optional parameters and no output schema, the description gives a broad purpose but does not explain how arguments (year, at, timezone/city/query, countryCode) interact or what happens for missing inputs. It is minimally sufficient but leaves important edge cases uncovered.
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 input schema already documents every parameter. The description adds no parameter-specific meaning, but because coverage is complete and the baseline is 3, this is acceptable.
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 ('Return') and a clear resource ('production DST schedule payload'), and specifies key contents ('current abbreviation and transition details'). It also distinguishes itself from the sibling answer_time_question by explicitly routing relative-date queries there.
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?
It clearly states that relative-date inputs should go to answer_time_question instead of this tool, which is a useful when-not-to-use condition. It does not elaborate on other alternatives like time_snapshot or search_timezones, but it gives enough context for the primary routing decision.
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 discloses the tool returns diagnostic info and includes a live health check, implying network activity arenas but does not mention potential side effects, failure modes, or permission requirements. Adds reasonable context but not exhaustive.
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, well-structured sentence that front-loads the purpose ('Return MCP and findtime Time API diagnostics') and efficiently lists the returned components. Every word earns its place.
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 tool has low complexity (1 optional param, no output schema), and the description covers the main functionality. It could mention that the health check may incur network latency or that the auth configuration might be sensitive, but it's adequate for 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?
Schema description coverage is 100%, so the schema fully explains the single optional parameter. The tool description does not mention the parameter, but the baseline of 3 applies since schema handles parameter semantics adequately.
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 returns diagnostics for the MCP and findtime API, listing specific items like version, URL, auth config, and health check. It is easily distinguished from sibling tools, which all focus on time-related operations.
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 tool's purpose is unique among siblings, so usage context is clear from the description (diagnostics). However, it does not explicitly state when to use it versus alternatives or any exclusions, though none seem necessary.
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 full burden. It discloses that the tool uses a 'production overlap endpoint' (implying a network call) and that relative dates are not handled directly (delegated to answer_time_question). However, it does not explicitly state read-only nature, error behavior, or any side effects, leaving some 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 only two sentences. The first sentence front-loads the primary purpose, and the second provides essential routing guidance. Every word earns its place, with no filler or redundant 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?
There is no output schema, so the description should explain what the tool returns, but it does not mention the output format, error cases, or how countryCodes/date affect the result. The routing rule adds some context, but the lack of return-value specification is a significant gap for a tool that computes overlap hours.
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 50%, and all parameters have descriptions in the schema (date, locations, _endUserId, countryCodes). The description adds no extra meaning to the parameters themselves, only the date-related routing rule. Since coverage is moderate, a baseline 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 clearly states the tool's function: 'Return shared business-hours overlap across multiple locations' with a specific verb and resource. It also distinguishes from the sibling tool answer_time_question by explicitly noting that relative-date inputs should be routed elsewhere, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-not-to-use guidance: 'For relative-date inputs... route to answer_time_question.' This names the alternative tool and the condition for using it, which is exactly the kind of guidance needed for correct tool selection.
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, the description carries the burden of behavioral disclosure. It communicates that the tool classifies intent and dispatches internally, warns that other tools silently drop natural-language qualifiers without an explicit ISO date, and notes suitability for vague/mixed intent. It does not mention auth, rate limits, or return format, but the core behavior is clearly surfaced.
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?
Three focused sentences, with the most important information front-loaded. The contrast with alternatives and the natural-language examples earn their place with no redundant content.
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 generic intent-router with no output schema, the description covers the core selection behavior, when to use it, why it is preferred, and how to distinguish it from sibling tools. It does not state the return shape, but the name and entry-point nature make the intended answer clear. Overall, it is adequately complete for safe and accurate selection.
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 baseline is 3. The description adds useful context around what the 'query' parameter should contain (natural-language time questions), but does not elaborate on parameters like 'now', 'date', or 'locale' beyond what the schema already provides.
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 purpose: it is the 'PREFERRED entry point for time/timezone/scheduling questions' and explains that it classifies intent and dispatches internally. This clearly distinguishes it from the sibling tools that operate on already-structured time data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance: use it WHENEVER there is a natural-language day/date qualifier, and provides concrete examples like 'Tuesday' and 'next Friday'. It also warns against alternatives that 'silently drop' these qualifiers and recommends it for 'vague or mixed-intent prompts'.
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?
Since no annotations are provided, the description carries the full burden. It explains the retry behavior for country-name queries, which is useful. However, it does not disclose other behavioral aspects such as error handling, rate limits, or the structure of the payload, but given the tool's simplicity, the description provides sufficient transparency.
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 three sentences, each earning its place. The first sentence states the core purpose, the second provides a nuanced behavior, and the third gives an explicit routing rule. No filler or 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 tool has 5 parameters, 0 required, no output schema, and no annotations. The description covers the core use cases and provides a crucial exclusion for relative dates, but does not fully compensate for lack of output structure or edge-case handling. However, the description is adequate for the tool's simplicity and the schema's completeness.
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 parameters are already well-documented. The description adds minimal param-specific meaning (e.g., mentions city, query, timezone in the purpose). It does not elaborate on mutual exclusivity or priorities among the fields, but the schema's coverage is high, so a baseline 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 clearly states the tool returns the current time payload for a city, query, or timezone, and distinguishes it from the sibling tool answer_time_question by specifying that relative-date inputs should not be handled here. The verb 'Return' plus the resource 'production current time payload' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to route relative-date inputs to answer_time_question, providing a clear when-not-to-use directive and naming the alternative. It also mentions that exact country-name queries may be retried through a canonical city, giving concrete usage context.
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, the description carries the transparency burden. It discloses a critical behavioral quirk—relative date qualifiers are 'silently dropped'—and instructs downstream synthesis to copy localTime fields and offsets exactly, revealing part of the output contract. It does not discuss failure modes or error behavior, but the key behavioral risk for this conversion tool is clearly addressed.
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 front-loaded with the core action, then gives crisp usage constraints, a named alternative, and output-handling rules. Every sentence earns its place with no redundancy; the length is justified by the routing and synthesis instructions.
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 7-parameter tool with no output schema or annotations, the description covers purpose, valid usage conditions, a sibling alternative, and the key output fields to preserve. It could additionally describe error behavior or the country-hint parameters, but the essential decision-making context is present.
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 71%, and the description adds meaningful value by constraining date to explicit ISO calendar dates and clarifying that current-moment conversions require no date qualifier. It also reinforces the meaning of from/time/to beyond what the raw property names 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 a specific verb and object: 'Convert a source local time into one or more target locations.' It clearly distinguishes itself from siblings by explicitly routing relative-date questions to answer_time_question, making the tool's scope concrete and non-overlapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit use conditions: use only with explicit ISO calendar dates or current-moment conversions, and explicitly says 'DO NOT use' for relative phrases like 'tomorrow' or 'next Friday.' It names answer_time_question as the alternative, fully satisfying when-to-use and when-not-to-use 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:

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

Score Badge

Copy to your README.md:

[![findtime-mcp-server MCP server](https://glama.ai/mcp/servers/hkchao/findtime-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/hkchao/findtime-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/hkchao/findtime-mcp-server'

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