extremes
PRO. Warmest and coldest AMeDAS stations in the latest map (by temp).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| access_token | No | Subscriber token from /success (or Authorization: Bearer) |
PRO. Warmest and coldest AMeDAS stations in the latest map (by temp).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| access_token | No | Subscriber token from /success (or Authorization: Bearer) |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so the description carries the whole behavioral burden, and it discloses little. 'PRO' vaguely signals a paid/subscriber tier and the schema's access_token implies auth, but the description never confirms the requirement or explains what happens without it. 'Latest map' is undefined — how stale, how many stations, what ranking direction — and there is no word on return shape or limits.
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?
One front-loaded sentence with no filler; the tier marker leads and the core statement follows. Its brevity is efficient rather than rambling, though the terseness edges toward under-specification.
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?
With no annotations and no output schema, the description has to cover auth expectations, the meaning of 'latest map', and result structure — none of which appear. A caller knows roughly what they get but not what they need to supply or how to interpret the response.
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 50%: access_token is documented in the schema but limit has no description anywhere. The description adds nothing about parameters — not whether limit controls how many warmest/coldest entries come back per side, nor its default or maximum, which is the single most likely misuse for this tool.
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?
Names a specific resource and result set: warmest and coldest AMeDAS stations from the latest observation map, ranked by temperature. That distinguishes it from sibling station (individual station data) and latest_obs_time (observation timestamp). The verb is only implied ('returns'), but the outcome is unambiguous.
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?
Intended use is inferable — fetch top/bottom temperature stations for the latest map — but there is no explicit statement of when to pick this over station or latest_obs_time, and no preconditions are spelled out. The 'PRO' prefix hints at a gated tier without explaining what that means for the caller.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.