HK Climate and Weather MCP Server

Server Quality Checklist

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

Latest release: v0.4.1
Disambiguation4/5
Most tools have clearly distinct purposes, such as current weather vs. forecasts vs. warnings. There is some potential confusion between get_current_weather and get_local_weather_forecast, but their descriptions distinguish immediate conditions from short-range outlooks.
Naming Consistency5/5
All tools follow the consistent 'get_' prefix combined with a descriptive object name, creating a predictable verb_noun pattern. No mixing of styles or vague verbs.
Tool Count4/5
With 19 tools, the server is slightly above the typical well-scoped range, but the breadth of climate, weather, tide, and astronomical data justifies the count. Each tool serves a specific data need without excessive redundancy.
Completeness4/5
The toolset covers a wide range of weather, climate, and astronomy data, including forecasts, warnings, radiation, tides, and visibility. A notable gap is the lack of a general station code list for temperature data, as only radiation and tide stations provide code lookup tools.
Average 3.1/5 across 19 of 19 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Get ... data', implying a read operation, but does not describe the output format, handling of optional month/day, language support, or edge cases. This is minimal behavioral insight.
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 a short single sentence, but it adds little beyond the tool name and is under-specified rather than appropriately concise. It does not earn its place by providing additional useful 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?
Although an output schema exists, the description is too thin to guide an agent on valid input ranges, the purpose of optional parameters, or expected behavior. With zero annotations and no parameter semantics, the overall context is incomplete for a tool with four parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the four parameters (year, month, day, lang). It provides no meaning beyond the schema's types and defaults, so the description completely fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly identifies the resource as 'Gregorian-Lunar calendar conversion data', which is distinct from the weather, tide, and astronomy sibling tools. It immediately conveys what the tool does.
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 versus alternatives, no mention of typical use cases, and no exclusions. The only implied usage is that it retrieves conversion data, but the description does not explicitly state when or why this tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only mentions that the forecast includes 'description, outlook, update', but does not disclose output structure, limitations, or any behavioral characteristics. This is minimal disclosure for a tool with no safety annotations.
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 concise sentence, front-loaded with the primary action. However, the trailing phrase 'with description, outlook, update' is vague and could be structured more clearly, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large set of sibling tools and the one undocumented parameter, this description is incomplete. It does not explain the output (though an output schema exists) or provide enough context for appropriate tool selection. The description lacks necessary guidance for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not mention the 'lang' parameter at all. Since there is one parameter with a default value, the description should explain its purpose (e.g., language of the forecast), but it adds no meaning 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 the action ('Get local weather forecast') and location ('HK'), providing a specific verb and resource. However, it does not differentiate from siblings like get_current_weather or get_9_day_weather_forecast, and 'local' is ambiguous without context.
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. With many sibling weather tools, the description gives no context, exclusions, or selection criteria, making it hard for an agent to choose correctly.
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?
There are no annotations, so the description bears full responsibility for disclosing behavior. It mentions 'statement and update' but does not explain what these are (e.g., warning statement text, update timestamp). No aggregate behavior like rate limits, pagination, or data freshness is disclosed.
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, concise sentence that front-loads the core action and resource. It is efficient but somewhat cryptic due to the phrase 'with statement and update'. It does not waste words, though it could be clearer without being longer.
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?
While the tool is simple (one optional parameter) and has an output schema, the description lacks necessary context for an agent to decide between this and the summary counterpart. The ambiguous 'statement and update' and absence of any usage guidance make the description incomplete for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'lang' is documented in the input schema with a default of 'en', but the description provides zero explanation of it. With 0% schema description coverage, the description should compensate for parameter meaning, but it does not even mention the parameter explicitly.
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 identifies a specific verb ('Get'), resource ('weather warning info'), and geographic scope ('HK'). It adds 'detailed' and 'with statement and update' to convey more than just a basic lookup. However, it does not explicitly distinguish itself from the sibling tool 'get_weather_warning_summary', though 'detailed' implies a contrast.
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 about when to use this tool versus alternatives. The description doesn't mention selecting between this and 'get_weather_warning_summary' or any other sibling tools, and there are no contextual cues about the appropriate scenario for requesting detailed warnings.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does not mention whether the operation is read-only, any side effects, rate limits, or what 'update' refers to. The minimal text adds little beyond the tool name.
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 compact, with a single front-loaded sentence that states the core action and scope. However, the phrase 'with messages and update' is slightly ambiguous and could be clearer, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema present), the description covers the basic purpose but omits practical context such as the difference from 'get_weather_warning_info', what 'update' means, or any usage constraints. The presence of an output schema mitigates the need for return-value detail, but overall the description leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional 'lang' parameter with a default, but the description does not mention or explain it. With 0% schema description coverage, the description fails to compensate, leaving the agent to guess the meaning and accepted values of 'lang'.
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 identifies the tool as fetching a weather warning summary for Hong Kong, specifying that it includes messages and an update. While it implies a distinction from sibling tools like 'get_weather_warning_info' via the word 'summary', it does not explicitly highlight that difference.
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. Given numerous sibling weather tools, the absence of any contextual direction (e.g., 'use for a high-level summary, not detailed info') leaves the agent to infer the use case.
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?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It only says 'including tips list and update,' which is vague and does not clarify what the tool returns, whether it is read-only, or any side effects. No additional behavioral context is provided.
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, concise sentence that front-loads the main purpose. It contains no filler. However, the phrase 'including tips list and update' is awkward and slightly ambiguous, though it doesn't detract much from conciseness.
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 an output schema, so return values are likely covered. However, the description lacks usage context, fails to explain the output ('tips list and update'), and provides no behavioral details. It is minimally adequate but with clear gaps for an agent deciding when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'lang' with a default, but the description provides zero explanation of it. With 0% schema description coverage, the description should compensate, but it doesn't. The parameter name is self-explanatory ('lang' likely means language), but the description adds no value 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 the tool fetches special weather tips for Hong Kong, using a specific verb ('get') and resource ('special weather tips'). It is distinct from sibling tools that handle forecasts, warnings, and tides. However, it doesn't explicitly differentiate from other tools or clarify what 'tips list and update' means, so it misses the top score.
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 in the sibling list. The description does not mention any scenarios, exclusions, or distinctions from similar weather data tools, leaving the agent without context 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?
With no annotations, the description carries the full burden of behavioral disclosure. It merely restates the purpose without explaining how optional parameters (year, month) affect results, what station identifiers are valid, or any historical data range constraints. The description adds no behavioral context beyond the basic 'get data' intent.
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 clear sentence, front-loaded with the action and resource. It is concise and easy to parse, though it could include more useful context without becoming bloated.
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?
Despite having an output schema, the description omits critical context such as optional parameter semantics (year/month default to null), the relationship to sibling temperature tools, and any special behavior. For a simple data retrieval tool with four parameters, the description is too sparse for an agent to invoke it effectively in varying scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only mentions 'specific station,' aligning with the required 'station' parameter. It does not clarify the meaning or default behavior of 'year', 'month', or 'lang', leaving the agent with incomplete information for constructing calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies the exact resource ('daily maximum temperature data') with a clear geographic scope ('for a specific station in Hong Kong'). This distinguishes it from sibling tools like get_daily_mean_temperature and get_daily_min_temperature, which share the same station/city context but target different metrics.
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 sibling temperature tools (mean/min) or other weather data tools. It implies usage via the metric name but does not state prerequisites, filtering scenarios, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only notes that the tides are 'astronomical' and the location is HK, but it does not state that the operation is read-only, specify any limitations (e.g., year range, station validity), or mention the timezone of the returned times. This is a significant gap for a tool with zero annotation support.
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, front-loaded sentence: 'Get times, heights of astronomical high/low tides for a station in HK.' It is concise and contains no filler, efficiently stating the core function. However, it could be slightly more informative without becoming verbose, so it loses one point for under-specification in favor of brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (2 required) and no annotations, the description is too sparse for complete context. It does not mention how to obtain valid station codes (e.g., via get_tide_station_codes), specify the timezone of times, or clarify acceptable year values. Although an output schema exists and return values are therefore covered, the missing input and prerequisite information makes the tool under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It only hints that 'station' refers to a station in HK, but it provides no meaning for 'year' (e.g., format, allowed range) or 'options' (which is an object but undefined). The description adds minimal value beyond the schema and fails to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' with a specific resource: 'times, heights of astronomical high/low tides'. It scopes the operation to 'a station in HK', which clearly distinguishes it from sibling tools like get_hourly_tides (which provides hourly data) and get_tide_station_codes (which returns station codes). The purpose is immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention that get_tide_station_codes should be used to obtain valid station codes, nor does it contrast with get_hourly_tides. There is no explicit context or exclusion, leaving the agent to infer usage solely from the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description must disclose behavioral traits. It only states the function without mentioning timezone assumptions, location bounds, or what happens with omitted optional parameters. The read-only nature is implied by 'Get' but not explicit, and important context like default location or data source is absent.
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 wasted words. It directly states the tool's purpose without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and an output schema, the description is too minimal. It omits essential usage context such as the default location (since no location parameter exists), how to specify a date range, language codes, and behavior for null month/day values. The presence of an output schema reduces the need to explain return shapes, but the overall context remains thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning or usage of 'year', 'month', 'day', or 'lang'. It fails to compensate for the lack of schema descriptions, leaving agents to guess parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves moonrise, moon transit, and moonset times, using a specific verb ('Get') and resource ('moon times'). This clearly distinguishes it from sibling tools like get_sunrise_sunset_times and weather/tide 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. It does not mention exclusions, prerequisites, or situations where other tools would be more appropriate.
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 burden. It only states the operation and date format, without disclosing whether the data is read-only, historical, or any limitations/rate limits. Minimal behavioral context beyond the obvious retrieval.
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 one concise sentence, front-loaded with the purpose. However, it repeats the date format already in the schema, which is slightly redundant though not verbose.
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 has a clear schema and an output schema, so parameters and return values are covered. The description provides basic purpose but lacks usage context or mention of station code options, making it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for date, lang, and station. The description's date format note is redundant with the schema, so it adds no new semantic value. Baseline 3 applies due to high coverage.
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 'Get weather, radiation report for HK', specifying a verb and resource scope that distinguishes it from siblings like get_current_weather and get_radiation_station_codes. It lacks detail on what 'report' includes, so not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the 18 sibling tools. The only additional instruction is the date format constraint, which is more of an input requirement than usage guidance.
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 states data retrieval; it does not disclose units, timezone, response format, optional filtering behavior, or any other operational traits. For a tool with no annotation coverage, this is a significant gap.
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, focused sentence with no unnecessary words. It is front-loaded with the action and resource, and is appropriately sized for the tool's simplicity.
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?
Despite having an output schema, the description is too minimal for a tool with 4 parameters (1 required) and no annotations. It omits critical context such as station format, optional filters, and default behavior, leaving the agent underinformed for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'specific station' but does not define station identifier format or explain lang, year, or month parameters. It completely neglects parameter semantics, making it impossible for an agent to construct correct arguments beyond the required station.
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+resource: 'Get daily minimum temperature data' and clearly distinguishes from siblings like get_daily_max_temperature and get_daily_mean_temperature. It also adds geographic scope ('Hong Kong') and station-level granularity, making the 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 implies usage when needing daily minimum temperature for a specific station in Hong Kong, but it does not explicitly contrast with sibling tools (e.g., max/mean/current weather) or state any exclusions. There is no when-to-use vs alternatives guidance beyond the inherent purpose.
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. The description only says 'get list', which implies a read-only operation, but does not explicitly disclose the absence of side effects, any permission requirements, or behavior related to the 'lang' parameter. It adds minimal behavioral context beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the essential information: what the tool returns and for which location. Every word earns its place, with no filler or repetition.
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?
While the output schema exists (which could explain return values), the description is incomplete because it omits the 'lang' parameter semantics and provides no usage guidance relative to sibling tools. For a simple list tool, the lack of parameter documentation and contextual instructions leaves notable gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'lang' with default 'en' and zero description coverage. The tool description does not mention the parameter at all, leaving its semantics undetermined. Since schema coverage is 0%, the description must compensate, and it fails to provide any guidance on language options or how the parameter affects the output.
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: retrieving a list of tide station codes and names in Hong Kong. It uses a specific verb ('get') and resource ('tide station codes and names'), and distinguishes itself from sibling tide tools like get_hourly_tides and get_high_low_tides which return actual tide data, not station metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for obtaining station codes needed for tide reports, but does not explicitly state when to use it versus alternatives or when not to use it. There is no mention of prerequisites or that it should be called before other tide endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It mentions data content and source but does not state read-only behavior, data freshness, units, limitations, or whether any authorization is needed. 'Get' only weakly implies a non-mutating 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 a single, front-loaded sentence that efficiently conveys the essential purpose and scope. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity with full schema coverage and an output schema, so the description does not need to explain return values. It adequately covers the core purpose and data content, though it omits usage context relative to siblings, which is partially addressed in other dimensions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters (lang and region) with defaults and descriptions, so the parameter semantics are fully documented. The description adds no parameter-specific meaning beyond the overall 'HK' scope, which is consistent with the default region.
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 retrieves current weather data, including warnings, temperature, and humidity, specifically for Hong Kong from HKO. This distinguishes it from sibling forecast and warning tools, though 'warnings' also appear in dedicated warning tools, creating slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_local_weather_forecast or get_weather_warning_summary. The description implies current conditions but does not explicitly exclude other use cases or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the function without mentioning units, data source, filtering behavior, error handling, or response format. There is no indication of whether this returns historical data or current data, or what happens if no data matches the station/year/month.
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, clear sentence with no wasted words. It is front-loaded and easily digestible. The structure could be improved by adding more detail, but for what it contains, it is concise and well-formed.
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 an output schema that covers return values, but the description still lacks essential context about optional filters (year, month) and the meaning of 'daily' in terms of time range. The description does not mention that the user can specify a particular year/month, despite these being available in the schema. This makes the description incomplete for proper invocation in many realistic scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'specific station,' which aligns with the required 'station' parameter. However, it does not explain the optional 'year', 'month', or 'lang' parameters, nor does it clarify their formats or the effect of omitting them. This leaves the agent to infer most parameter semantics from names alone.
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 identifies the tool as retrieving daily mean temperature data for a specific Hong Kong station. The verb 'get' and resource 'daily mean temperature data' are specific, and the word 'mean' distinguishes it from sibling tools like get_daily_max_temperature and get_daily_min_temperature.
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 says to use this for daily mean temperature, which implies a retrieval scenario. However, it does not explicitly state when to choose this over alternatives or when not to use it. No exclusions or comparisons are provided, though the tool's name and description make the primary use case obvious.
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 present, so the description carries the full burden, but it only describes the output content and location. It does not disclose behaviors like language parameter effects, data source, update frequency, or any limitations. The verb 'Get' weakly implies read-only, but this is not explicit.
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 word contributes: 'Get', '9-day', 'weather forecast', 'HK', and the included data types are all relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple forecast tool with an output schema, the description adequately covers what is returned (9-day forecast, general situation, daily data) and the fixed location. However, it omits any mention of the language parameter, which is part of the schema and may affect the output language.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter 'lang' with default 'en', and schema description coverage is 0%. The description does not mention this parameter or explain accepted values (e.g., 'en', 'tc', 'sc'), leaving the agent to infer its meaning from the name alone.
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 a specific verb ('Get'), a distinct resource ('9-day weather forecast for HK'), and the included content ('general situation, daily data'). This distinguishes it from sibling tools like get_current_weather and get_local_weather_forecast, which offer different forecast periods.
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 prefer this tool over alternatives such as get_current_weather or get_local_weather_forecast. It does not mention exclusions, prerequisites, or context beyond the fixed 'HK' scope.
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 states the basic read operation without disclosing output format, timezone, data source, or limitations. This is minimal behavioral 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 a single, tightly worded sentence with no redundancy or filler. It is front-loaded with the core action and resource.
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 description is too sparse for reliable invocation: no parameter guidance, station code format, or year range. Although an output schema exists, it does not compensate for the missing usage context and ambiguous parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only vaguely references a 'station' without explaining its format. The 'year' and 'options' parameters are completely omitted, leaving the agent without needed guidance.
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 tide heights for stations in Hong Kong, using a specific verb and resource. It distinguishes itself from sibling tools like get_high_low_tides by explicitly mentioning 'hourly heights'.
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 gives context ('for a station in HK') but does not specify when to prefer this tool over alternatives or provide any exclusions. Usage must be inferred from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It clearly indicates a read-only operation (Get), but does not disclose any side effects, rate limits, or parameter behavior. The behavior is minimally transparent but lacks richness.
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 sentence of eight words, front-loaded with the verb and resource. No unnecessary words or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity with one optional parameter and an output schema, but the description omits the 'lang' parameter entirely and provides no usage context. This makes it incomplete for reliable invocation and parameter handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, 'lang', with no description and 0% schema coverage. The tool description does not mention this parameter at all, failing to compensate for the lack of schema info. An agent has no way to know what 'lang' controls.
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 'Get cloud-to-ground and cloud-to-cloud lightning count data' with a specific verb ('Get') and a specific resource (lightning count data). It distinguishes itself from sibling weather/tide tools that handle different 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. Usage is implied (need lightning counts), but there is no comparison with other tools 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, placing the full burden on the description. It only states basic purpose and does not disclose behavioral traits such as timezone handling, behavior when month/day are omitted, or read-only nature. The description adds no context beyond the function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded with the action verb and contains only essential 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?
While the output schema exists to document return values, the description still lacks critical handling information: how optional month/day parameters behave, what lang controls, and any timezone context. For a multi-parameter tool with no annotations or parameter docs, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the four parameters (year, month, day, lang). It mentions none of them, providing no additional meaning about their roles, defaults, or relationships. The parameter names are self-explanatory, but the description fails to aid in correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with concrete resources 'times of sunrise, sun transit and sunset' and geographic scope 'for Hong Kong'. It clearly distinguishes this tool from sibling tools like get_moon_times by naming solar events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states its context (Hong Kong solar times), which sufficiently implies when to use it. However, it does not explicitly mention alternatives or exclusion scenarios, though the unique domain among siblings makes the context 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 must carry the burden. It states the basic operation ('Get list of weather station codes and names'), which is clear for a simple read-only list. However, it does not disclose whether all stations are returned, how the lang parameter affects behavior, or any limitations, though these are not critical for such a tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, front-loaded with the action and resource. Every word contributes to the core meaning, with no filler or redundant 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?
For a tool with one optional parameter and an output schema present, the description adequately covers the essential purpose and output. It does not explicitly link to the sibling get_weather_radiation_report, but that is more of a usage guideline nuance. Overall, it is sufficiently complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, lang, with a default but no enums or description. Schema description coverage is 0%, and the description does not explain lang or its possible values. While the parameter name is self-explanatory, the description adds no meaning beyond the schema, so the baseline for low coverage is reduced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and clearly states the resource: 'list of weather station codes and names for radiation reports in HK.' It distinguishes itself from sibling tools like get_tide_station_codes by specifying 'for radiation reports,' leaving no ambiguity about its function.
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 a use case (obtaining station codes for radiation reports), and the sibling tool get_weather_radiation_report hints at a prerequisite relationship. However, it does not explicitly state when to use this tool, when not to use it, or mention any alternatives, leaving usage guidance solely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It adds useful context about the temporal resolution (10-minute mean) and geographic scope, but does not mention data source, units, update frequency, or any limitations. The read-only nature is implied by 'Get'.
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, focused sentence that conveys the essential purpose without any fluff. It is appropriately front-loaded and easy to parse.
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 is simple with one optional parameter and an output schema present, which reduces the need to describe return values. The description covers the core purpose and geographic scope. It could optionally mention the update frequency or units, but the current level is sufficient for this simple data-access tool.
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 provides 100% coverage for the sole parameter 'lang', including its default and allowed values. The description adds no parameter-specific information, but this is acceptable given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get), the specific resource (latest 10-minute mean visibility data), and the location (Hong Kong). This distinguishes it from all sibling tools, none of which mention visibility.
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 usage context is implied by the tool's name and description: it is for retrieving visibility data. However, there is no explicit guidance on when to use this tool versus alternatives (e.g., get_current_weather) or any exclusion criteria.
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:

[![hk-climate-mcp-server MCP server](https://glama.ai/mcp/servers/hkopenai/hk-climate-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/hkopenai/hk-climate-mcp-server)

Score Badge

Copy to your README.md:

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

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