Weather MCP Server by Meteosource

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

With no annotations, the description carries the full burden and does well: it discloses the return shape (a table per location with `columns` once and `rows` as arrays), that output is trimmed to `hours`, the default variable set, the 20-location cap, the ~4-day horizon, and a tier restriction. It stops short of error behavior or auth/rate-limit details.

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?

Front-loaded with purpose, then output shape, then caveats; every sentence contributes. The pollutant variable enumeration is long but earns its place by telling the agent what values `variables` accepts.

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?

No output schema and no annotations, so the description must stand alone — and it covers output layout, defaults, geographic limit, horizon, and tier restriction. It is nearly complete for invocation, with only timezone semantics and over-limit error behavior left undocumented.

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?

Top-level schema description coverage is 0%, yet the description names the default variables (pm10, pm25, no2_surface, so2_surface, ozone_surface), enumerates the additional options for `variables`, and explains that `hours` trims the table. It adds meaning well beyond the schema, though `timezone` and the place_id-vs-lat/lon choice go unaddressed here.

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 with scope: hourly air-quality (smog) forecast for up to 20 locations, ~4 days ahead. The purpose is unmistakable and clearly distinct from weather-oriented siblings like get_forecast, but the description never explicitly differentiates itself from those siblings.

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 by the resource name and the note that it is 'Not available on the free tier,' which is a useful eligibility constraint. However, there is no explicit when-to-use guidance, no guidance on when to supply custom `variables` versus the defaults, and no routing away from alternatives such as get_forecast.

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 full load and does it well: it discloses that only locations with an active alert are returned, that an empty list is a valid all-clear signal, geographic coverage (USA/EU/Canada), and a tier/auth prerequisite. It does not state what happens for out-of-coverage coordinates or error behavior, leaving a small 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?

The core identity is front-loaded in the first line, then return-shape, cost profile, coverage, and access tier follow in short scannable clauses. No sentence is redundant.

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?

Without an output schema or annotations, the description still explains the return payload (event type, severity, validity window, headline), the empty-result case, coverage limits, and cost/access constraints. Only the undocumented 'language' parameter keeps it from being fully complete.

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 description adds a genuinely useful constraint absent from the schema: a hard cap of 20 locations. However, the top-level 'language' parameter is never mentioned, and location-input semantics (place_id vs lat/lon, label echo) are only covered by the schema's nested descriptions rather than the tool description itself.

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 ('Official weather warnings (severe weather alerts)') plus a clear scope limit of up to 20 locations. An agent can immediately separate this from get_forecast, get_air_quality, or search_places without inspecting the schema.

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 clear operating context: 'designed for monitoring/polling' and 'cheap to call frequently', and explains that an empty list means all clear, which tells the agent how to interpret results. It stops short of explicitly naming an alternative sibling (e.g. use get_forecast for outlooks) or stating when not to use it.

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 full burden, and it discloses meaningful traits: tier-gated horizons (free: 7 days), section availability by tier (minutely 'higher tiers', alerts 'startup tier and above'), timezone/unit defaults, and the flattened table output shape. It omits auth requirements, rate limits, and error behavior, but the tier and output disclosures go well 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?

Front-loaded with the purpose and capacity in the first sentence, then organized into labeled sections for parameters and output. It is dense but each sentence carries information; the output paragraph is somewhat long given no output schema exists to carry that load.

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 an 8-parameter tool with no annotations and no output schema, the description covers the essential gaps: forecast horizons per tier, section semantics, output table structure with flattened column naming, and unit/timezone behavior. An agent has enough to call it correctly without opening the schema.

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% at the top level, so the description must compensate, and it largely does: it enumerates valid `sections` values, explains that hourly is trimmed to `hours` and daily to `days`, names example `variables`, and defines `timezone` and `units` defaults. It leaves `language` and the `locations` array limits/shape unexplained, so it falls short of full 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?

States a specific verb+resource ('Weather forecast') with a stated capacity limit ('up to 20 locations in one call'), which clearly separates it from get_weather_history, get_air_quality, and get_solar_production. It does not address the overlap with get_alerts, even though its own 'alerts' section covers the same data, leaving that sibling distinction unstated.

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 rather than stated: it recommends using `variables` 'when querying many locations' and notes tier requirements per section, which is useful operational guidance. However, it never says when to prefer this tool over get_alerts, get_weather_history, or how to obtain a place_id before calling (search_places), so the routing decision is left to inference.

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 to lean on, the description carries the full behavioral burden and does so: it discloses the renewables-tier key requirement, the 400 site-day cap, one-request-per-site-day costing, caching of past days, per-site refusal of out-of-plan history, and the exact error wording. This is unusually thorough.

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?

Long but densely packed with no filler; the first sentence front-loads purpose and scale before drilling into site fields, date rules, granularity, columns and cost. It could be split for scannability, but almost every sentence carries actionable information.

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?

No output schema exists, yet the description defines the return shape (top-level `columns`, per-site `rows` arrays in column order) and the meaning of each production column. Combined with the auth, cost and error behavior, an agent has everything needed to call this 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?

