met-mcp

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden for behavioral disclosure. The description is straightfoward: it 'finds' stations, which implies a read operation. It adds a useful hint about the return type (station ID format) and how to use it downstream. However, it doesn't disclose any potential failures (e.g., what happens if no stations are found), any rate limits, or whether the required coordinates are validated for proximity. The description adds some value but is not deeply informative about 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 concise: one sentence with a clear action and a helpful downsteam usage tip. It is front-loaded with the core purpose and then adds the valuable station-ID hint. No wasted words. It could potentially describe the coordinates more, but for a simple lookup tool, it's appropriately sized.

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 simplicity (3 params, no output schema), the description is adequately complete. It states the resource type (official weather stations), the domain (Frost), and a downstream use case. It doesn't describe the return structure (e.g., does it return a list of stations with their own coordinates?), but the agent can likely infer that from 'find stations' and the schema. The lack of an output schema means the description could be more descriptive about the response shape, but it's not critical for an agent to invoke the tool correctly.

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 100%, so the schema already documents all three parameters (latitude, longitude, count) including their constraints and defaults. The description adds the fact that stations are 'nearest' to the given coordinates, which clarifies the role of latitude/longitude, but that's implicit in the schema. The description does not add any details about count or its behavior beyond what the schema says. Since coverage is high, baseline 3 is appropriate.

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 states a specific verb and resource: 'Find the nearest official weather stations (Frost).' It clearly indicates the tool's function and hints at the domain (meteorological data). It doesn't explicitly differentiate from siblings, but the reference to 'Frost' and the station ID gives it a unique identity. The description is clear enough that an agent can distinguish it from the other weather-related tools based on the resource it targets.

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 usage guidance by telling the agent to use the station ID with get_historical_weather. This implicitly states that the tool is a prerequisite for another tool, which is useful routing information. However, it doesn't explicitly state when NOT to use this tool or mention alternatives (e.g., get_nowcast or get_forecast might also need station IDs, but that's not stated). The guidance is clear but could be more explicit about exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are absent, so the description bears full responsibility for disclosing the tool's behavior. 'Find latitude and longitude' accurately conveys a read-only geocoding lookup. However, important behavioral traits go undisclosed: the tool can return multiple matches (implied by the count parameter), there's no mention of no-match behavior, and the coordinate format isn't specified. The description is accurate but shallow—it could easily have added a caveat about ambiguous place names or rate limiting without much effort.

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?

Two sentences, no filler. The first sentence is the core purpose, the second adds workflow value by connecting the output to sibling tools. Every word earns its place, and the structure is maximally front-loaded—an agent scanning the first sentence knows exactly what this tool does.

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 low-complexity tool (2 flat params, no nested objects, no enums), the description is nearly complete. The 'use the coordinates with the other tools' line provides crucial integration context, and the description's mention of 'latitude and longitude' gives a hint about the return shape even without an output schema. The main gap is the lack of explicit discussion of multi-match (returned array of candidates) behavior, which the count parameter implies—but this is a minor omission for an otherwise simple lookup 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 100% with both parameters well-documented ('name' includes 'Place name, e.g. 'Bergen' or 'Oslo, Norway'' and 'count' includes 'Maximum number of matches to return' with min/max constraints). Per the rubric, high coverage gives a baseline of 3, and the description doesn't need to add parameter detail. The description's phrasing 'for a place name' echoes the name parameter without restating the schema. The schema carries the weight here, exactly as intended.

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 states a clear verb+resource: 'Find latitude and longitude for a place name.' The name 'geocode_location' and the description's mention of coordinates make the operation unambiguous. The sibling tools are all weather/forecast endpoints, so this tool naturally stands apart as the geocoding prerequisite, and the description makes that distinct role clear. It could be more explicit about disambiguating the output to a single canonical place, but the core purpose 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?

