get_weatherFetches weather and temperature for a Tokyo-area location from JMA, adds heatstroke alerts for high temperatures, and returns advice in Japanese, English, or Chinese.
天気情報取得＆多言語AIアドバイス - 気象庁APIから天気・気温を取得。高温時は熱中症注意を表示。language（ja/en/zh）指定で応答言語を強制可能。
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | 応答言語の強制指定（省略時は地域名から自動判定） | |
| area_name | Yes | 地域名（例: 東京, 横浜） |
Changes observed during successful MCP inspections.
v2.58.7Input schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / languageAdded value: +{
+ "description": "応答言語の強制指定（省略時は地域名から自動判定）",
+ "enum": [
+ "ja",
+ "en",
+ "zh"
+ ],
+ "type": "string"
+}Input schema / requiredPrevious value: -[]New value: +[
+ "area_name"
+]v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds genuinely new context: the upstream data source (JMA API), the conditional heatstroke-caution behavior on high temperatures, and the fact that language can be forced rather than only auto-detected. It does not describe response shape or failure behavior, but that is a minor gap given the 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?
A single dense sentence that front-loads the core capability (weather/temperature retrieval) before the secondary features. No wasted clauses, though the dash-separated marketing phrasing ('多言語AIアドバイス') could be tightened.
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?
There is no output schema, so the description carries the burden of explaining returns; it does state that weather and temperature values come back and that a heatstroke notice may appear. That is adequate for a two-parameter read tool, with only the exact response structure left unspecified.
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 100%, with both parameters documented and the language enum with its ja/en/zh values spelled out in the schema. The description restates the language override rather than adding format or syntax detail beyond it, so the baseline of 3 applies.
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?
States a specific verb and resource — fetch weather/temperature from the Japan Meteorological Agency API — plus the value-adds (heatstroke caution, multilingual output). The tool is clearly distinct from the transit-oriented siblings, though the hyphenated 'multilingual AI advice' framing slightly muddles a clean one-line purpose statement.
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?
Usage is implied: an agent seeking weather/temperature for a region would call this, and no sibling overlaps in the weather domain. However, there is no explicit when-to-use, when-not, or alternative routing guidance, and no stated prerequisite that area_name must be supplied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.