Top-level schema coverage is reported as 0%, so the description must compensate, and it largely does: it explains module_kw=1 for specific yield, inverter_kw defaulting to module_kw, tilt/orientation defaults and azimuth convention, date format and bounds, granularity options and their limits, and the variables list. However, `units` and `timezone` are never explained anywhere.

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 ('Production of photovoltaic systems, past and forecast') plus scope ('up to 20 sites'), which cleanly separates it from the sibling get_wind_production. An agent can tell exactly what this returns without opening the schema.

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 concrete selection guidance for the granularity parameter (hourly capped at 14 days, daily/monthly at 366 days) and date window (20 years back to 4 days ahead), and warns that older days need a paid add-on. It stops short of explicitly routing to sibling tools, but the usage 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?

No annotations exist, so the description carries the full behavioral burden and does so: plan-based read limits, the exact error string for blocked old days reported per location, per-location-day billing, first-fetch request cost, caching of repeats, a 400 location-day call cap, max ranges per granularity, and rough response size. This is exactly the operational context an agent needs before invoking.

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?

Front-loaded with a single-line summary, then organized into access, granularity, variables/aggregations and output blocks. It is long but dense; a few clauses (e.g. the wind_power_density formula, repeated caps) could be trimmed without losing decision-relevant information.

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 an 8-parameter tool with no annotations and no output schema, the description is nearly complete, even sketching the return shape (top-level 'columns', per-location 'rows', ~15 kB for a year of daily data). The remaining gap is the unexplained units/timezone parameters and no explicit statement of the default units.

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% for top-level params, so the description must compensate and largely does: date format and inclusivity, granularity values with their caps, the full variables list with defaults, and the normals=true semantics. However, 'units' and 'timezone' are never explained in either schema or description, leaving two parameters undocumented.

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?

Opens with a specific verb+resource: 'Historical weather (archive) with server-side aggregation.' It is unambiguous that this is the retrospective/archive tool versus the forecast-oriented siblings, and the granularity/aggregation framing tells the agent exactly what kind of data it returns.

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?

Rich conditional guidance: plan-based access windows (startup 7 days, standard 1 year, premium/flexi 20 years, byvalue 366 days), the paid add-on for older days, per-granularity call caps, and when to split long ranges. It does not explicitly name a sibling alternative (e.g. get_forecast for future data), so it stops short of full when-not/exclusions guidance.

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 and does so well: it discloses the historical add-on boundary (last 3 years free, older days refused with 'historical data this old' reported per site), request billing (one API request per site+day, cached on repeats), the 400 site-days cap, and auth tier. It even sketches the return shape (columns at top level, rows as ordered arrays).

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?

Very long, but front-loaded with purpose and organized by concern (sites, dates, granularity, columns, variables, catalogue, cost). The turbine catalogue is bulky yet necessary because the schema explicitly points to it in the description; the rest is dense with no obvious filler.

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 7-parameter tool with no annotations and no output schema, the description covers nearly everything an agent needs: date rules, granularity trade-offs, cost model, failure modes, output layout, and the turbine catalogue. Minor gap: units and timezone parameters are never addressed.

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?

Top-level schema description coverage is 0%, so the description must compensate, and it largely does: turbine_model is tied to an inline catalogue (with the default SWT120/3600), roughness enum values and the farmland default are spelled out, hub_height default 100 m is stated, and the exactly-one-of turbine_count/total_capacity rule is explicit. It leaves units, timezone, and label unexplained, so not a 5.

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?

Opens with a specific verb+resource+scope: 'Production of wind farms, past and forecast, for up to 20 sites.' This clearly separates it from siblings like get_solar_production (different resource) and get_weather_history (production output vs raw weather).

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 rich context on when the call is viable: date window (20 years back to 4 days ahead), per-call caps (14 days hourly, 366 days daily/monthly, 400 site-days), and the renewables-tier key requirement. It never explicitly names an alternative sibling or a 'use X instead when' rule, so it stops short of a 5.

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, and it delivers useful behavior: result cap (up to 10), ordering by relevance, the returned field set, and the non-obvious degree-letter coordinate format quirk. It stops short of stating behavior on zero matches or any auth/rate-limit constraints, so not a full 5.

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 tight sentences, front-loaded with purpose, then usage, then return shape and the coordinate-format caveat. Every sentence earns its place; nothing is repeated from the 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?

With no output schema and no annotations, the description does the heavy lifting well, documenting return cardinality, ordering, fields, and coordinate encoding. Minor residue remains: undefined `language` behavior and unspecified no-match/error handling for a tool other agents depend on.

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%, so the description must compensate, and it does for three of four parameters: it defines `query` (place name or postal code) and the paired `lat`/`lon` semantics (nearest known place) plus their mutual exclusivity. The `language` parameter is never mentioned, leaving one 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 and resource ('Find locations and their Meteosource place_id') and immediately frames the tool's role relative to siblings: it produces place_id values consumed by the other weather tools. An agent can distinguish it from get_forecast/get_alerts without reading any schema.

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?

Explicitly says 'Use this first' and names the two alternative input modes with their selecting conditions: `query` for place name/postal code, `lat`+`lon` for nearest known place. This is exactly the when-to-use/when-to-use-which guidance the dimension asks for.

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