The description's second sentence, 'Use the coordinates with the other tools,' provides valuable workflow context: this tool is a prerequisite step that feeds the forecast/station siblings. This implicitly tells the agent when to reach for this tool (when it has only a place name and needs coordinates for get_forecast, etc.). It doesn't name specific alternatives or when-not-to-use conditions, but given the siblings are all weather consumers of this tool's output, the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations present, the description carries the burden of disclosing behavior. It usefully discloses the data source, the hourly granularity, and geographic coverage. It does not mention auth needs, rate limits, response format, or failure behavior, so the disclosure is informative but incomplete.

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 a single, front-loaded sentence that states the verb, resource, input, and a key limitation. There is no wasted text, and all information earns its place.

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?

The tool is simple, all parameters are covered by the schema, and no output schema exists. The description conveys the essential behavior: an hourly forecast at a coordinate. It could mention what the response contains or how to get coordinates first, but those gaps are minor for this tool's straightforward invocation.

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%, so the schema already documents latitude, longitude, and hours with types, bounds, and defaults. The description adds only a high-level mapping ('hourly' → hours, 'coordinate' → lat/long) and no new parameter meaning, matching the baseline for high schema coverage.

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 states a specific action ('get'), a specific resource ('hourly weather forecast from MET Norway (Yr)'), and a specific input ('for a coordinate'). It clearly distinguishes the tool from the sibling geocode_location, which addresses a different task.

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 implies that the tool is for weather data at an already-known coordinate, and 'works worldwide, best coverage in the Nordics' adds practical context. However, it does not explicitly explain when to use this tool instead of geocode_location, nor does it mention that geocoding may be needed to obtain coordinates. The usage guidance is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 reveals the data source (Frost archive) and the depth of history (100+ years), which informs expectations about temporal coverage. However, it does not disclose output format, pagination, units, error handling, or any access limitations—gaps that are material for an agent.

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 a single sentence that front-loads the core action ('Daily historical observations') and immediately follows with useful context (Frost archive, 100-year span) and a practical pointer (find_weather_stations). Every word earns its place with no redundant or vague wording.

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 output schema and no annotations, the description is sparse. It covers the purpose and prerequisite but omits return-value details (e.g., units, format, whether data is aggregated daily) and error behavior (e.g., missing data handling). While the schema explains parameters, an agent still lacks enough information to confidently interpret the tool's 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?

The input schema provides 100% coverage with descriptive text for all four parameters, including defaults for 'elements' and pattern constraints for dates. The description adds no extra parameter-level meaning beyond pointing to find_weather_stations for station_id, which is already implied in the schema. The baseline of 3 is appropriate when schema covers everything.

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 core function: 'Daily historical observations from a weather station.' It specifies the data source (Frost archive) and historical depth (over 100 years), which distinguishes it from sibling tools like get_forecast and get_nowcast. The purpose is unambiguous and correctly frames the tool's scope.

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 explicitly instructs to use find_weather_stations to locate station ids, providing a clear prerequisite for use. It implies historical usage via the word 'historical' but does not explicitly contrast with forecast/nowcast tools. The guidance is helpful but could be more explicit about when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the behavioral burden. It discloses the data source (radar-based), temporal resolution (minute-by-minute), forecast horizon (next 2 hours), and geographic restriction (Nordic region only). It omits response format details and non-coverage behavior, but enough behavioral context is present for safe selection and invocation.

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?

Three short sentences, each adding distinct value: what is returned, the time horizon and source, then the use case. No wasted words or duplication of the title or schema.

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, low-complexity tool with two well-documented parameters, the description is sufficient for an agent to select and invoke it. The lack of an output schema means the response format is not explicitly described, but the description strongly indicates a precipitation series, which is enough to act.

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 for the two parameters is effectively complete (latitude/longitude, with ranges and descriptions provided). The description adds a meaningful geographic constraint 'Nordic region only', but it does not add much per-parameter semantics beyond what the schema already includes.

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 function: minute-by-minute precipitation for the next 2 hours, based on radar data. It also defines the geographic scope (Nordic region only) and includes an applied use case ('do I need an umbrella right now?'), which distinguishes it from sibling tools like get_forecast and get_ocean_forecast.

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 gives a clear context for use: immediate, short-horizon precipitation checks. It does not explicitly name alternatives or say when not to use it, but the time window ('next 2 hours') and 'umbrella right now' framing make the intended scenario obvious.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations are absent, so the description carries the entire behavioral burden. It says the tool returns wave conditions and covers a fixed geographic region, but says nothing about whether this is a read-only operation, whether forecasts carry uncertainty/time horizons beyond the 1–48h hours parameter, data licensing, or units of the returned wave height (feet, meters). Without annotations there is no safety or mutational profile at all.

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?

