Get Taiwan city weather forecast for the next 36 hours. Returns three time periods with weather conditions, rain probability, temperature range, and comfort level.
查詢台灣某縣市未來 36 小時天氣預報。
回傳三個時段的天氣現象、降雨機率、氣溫區間與舒適度。
縣市名稱接受常見寫法，例如「台中」「臺北市」「高雄」「Taipei」；
「新竹」「嘉義」同時對應市與縣，會一次回傳兩者。
Args:
city: 縣市名稱（台灣 22 縣市，中英文皆可）。
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the return format (three periods), the specific data fields, and the special handling for ambiguous city names. It does not mention rate limits or authentication, but for a simple query tool, this is sufficient.
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 five sentences, front-loaded with purpose, then return data, examples, and parameter documentation. No fluff, each sentence adds value.
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 has an output schema (not shown), the description still covers the input and output adequately. It specifies the time period, data fields, and city name handling, making it complete for a simple forecast tool.
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 coverage is 0% (only type string), and the description adds rich semantics: accepted city names (Chinese and English), examples, and the behavior for ambiguous names like 新竹/嘉義 returning both city and county. This fully compensates for the lack of schema 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 it queries the 36-hour weather forecast for a city in Taiwan, listing the returned fields (weather phenomena, rain probability, temperature range, comfort level) and handling ambiguous city names. It is a specific verb+resource and distinct from siblings like get_recent_earthquakes.
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 does not explicitly state when to use this tool versus alternatives, but it provides context by listing examples and noting ambiguous city name behavior. It implies usage for weather forecasts but offers no exclusion criteria or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tun0000/taiwan-weather-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server