Retrieve live Baltic Sea sea-level and water temperature observations from Finnish coastal mareographs, with configurable lookback hours and station limits.
Fetch live Baltic Sea mareograph sea-level and water temperature observations along the Finnish coast (CC BY 4.0).
| Name | Required | Description | Default |
|---|---|---|---|
| hoursBack | No | ||
| maxStations | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden, yet it only adds 'live' (freshness) and a CC BY 4.0 license note. It says nothing about rate limits, authentication, coverage/station availability, or what happens when no recent observation exists for a station.
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 well-formed sentence with the data scope front-loaded and no filler; the license tag is the only appended element. It is efficient, though its brevity comes partly at the cost of the missing parameter and usage detail.
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?
For a simple two-optional-parameter read tool with no output schema, the description establishes what the data is and its freshness, which is close to sufficient. It falls short because neither parameter is explained and no annotation fills that gap, leaving the agent to guess the effect of hoursBack and maxStations.
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% and the description never mentions 'hoursBack' or 'maxStations'. The schema supplies types, defaults and bounds, but the description contributes no meaning about what the lookback window or station cap actually control, so it does not compensate for the coverage gap.
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 ('Fetch'), a specific resource ('sea-level and water temperature observations'), and constrains it geographically ('Baltic Sea mareograph ... Finnish coast') plus temporally ('live'). This implicitly separates it from weather siblings like fmi_station_weather and fmi_weather_observations, though it never names them explicitly.
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 word 'live' hints that only recent data is returned, but there is no explicit statement of when to pick this over fmi_weather_observations, fmi_station_weather, or fmi_fingrid_nowcast, and no prerequisites or exclusions are given. An agent must infer the choice from the resource name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.