Skip to main content
Glama

Exterior painting weather and drying check

exterior_weather_check
Read-onlyIdempotent

For a UK postcode (or latitude and longitude) and dates from today up to 8 days ahead, fetches the hourly forecast (MET Norway) and checks each working hour against typical limits for the paint type: minimum temperature, humidity, 3 C above dew point, rain chance, wind, and a rain-free drying time after each coat. Returns each day's verdict (good, good_but_watch_rain, marginal, no), the best painting window, the main problems and an indicative recoat time at that day's temperature. Pass the data sheet's own limits to override. Example: {"postcode":"LS1 4AP","paint_type":"water_based_masonry","start_date":"2026-11-14","end_date":"2026-11-18"}.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "exterior_weather_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
tradeNoOptional. The decorator's own business details (Nero Trade Profile v1). Used to prefill quotes and to give a stable nero_trade_ref. Not stored by Brush Pack.
end_dateNoYYYY-MM-DD, at most 15 days after today. Defaults to start + 6 days.
end_hourNoWorking day end. Defaults to 17.
latitudeNo
postcodeNoFull UK postcode of the job.
longitudeNo
min_temp_cNoMinimum application temperature from the data sheet.
paint_typeNowater_based_masonry: Water-based masonry paint, from 8 C, humidity up to 80%, 4 h rain free; solvent_based_masonry: Solvent-based (pliolite type) masonry paint, from 5 C, humidity up to 85%, 2 h rain free; water_based_trim: Water-based exterior gloss or satin for wood, from 8 C, humidity up to 80%, 3 h rain free; solvent_based_trim: Solvent-based (oil) exterior gloss or undercoat, from 5 C, humidity up to 85%, 4 h rain free; wood_stain_water: Water-based wood stain, from 8 C, humidity up to 80%, 4 h rain free; wood_stain_solvent: Solvent-based wood stain, from 5 C, humidity up to 85%, 4 h rain free; metal_paint: Solvent-based metal paint, from 5 C, humidity up to 85%, 4 h rain free
start_dateNoYYYY-MM-DD, today or later. Defaults to today.
start_hourNoWorking day start, 24 hour clock. Defaults to 8.
rain_free_hoursNoHours the coat must stay dry after it goes on.
recoat_hours_at_20cNoRecoat time at 20 C from the data sheet.
max_humidity_percentNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior3/5

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

Adds real value beyond the read-only/idempotent annotations: reveals the external data source (MET Norway, hence openWorld), the forecast horizon, and the shapes of the verdict and best-window results. However, it states a horizon of 'up to 8 days ahead' while the schema allows end_date 'at most 15 days after today', so an agent may wrongly reject valid requests — an internal inconsistency that undercuts trust in the stated constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single dense but front-loaded paragraph: inputs, then processing, then return values, then override note, then example. Almost every clause carries information, though the first sentence runs long enough that the input/processing boundary is easy to lose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by enumerating the returned verdicts, best painting window, problems, and indicative recoat time. Gaps remain around failure modes (non-UK postcode, requests past the horizon, API outage) and around the date-range conflict with the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 77%, so the baseline is 3; the description earns an extra point by explaining that postcode and lat/lng are alternatives, that start_date/end_date bound the forecast horizon, and that the caller's data-sheet limits (min_temp_c, rain_free_hours, recoat_hours_at_20c) override built-in paint_type defaults. The worked example JSON maps fields to intended usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb chain (fetches hourly forecast, checks each working hour) plus the resource (MET Norway forecast for a UK postcode/lat-lng) and the domain limits applied (temperature, humidity, dew point, rain, wind, drying time). No sibling tool (job_estimate, lead_paint_risk, paint_quantity) could be confused with it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operating context: UK postcode or lat/lng, dates from today up to 8 days ahead, and that the caller may pass data-sheet limits to override defaults. It does not name an alternative tool or state when-not-to-use, but the sibling set is clearly disjoint in purpose.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.