Three lines, dense with signal; scope and coordinate system in the first sentence. No orphan phrases like 'this tool does' or 'see schema for details.'

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?

After adding annotations and a good parameter schema, the missing pieces are: no output schema (the agent doesn't know what response fields look like), no mention of data freshness or source attribution, no latitude/longitude-order gotcha, no error semantics. For a wave-forecast tool these aren't fatal, but the lack of any return value disclosure in the description is a real gap.

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_parameter_description_coverage is full: every parameter has a schema description (latitude, longitude, hours). The semantic says latitude/longitude are decimal degrees, hours has min/max/default. Description adds no mention of coordinate format (e.g. 'lat, lon' vs 'lon, lat') above the schema, so saw a small amount of redundancy, but the schema carries the weight.

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+resource ('Wave height, wave direction, and sea temperature') and a geographic scope ('Norwegian coast and nearby seas'). It does not explicitly name a sibling, but for a standalone forecast tool in this domain the core purpose 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?

The description implies use (forecasting along the Norwegian coast) but it names no alternative tool and gives no exclusion or when-not-to-use context. An agent could still call it to request a wave forecast anywhere on Earth and get a result that doesn't apply.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral disclosure. It explains what the tool returns and that it works globally, but it does not mention edge cases such as polar day/night, missing sunrise/sunset values, time format, or how the UTC offset affects returned times beyond the schema.

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 two short sentences and both of them directly serve the goal. It is front-loaded with the core output and avoids redundant phrasing.

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 output schema, the description names the expected results but does not describe their format or how edge cases behave. Combined with the schema, the definition is sufficient for basic calls but lacks some context for unusual locations and ambiguous timezone semantics.

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%, so all parameters are already documented with type and format. The description adds no meaningful information, whereas 'coordinate' and 'date' are broad restatements of the schema fields.

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 title and description clearly identify the tool as returning sunrise, sunset, and solar noon for a given coordinate and date. The phrase 'Works worldwide' adds meaningful scope, and the resource is distinct from the weather-focused sibling tools.

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 intended use is reasonably implied—request sun-event times for a location and date—but no explicit guidance is given about when to choose this tool over alternatives. The sibling list makes the distinction obvious, so the lack of direct comparison is a moderate gap rather than a severe one.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It discloses that alerts are official danger warnings, in Norwegian, covering Norway/waters. This is useful. But it doesn't disclose behaviors like alert significance levels (yellow/orange/red), update cadence, or what happens with benign conditions (empty list?). Since no annotations exist, this is a moderate 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?

Three sentences, focused. The most important facts (what it is, scope, optional filters) are front-loaded. No filler. Could potentially merge the Norwegian text note, but it's relevant for the agent to know.

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 2-param optional tool, it's decent. Tells coverage, type, and language. Missing: what the response shape looks like (no output schema), whether alerts are paginated or have severity levels, and whether an empty result is possible. Because it deals with official warnings, an agent might need to know how to interpret severity.

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 100% (both params described as latitude/longitude decimal degrees). The description adds a little: omitting coordinates yields all alerts. But it doesn't explain the relationship (e.g., proximity radius) or behavior when only one coordinate is provided. Baseline 3 is fair since schema already documents units.

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 (get weather alerts) and the scope (Norway and waters), plus the alert types. Siblings are focused on forecast/station/etc, so purpose is clear, though it doesn't explicitly differentiate from get_forecast or get_nowcast beyond the 'danger warnings' angle.

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?

Gives a clear usage hint: omit coordinates for all current alerts, likely imply include coordinates for local alerts. It mentions source (MET Norway) and coverage area. However, it doesn't explicitly say when to use this over get_forecast or get_nowcast, though the danger-warning nature is implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.