一个基础的模型上下文协议 (MCP) 服务器，提供从马来西亚官方开放数据门户的开放 API 检索的天气信息。该服务器使 LLM 能够获取天气预报、警报、洪水相关水位以及地震报告。
API 文档： data.gov.my
获取水位条件
检索指定地区或州的洪水警报相关的水位状况。如果同时提供地区和州，则以地区为准。如果未指定地区或州，则该字段为空字符串。
参数：
区：指定州内要检索洪水预警情况的地区名称。
州：要检索洪水预警情况的马来西亚州的名称。
获取警告
检索指定日期范围内发布的一般天气警告。
参数：
datetime_start：以YYYY-MM-DD HH:MM:SS （含）格式表示的最早时间戳，用于获取天气预警信息。如果省略，则默认为当前日期。
datetime_end：以YYYY-MM-DD HH:MM:SS （含）格式表示的停止检索天气预警的最晚时间戳。如果省略，则默认为当前日期。
获取天气预报
检索给定日期范围内特定位置的天气预报。
参数：
location_name：检索预报的位置的名称或标识符。
date_start：开始检索天气预报的最早日期（含）。如果省略，则默认为当前日期。
date_end：停止检索天气预报的最晚日期（含）。如果省略，则默认为当前日期。
获取地震新闻
获取指定日期范围内特定地点的地震新闻。
参数：
位置：地震发生地点的名称或标识符。
date_start：开始搜索地震新闻的最早日期（含）。如果省略，则默认为当前日期。
date_end：停止搜索地震新闻的最晚日期（含）。如果省略，则默认为当前日期。
Related MCP server: Weather MCP Server
在claude_desktop_config.json文件中添加以下内容。更多信息，请参阅Claude Desktop 用户指南。
uv{
"mcpServers": {
"weather": {
"command": "uv",
"args": [
"--directory",
"weather-my-mcp",
"run",
"weather.py"
]
}
}
}创建docker镜像
docker build . --tag weather-my-mcp编辑claude_desktop_config.json文件如下：
{
"mcpServers": {
"weather": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"weather-my-mcp"
]
}
}
}此 MCP 服务器采用 MIT 许可证。这意味着您可以自由使用、修改和分发该软件，但须遵守 MIT 许可证的条款和条件。更多详情，请参阅项目仓库中的 LICENSE 文件。
Fetch earthquake news for a given location within a specified date range.
Args:
location: Name or identifier of the place where the earthquake(s) occurred.
date_start: The earliest timestamp in the form of <YYYY-MM-DD HH:mm:ss> (inclusive) to start searching for earthquake news. If omitted, defaults to the current date.
date_end: The latest timestamp in the form of <YYYY-MM-DD HH:mm:ss> (inclusive) to stop searching for earthquake news. If omitted, defaults to the current date.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | ||
| datetime_start | No | ||
| datetime_end | No |
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 mentions fetching news but doesn't describe what 'news' entails (e.g., articles, alerts, data points), potential rate limits, authentication needs, or error handling. The description lacks details on return format, pagination, or data freshness, leaving significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the purpose stated clearly in the first sentence. The parameter explanations are concise and directly relevant, avoiding unnecessary details. However, the formatting with 'Args:' and bullet-like indentation could be slightly more streamlined, but it remains efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is partially complete. It covers the purpose and parameter semantics adequately but lacks behavioral details like output structure, error cases, or usage guidelines relative to siblings. Without annotations or output schema, more context on what 'news' returns would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'location' is a 'Name or identifier of the place where the earthquake(s) occurred,' clarifies timestamp formats for date parameters, and specifies default behaviors (e.g., defaults to current date if omitted). This compensates well for the schema's lack of descriptions, though it doesn't cover all nuances like valid location formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Fetch earthquake news for a given location within a specified date range.' It specifies the verb ('fetch'), resource ('earthquake news'), and scope ('location within date range'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_warning' or 'get_weather_forecast', which might also involve location-based data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools or clarify scenarios where 'get_earthquake_news' is preferred over 'get_warning' or 'get_water_level_condition', nor does it specify prerequisites or exclusions. Usage is implied only through the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve general weather warnings issued within a specified date range.
Args:
datetime_start: The earliest timestamp in the form of <YYYY-MM-DD HH:mm:ss> (inclusive) from which to retrieve weather warnings. If omitted, defaults to the current date.
datetime_end: The latest timestamp in the form of <YYYY-MM-DD HH:mm:ss> (inclusive) to stop retrieving the weather warnings. If omitted, defaults to the current date.
| Name | Required | Description | Default |
|---|---|---|---|
| datetime_start | No | ||
| datetime_end | No |
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 describes the action ('retrieve') and date range filtering, but lacks critical behavioral details: it doesn't specify if this is a read-only operation, what permissions are needed, how results are returned (e.g., format, pagination), error handling, or rate limits. For a retrieval tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a structured 'Args:' section with bullet-like explanations for each parameter. Every sentence adds value—no redundancy or fluff. The structure makes it easy to scan, with key information presented efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is partially complete. It excels in parameter semantics and purpose clarity but lacks usage guidelines and behavioral transparency. Without annotations or output schema, it should ideally cover more behavioral aspects (e.g., response format, safety). It's adequate as a minimum viable description but has clear gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema, which has 0% description coverage. It explains both parameters: datetime_start as 'The earliest timestamp... (inclusive) from which to retrieve weather warnings' with format details and default behavior, and datetime_end similarly. This fully compensates for the schema's lack of descriptions, providing clear semantics, formats, and defaults that are not in the schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieve general weather warnings issued within a specified date range.' This specifies the verb ('retrieve'), resource ('general weather warnings'), and scope ('within a specified date range'). It distinguishes from siblings like get_earthquake_news or get_weather_forecast by focusing on warnings rather than news, conditions, or forecasts. However, it doesn't explicitly differentiate from all siblings (e.g., water level conditions might overlap with weather warnings), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like get_earthquake_news or get_water_level_condition, nor does it specify scenarios where weather warnings are preferred over forecasts or other data sources. The only implied usage is for retrieving weather warnings by date, but no explicit when/when-not instructions or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the water level conditions associated with flood warnings for a specified district or state. If both district and state are provided, the district takes precedence. If district or state is not specified, use an empty string for that field.
Args:
district: The name of the district within the specified state for which to retrieve flood warning conditions.
state: The name of the state in Malaysia for which to retrieve flood warning conditions.
| Name | Required | Description | Default |
|---|---|---|---|
| district | No | ||
| state | No |
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. While it describes the retrieval action and parameter precedence, it lacks critical behavioral details such as whether this is a read-only operation, what authentication might be required, rate limits, error conditions, or the format of returned data. For a tool with zero 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The parameter explanations are necessary given the schema coverage gap. However, the formatting with 'Args:' could be slightly more integrated, and some sentences could be more concise (e.g., the second sentence about precedence is clear but slightly wordy).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters, no annotations, no output schema), the description is moderately complete. It covers purpose and parameter semantics well but lacks behavioral transparency and output details. Without annotations or output schema, the description should ideally provide more context about what the tool returns and any behavioral constraints to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema, which has 0% description coverage. It explicitly defines both parameters: 'district: The name of the district within the specified state for which to retrieve flood warning conditions' and 'state: The name of the state in Malaysia for which to retrieve flood warning conditions.' This clarifies the geographic scope and relationship between parameters, fully compensating for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieve the water level conditions associated with flood warnings for a specified district or state.' It specifies the verb (retrieve), resource (water level conditions), and context (flood warnings). However, it doesn't explicitly differentiate from sibling tools like 'get_warning' or 'get_weather_forecast' beyond the specific resource focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'If both district and state are provided, the district takes precedence. If district or state is not specified, use an empty string for that field.' This gives explicit guidance on parameter precedence and handling of unspecified fields. However, it doesn't mention when to use this tool versus alternatives like 'get_warning' or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a weather forecast for a specific location within a given date range.
Args:
location_name: The name or identifier of the location for which the forecast is retrieved.
date_start: The earliest date (inclusive) to begin retrieving the weather forecast. If omitted, defaults to the current date.
date_end: The latest date (inclusive) to stop retrieving the weather forecast. If omitted, defaults to the current date.
| Name | Required | Description | Default |
|---|---|---|---|
| location_name | Yes | ||
| date_start | No | ||
| date_end | No |
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 describes what the tool does (retrieve forecast) but lacks details on behavioral traits such as rate limits, authentication needs, error handling, or what happens if dates are invalid. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by a structured 'Args' section. Every sentence adds value, with no wasted words, though the structure could be slightly more streamlined (e.g., integrating defaults into the main description).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 3 parameters, the description is moderately complete. It covers the purpose and parameters well but lacks details on return values, error cases, or behavioral context. For a retrieval tool with no structured support, it meets minimum viability but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds meaningful semantics beyond the schema by explaining each parameter: location_name as 'name or identifier', date_start and date_end with defaults and inclusivity. This clarifies usage effectively, though it could specify date format or location identifier examples for a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieve a weather forecast for a specific location within a given date range.' It specifies the verb (retrieve), resource (weather forecast), and scope (location and date range). However, it does not explicitly differentiate from sibling tools like get_earthquake_news or get_warning, which handle different types of data, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 sibling tools or other contexts where this tool might be preferred or avoided. Usage is implied by the purpose but lacks explicit instructions, leaving gaps for an AI agent to infer correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_earthquake_newsget_warningget_water_level_conditionget_weather_forecastScored across 4 tools
Each tool has a clearly distinct purpose: get_earthquake_news for earthquake-related news, get_warning for general weather warnings, get_water_level_condition for flood-specific water level data, and get_weather_forecast for general weather predictions. There is no overlap in functionality, and the descriptions clearly differentiate their domains (earthquakes, warnings, floods, forecasts).
All tool names follow a consistent verb_noun pattern with 'get_' as the prefix, followed by a descriptive noun phrase (e.g., get_earthquake_news, get_warning, get_water_level_condition, get_weather_forecast). This uniformity makes the tool set predictable and easy to understand.
With 4 tools, the count is reasonable for a weather-focused server, covering key areas like earthquakes, warnings, floods, and forecasts. It is slightly lean but well-scoped, as each tool addresses a distinct aspect of weather and related hazards without redundancy.
The tool set covers specific weather-related data (earthquakes, warnings, floods, forecasts) but has notable gaps for a general 'Weather MCP' server. Missing operations include current weather conditions, historical data, or broader meteorological tools (e.g., humidity, wind speed), which limits comprehensive coverage of the weather domain.
Geospatial MCP server for earthquake, tsunami, volcano, disaster, and FX data queries.
Hosted MCP server for Xweather weather data: conditions, forecasts, alerts, and more.
This MCP server provides seamless access to Malaysia's government open data, including datasets, w…
An MCP server for weather information by @kulybaba