mcp-hko

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation5/5
Each tool has a clearly distinct purpose, covering different weather data types (temperature records, forecasts, tides, earthquakes, etc.). Descriptions are detailed enough to avoid confusion, even where tools seem related (e.g., flw vs fnd, warningInfo vs warnsum).
Naming Consistency2/5
Tool names are inconsistent: some are cryptic abbreviations (e.g., flw, fnd, lhl, mrs, qem), others are longer descriptive names (e.g., hourlyrainfall, lunardate, warningInfo), and casing is mixed (all lowercase vs camelCase). No predictable pattern like verb_noun.
Tool Count4/5
With 20 tools, the server covers a wide range of weather and astronomical data. While slightly on the high side, each tool serves a specific purpose for a national meteorological service. Could potentially consolidate a few, but the count is reasonable.
Completeness4/5
The server provides comprehensive coverage of current weather, forecasts, warnings, and historical temperature data. However, it lacks tools for historical rainfall, pressure, or wind data, which would be expected for full completeness. Still, the core functions are well-covered.
Average 3.4/5 across 20 of 20 tools scored. Lowest: 2.2/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 is passing
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It fails to mention that the tool is read-only, any rate limits, or the valid year range (contradicts schema default). The description includes a non-schema parameter 'dataType' and an example with year 2025, but the schema restricts years to 2018-2024, causing confusion and lack of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose, repeating parameter explanations already present in the schema. It includes a redundant parameter list and a URL example that could be shortened. The essential purpose is not front-loaded; the first line just restates the tool name. Much content is not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain the return values, but it does not. It also fails to clarify the 'dataType' parameter present in the example but absent from the input schema. The tool has 4 parameters, no output schema, and no annotations; the description is insufficient for an agent to understand the complete behavior.
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 no new meaning beyond the schema; it repeats parameter details and provides an example. While the example may clarify formatting, it does not enhance semantic understanding of parameters. No additional constraints or interpretations are provided.
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 'Times of Moonrise/Moonset' and provides an API request example, indicating it retrieves moonrise/moonset times. However, it lacks a specific action verb like 'get' or 'retrieve', and the title is missing. It distinguishes from sibling tools like 'srs' (sunrise/sunset) implicitly by focusing on moon data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 such as 'srs' for sunrise/sunset. It does not mention any prerequisites, recommended use cases, or conditions under which this tool should be avoided. The sibling context is completely ignored.
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 should disclose behavioral traits. It does not mention rate limits, authentication, error handling, or side effects. The response keys are listed but that is output structure, not behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but includes unnecessary formatting (indentation, line breaks). It is not front-loaded; the first line merely restates the name.
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 one parameter and no output schema, the description covers the basics (parameters, example, response fields). However, it lacks usage guidance and behavioral context, making it minimally 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?
Schema coverage is 100% with a description and default for 'lang'. The description adds example values and response keys, which provides minor additional context beyond the schema.
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 indicates the tool is for accessing Special Weather Tips data, listing parameters and response keys. However, it lacks an explicit verb like 'retrieves' and reads more like documentation than a concise action statement.
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 its many siblings (e.g., warningInfo, hourlyrainfall). No context on 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 full burden. It implies a read-only GET request via the example URL but does not disclose rate limits, authentication, idempotency, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a comprehensive list of response keys, which is helpful given the lack of an output schema, but it makes the description longer than necessary. It could be more concise by moving response details elsewhere.
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 a single optional parameter and no output schema, the description adequately covers input and output format. However, it lacks details on error handling, rate limits, or how to handle the response, and does not help with tool selection among siblings.
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 description adds value by listing allowed values for the 'lang' parameter (en, tc, sc) and providing a request example, which goes beyond the schema's brief description. Schema coverage is 100%, so baseline is 3; the extra detail justifies a 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 '9-day Weather Forecast (fnd) API Request', specifying the verb (fetch) and resource (9-day forecast). However, it does not differentiate from sibling weather tools like 'clmmaxt' or 'flw', which may also provide forecasts.
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 a request example and parameter info but lacks explicit guidance on when to use this tool versus alternatives. No when-not-to-use or context relative to sibling tools is given.
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 available, the description must fully disclose behavioral traits. It lists parameters and response keys but omits key behaviors: it does not state that the tool is read-only, makes an HTTP GET request, or has any side effects. The response keys hint at the output, but the behavioral profile is incomplete, especially for a tool that performs an external API call.
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 well-structured with clear sections: a header, parameter list, example request, and response keys. It is somewhat verbose but mostly front-loaded with the essential purpose. Every sentence adds value, though the example and response keys could be integrated more concisely.
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 optional parameter, no output schema), the description provides adequate context: parameter values, an example URL, and response fields. It is complete enough for an agent to invoke the tool, though it could explicitly state the data source (Hong Kong Observatory) and that the operation is read-only.
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 input schema covers 100% of parameters with a description for 'lang', but the schema description ('change the language of the result') is vague. The tool description adds concrete meaning by specifying allowed values ('en', 'tc', 'sc') and provides a request example, significantly enhancing parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as 'Quick Earthquake Messages (qem) API Request' but does not explicitly state a verb or action (e.g., 'fetch' or 'get'). It relies on the name and context to imply the purpose, making it somewhat clear but not precise. The presence of sibling tools like 'feltearthquake' suggests a potential distinction, but the description does not clarify how 'qem' differs from similar earthquake-related tools.
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, such as 'feltearthquake' or other data sources. The description lacks any contextual cues about preferred scenarios or prerequisites, leaving the agent without decision-making support for tool selection.
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, and the description does not disclose behavioral traits like whether the tool is read-only, requires authentication, or has rate limits. It only lists response keys, which gives some insight but not 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise but includes a verbose request example and response key list. It is structured with headings, but the information could be condensed without losing clarity.
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 simplicity of the tool (one optional parameter, no output schema), the description covers the basics: parameter details, example, and response structure. However, it lacks behavioral context and does not address potential edge cases or limitations.
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 has 100% coverage with a single parameter 'lang'. The description adds specific allowed values ('en', 'tc', 'sc') and a request example, which provides more meaning than the schema's generic description and default value.
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 it returns weather warning information, with a request example and response keys. However, it does not differentiate from the sibling tool 'warnsum', which likely has overlapping functionality.
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 a request example but offers no guidance on when to use this tool versus alternatives, such as 'warnsum'. It also fails to specify any prerequisites or context for use.
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 exist, so description bears full burden. It details request and response structure but does not disclose data limits, rate limits, or error handling. While it mentions optional parameters and defaults, behavioral traits like being read-only are implicit but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy due to including response key details and an example. While the example is helpful, the response format section adds bulk. It is front-loaded with purpose but could be more concise without losing essential information.
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 no output schema, describing response keys is useful for an agent to understand return values. However, it lacks information on data availability, station list references, or error responses. The description is complete for basic usage but not for edge cases or integration 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?
Schema coverage is 100%, so baseline is 3. Description adds a request example and indicates month is optional, but largely repeats schema information. It provides minimal additional meaning beyond what the schema already captures.
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 'Daily Mean Temperature (CLMTEMP) API Request' and describes the parameters, establishing that it retrieves mean temperature data. However, it does not explicitly differentiate from sibling tools like clmmaxt and clmmin, which could cause confusion.
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. There is no mention of, for example, 'Use this for mean temperature; for max use clmmaxt.' The description only lists parameters and response format, lacking context for selection.
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 should reveal all behavioral traits. It lists parameters and response keys but omits whether the operation is read-only, any authentication needs, rate limits, or data update frequency. The agent lacks critical safety and performance context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably structured with sections for parameters, request example, and response keys. However, listing all response keys is verbose; some could be omitted if the response is standardized. The information is useful but could be slightly more concise.
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 lack of an output schema, the description compensates by enumerating all response keys, which is helpful. For a simple tool with one parameter and a straightforward API, the description covers the essentials. Minor gaps exist (e.g., no error handling hints) but overall it is complete.
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 covers 100% of parameters, but the description adds value by listing the specific language values ('en', 'tc', 'sc') and providing a default and example. This enriches the schema's minimal description 'change the language of the result'.
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 'Locally Felt Earth Tremor Report' and provides a request example. The purpose is evident: to retrieve earthquake data. However, it does not explicitly differentiate from sibling tools like 'flw' or 'fnd', which are unknown but likely different domains.
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?
There is no guidance on when to use this tool instead of others. The description provides parameter details and an example but does not mention scenarios, prerequisites, or alternatives. An agent would not know if this is appropriate for historical data or real-time queries.
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 bears the full burden. It explains the API endpoint, response structure (keys), and data format. However, it does not disclose potential behavioral traits such as rate limits, error handling, or data coverage. The description 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with sections but is somewhat lengthy. The example and response keys add context but could be condensed. It is not overly verbose, but some lines (e.g., the repeated parameter explanations) could be streamlined without losing clarity.
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 no output schema, the description includes response keys and an example, which aids understanding. However, it lacks details on error conditions, date range validation, or station code availability. The tool is simple, but the description could be more complete for an agent to handle edge cases.
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?
Input schema covers 100% of parameters with descriptions. The description adds value by providing a request example and explaining response keys for both JSON and CSV formats. This goes beyond the schema, giving the agent contextual understanding of how parameters are used in practice.
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 it is for 'Daily Minimum Temperature (CLMMINT) API Request', which specifies the resource (daily minimum temperature). The name matches the function. However, it does not explicitly differentiate from siblings like 'clmmaxt' (likely max temperature), leaving some ambiguity for the AI agent.
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 parameter details and an example but offers no guidance on when to use this tool versus alternatives (e.g., clmmaxt for maximum temperature). It lacks explicit context for appropriate usage or exclusions, which is important given multiple temperature-related sibling tools.
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 present, so the description carries the burden. It provides the response keys and a request example, giving insight into output format, but does not disclose authentication, rate limits, or side effects. For a read-only API, this is adequate but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with sections but includes a full URL example and a list of response keys, making it slightly verbose. It could be more concise by focusing on the tool's purpose rather than API details.
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 the description covers input and output adequately. However, it lacks explanation of how this tool relates to siblings or any preconditions, leaving the agent without full context for selection.
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 input schema describes the 'lang' parameter minimally, but the description lists the allowed values ('en', 'tc', 'sc'), which are not in the schema's enum. This adds critical semantic information beyond what the 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 begins with 'Local Weather Forecast' and the tool name 'flw' suggests forecast. It clearly indicates the tool returns a local weather forecast, but lacks an explicit verb like 'get' and does not differentiate from sibling weather tools.
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 the 19 sibling weather tools. The description is purely technical without any usage 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?
The description lists response keys, giving insight into what data is returned, which partially compensates for missing annotations. However, it does not explicitly state that the tool is read-only or mention any rate limits or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes a redundant parameter list and a lengthy example URL. It could be more concise, though it is structured with clear sections.
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 simplicity (one optional parameter, no output schema), the description adequately covers the response format and usage example. However, it lacks error handling or rate limit information.
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 covers the single parameter 'lang' with a description. The tool description adds concrete values (en, tc, sc) and a request example, providing richer usage context beyond the schema.
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 this is a current weather report API and lists response keys, indicating it returns comprehensive weather data. However, it does not differentiate from sibling tools that also provide weather data like temperature or wind.
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 vs alternatives. The description provides an example URL but does not specify scenarios where this tool is appropriate or when to choose a sibling tool.
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 provided, so the description carries the full burden. It discloses the return format and parameter behavior, but does not explicitly state whether the tool is read-only or has any side effects (likely safe read operation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately structured with sections, but includes a full request URL and list of response keys, which is somewhat verbose for an agent. Could be more concise while retaining key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one optional parameter, no output schema, and no annotations, the description covers the essential aspects: purpose, parameter details, request format, and response structure. It is sufficiently complete for a simple read-only API.
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?
Input schema has one parameter with description 'change the language of the result.' The description adds value by listing exact language codes (en, tc, sc) and providing a request example, going beyond the schema's description.
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 it is a 'Weather Warning Summary' API request, indicating it retrieves weather warnings. It specifies parameters and response structure, but does not explicitly differentiate from sibling tools like warningInfo.
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 explicit guidance on when to use this tool versus alternatives. The description provides a request example but lacks context for optimal use cases or when not to use 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?
No annotations are provided, so the description must disclose behavioral traits. It implies a read-only retrieval (API request with no side effects) and includes request/response details. However, it does not explicitly state safety, permissions, or rate limits, which would be helpful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections and includes necessary information without excessive verbosity. However, it repeats parameter defaults that are already in the schema, so minor redundancy exists.
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 has only two parameters and no output schema, the description provides sufficient context: input options, example request, and response format. It lacks error handling or rate limit info but is adequate for basic 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 input schema already covers both parameters with descriptions and defaults (100% coverage). The description adds value by providing a concrete request example and detailed response keys, which help the agent understand how to construct requests and interpret responses.
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 that the tool retrieves lightning count data (Cloud-to-Ground and Cloud-to-Cloud). The verb 'API Request' indicates a retrieval operation. While it does not explicitly distinguish from sibling weather tools, the context makes it clear this is for lightning data.
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 conditions, prerequisites, or exclusions. The agent is left to infer usage based on the tool name and description alone.
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 reveals it is a read-only API call returning tide data. It explains the request format and response keys but omits details on rate limits, authentication, or error handling.
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 structured with a header, parameter list, example, and response keys. It is informative but slightly wordy; could be more concise by removing redundant parameter details already in schema.
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?
No output schema exists, so the description compensates by detailing JSON and CSV response keys. It covers all input parameters and provides an example, but lacks error scenarios or typical usage patterns.
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%, but the description adds value by listing valid station codes, year range, and optional parameters with examples. The request example and response field explanations go 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 the tool retrieves 'Times and Heights of Astronomical High and Low Tides', using a direct verb and resource. It lists parameters, an example, and response keys, distinguishing it from sibling tools which cover other weather data like temperature, rainfall, and warnings.
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 like 'flw', 'lhl', or other siblings. The description does not mention use cases, prerequisites, or context for choosing this tool over others.
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 full burden. It details the response formats (JSON/CSV), fields, and provides an example URL. However, it does not mention rate limits or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose, including an example and full response keys for both formats. It could be more concise by omitting redundant parameter details and focusing on key behavioral information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers the response structure. It explains both JSON and CSV formats. However, it lacks context on limitations (e.g., historical data only) and error conditions.
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%, so the description adds minimal new meaning. It repeats parameter ranges and defaults that are already in the schema. No additional semantics 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 'Times of Sunrise/Sunset (SRS) API Request', specifying the verb (request) and resource (sunrise/sunset times). It distinguishes from sibling tools by focusing on this specific phenomenon.
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 does not explicitly state when to use this tool versus alternatives. Usage is implied through the purpose, but no when-not-to-use or alternative guidance is provided.
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 full burden. It thoroughly explains the request format, parameters, and response structure for both JSON and CSV. It is clear this is a read-only data retrieval operation, and no destructive or complex behavior is implied.
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 well-structured with clear sections for parameters, request example, and response keys. It is not overly verbose for the amount of information conveyed, but could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional parameters, no output schema), the description covers all necessary aspects: purpose, parameters with examples, and comprehensive response keys for both formats. No output schema exists, but the description compensates by detailing return values.
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 fully describes both parameters (lang, rformat) with their defaults and options. The description restates this information and adds a request example, but adds no deeper semantic meaning or constraints beyond what the schema 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 explicitly states 'Latest 10-minute Mean Visibility (LTMV) API Request' and details what the tool returns: visibility data from automatic weather stations. It clearly distinguishes from sibling tools which cover other weather parameters like rainfall, temperature, and warnings.
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 the many sibling tools. It does not mention any context, prerequisites, or alternative tools for similar data. The agent is left to infer usage alone.
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 present. Description covers input format and response keys but lacks details on rate limits, error handling, or supported date range. Adequate for basic understanding 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: purpose, parameter, example, response keys. Every line adds value. Could be slightly more organized but very efficient.
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?
No output schema, but description lists response keys. However, lacks context on date range validity, timezone, or API restrictions. Reasonably complete for a simple conversion tool.
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%, but description adds value with usage example and response key explanation. Exceeds baseline by providing concrete illustration of how the parameter is used.
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?
Description clearly states the tool performs Gregorian-Lunar calendar conversion. Provides example and response keys, making purpose unmistakable. Distinct from all sibling weather tools.
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?
No explicit guidance on when to use or alternatives. However, siblings are all weather-related, so implicit differentiation. Could be improved with a note on date range or timezone relevance.
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?
No annotations are provided, so the description carries full burden. It explains the output format for both JSON and CSV, including the structure of keys and data arrays, which is transparent for a read operation.
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 well-structured with sections for parameters, example, and response keys. Every part serves a purpose without redundancy, and it is appropriately concise for the complexity.
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 lack of output schema, the description provides comprehensive response format details. It could mention error handling or rate limits, but for a simple data retrieval tool, it is largely complete.
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%, but the description adds value with an example URL, explanation that month is optional, and a reference to a station code list, going 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 it is the 'Daily Maximum Temperature (CLMMAXT) API Request' and includes an example URL and response keys, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains parameters and provides an example, but does not explicitly guide when to use this tool versus sibling tools like clmtemp or other weather APIs.
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 full burden. It discloses the request format, optional parameters, and response structure, but does not explicitly state that the operation is read-only, safe, or any rate limits. The behavioral traits are incomplete for a data retrieval tool.
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 well-organized with sections for parameters, example, and response. It is front-loaded with purpose and uses bullet points effectively. The inclusion of both JSON and CSV response keys is slightly redundant since only JSON is supported, but overall not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is remarkably complete. It explains all 6 parameters, provides valid values, a concrete request example, and details the response structure. It covers the tool's purpose, usage, and output comprehensively.
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 has 100% coverage with basic parameter descriptions, but the description adds significant value by listing all valid station codes, year range, and providing a request example. It also clarifies that rformat defaults to 'json' and that month/day/hour are optional, enriching the schema details.
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 retrieves Hourly Heights of Astronomical Tides (HHOT) for a given station and year, with optional month/day/hour filtering. It specifies the resource (tide data) and action (API request), and is distinct from sibling tools like climate or earthquake data.
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 context on when to use the tool (to get tide heights) and how to specify parameters. However, it does not explicitly mention when not to use it or compare it to sibling tools, which could help avoid confusion with similar data tools.
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?
No annotations are provided, so the description bears the full load. It is transparent about being an API request and details the response structure (type, SolarData, AmbientTemp). However, it does not mention any behavioral aspects like rate limits or authentication requirements, but the read-only nature is implied.
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 well-structured with clear sections (Parameters, Request Example, Response Keys) and is front-loaded with the title. It is not overly verbose, though the example URL could be considered redundant with schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description compensates by listing response keys. All parameters are covered, and the tool's function as a data retrieval for a specific station and date is fully explained. It is complete for a read-only API tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameters. The description adds value by providing a request example, clarifying the 'lang' default, specifying date format, and directing to documentation for station codes.
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's a 'Weather and Radiation Level Report (RYES) API Request', specifying the verb (retrieval) and resource. It distinguishes from siblings like 'hhhot' or 'hourlyrainfall' by mentioning solar radiation data and specific response keys (SolarData, AmbientTemp).
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 provides a request example and parameter details but does not explicitly state when to use this tool versus alternatives like 'rhrread' or 'srs'. The example implies usage for solar radiation, but no when-not or exclusions are mentioned.
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?
No annotations provided, so description carries full burden. It discloses the read-only nature via API request, shows response keys and example, and explains the sole parameter. No destructive actions mentioned, which is appropriate for a read operation.
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?
Description is well-structured with sections for description, parameters, request example, response keys, and response example. It is front-loaded with purpose. Some redundancy (e.g., repeating parameter info) but overall efficient.
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 only 1 optional parameter and no annotations or output schema, the description is nearly complete. It documents the response format and includes a full example. Missing error handling or rate limits, but not critical for a simple API tool.
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. Description adds value by showing the parameter in the URL example and clarifying default and options ('en, tc, sc'), going beyond the schema's enum-less 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?
Description clearly states 'Rainfall in the Past Hour from Automatic Weather Station API Request', providing a specific verb (rainfall) and resource (automatic weather station). It distinguishes itself from siblings which appear to be other weather data types.
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?
While no explicit when-to-use/alternatives are given, the description provides a clear request example and response structure, implying usage for hourly rainfall data. Sibling names are distinct, so context is clear.
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-hko MCP server](https://glama.ai/mcp/servers/louiscklaw/mcp-hko/badges/card.svg)](https://glama.ai/mcp/servers/louiscklaw/mcp-hko)

Score Badge

Copy to your README.md:

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

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/louiscklaw/mcp-hko'

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