Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@agro-weather-mcp check the frost risk for my orchard near Davis, CA this week"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
agro-weather-mcp is a public, open-source MCP server that gives LLMs compact,
agriculture-focused weather tools backed by the free Open-Meteo APIs. It uses
stdio only, needs no hosting, API key, or secret, and is intended for farmers,
agronomists, and agricultural software experiments.
With uv:
uvx --from git+https://github.com/rajshivang07/agro-weather-mcp agro-weather-mcpFor local development:
git clone https://github.com/rajshivang07/agro-weather-mcp
cd agro-weather-mcp
uv sync --extra dev
uv run agro-weather-mcpRelated MCP server: open-meteo-mcp-server
This server is useful anywhere an MCP-compatible assistant needs agriculture weather context without building a custom Open-Meteo integration. It runs as a local process over stdio, so users do not need to operate a web server, deploy cloud infrastructure, or create an API key.
Typical users and environments include:
Farmers who want a conversational way to check frost risk, recent water balance, or soil conditions for a field.
Agronomists and crop advisors who need quick GDD calculations and weather summaries during field planning.
Farm-management and precision-agriculture software teams that want reusable weather tools in an LLM workflow.
Researchers and students prototyping crop-weather assistants without paying for a weather data service.
Developers building local assistants in Claude Desktop, Claude Code, MCP Inspector, or another MCP-compatible client.
Teams testing agricultural workflows before connecting them to their own field records, sensors, or farm databases.
Example workflows include:
Geocode a farm, then inspect current and 48-hour soil conditions before discussing sowing timing.
Calculate seasonal GDD from historical archive data and extend the range into the forecast when appropriate.
Check the next 7 days for overnight frost exposure before recommending a field visit or crop-protection review.
Compare precipitation with reference ET0 to identify periods that deserve closer soil-moisture monitoring.
Use the five standardized tools as a weather layer inside a larger farm assistant, while keeping farm-specific decisions in the application that owns the field data.
This project is best suited to local development, personal assistants, demos, education, research, and non-commercial prototypes that respect Open-Meteo's free-tier terms and rate limits. It is not a replacement for a farm's weather station, irrigation model, crop model, regulated advisory service, or local agronomic expertise. Outputs are informational and should be reviewed before being used in operational decisions.
Add this entry to the Claude Desktop MCP configuration:
{
"mcpServers": {
"agro-weather": {
"command": "uvx",
"args": ["--from", "git+https://github.com/rajshivang07/agro-weather-mcp", "agro-weather-mcp"]
}
}
}claude mcp add agro-weather -- uvx --from git+https://github.com/rajshivang07/agro-weather-mcp agro-weather-mcpgeocode_location: find candidate places and coordinates.
get_growing_degree_days: calculate capped, modified-average GDD across past and forecast dates.
get_frost_risk: summarize overnight minimums, threshold hours, and risk levels.
get_water_balance: compare precipitation with FAO-56 reference ET0 and explain dryness.
get_soil_conditions: summarize current and 48-hour soil temperature and moisture by depth.
The tools are task-oriented interpretations of Open-Meteo data. The rule-based notes and risk labels below are generated by this MCP server. They are not text provided by the Open-Meteo APIs.
Every tool response includes the resolved date range, timezone, units, and
data_source: "Open-Meteo (CC BY 4.0)". Coordinates are validated before a
request is made. Invalid coordinates, dates, date ranges, counts, or forecast
horizons return actionable tool errors.
geocode_locationInput:
{
"name": "Davis",
"country_code": "US",
"count": 3
}name is required. country_code is optional and must be a two-letter ISO
country code. count defaults to 3 and must be between 1 and 10.
The result contains candidate places with:
name
admin_area
country
latitude and longitude in degrees
elevation in metres
timezone as an IANA timezone name
This tool has no user-supplied dates, so its resolved date range is the current date. Use the returned coordinates with the other tools.
get_growing_degree_daysInput:
{
"lat": 38.54,
"lon": -121.74,
"start_date": "2026-04-01",
"end_date": "2026-04-30",
"base_temp_c": 10.0,
"upper_cap_c": 30.0,
"method": "modified_avg"
}Dates use inclusive YYYY-MM-DD format. The range can be at most 366 days.
Past dates use the archive endpoint, future dates use the forecast endpoint,
and a range crossing today is split and merged automatically. Future dates are
limited by the forecast horizon of 16 days from today.
The current method is modified_avg. For each day, Tmin and Tmax are clamped
to the inclusive range [base_temp_c, upper_cap_c], then calculated as:
GDD = ((clamped Tmax + clamped Tmin) / 2) - base temperatureThe response contains total accumulated GDD in degree-days. For ranges of 31 days or fewer it also contains daily values. Longer ranges contain weekly GDD summaries instead. Missing daily temperatures produce a null daily value and are excluded from the total.
get_frost_riskInput:
{
"lat": 35.68,
"lon": 139.65,
"days": 7,
"threshold_c": 0.0
}days must be between 1 and 16. threshold_c is in degrees Celsius. The
server requests hourly temperature_2m forecasts and returns each detected
night's minimum temperature and the number of hours below the threshold.
Risk is assigned using these server rules:
none: zero hours below the threshold
low: minimum temperature is above threshold_c - 2 °C
moderate: minimum temperature is above threshold_c - 5 °C
high: minimum temperature is at or below threshold_c - 5 °C
The result is forecast-only and covers the current date through the requested number of forecast days in the resolved local timezone.
get_water_balanceInput:
{
"lat": 52.52,
"lon": 13.41,
"start_date": "2026-06-01",
"end_date": "2026-06-30"
}Dates use inclusive YYYY-MM-DD format and the range can be at most 366 days.
The server combines daily precipitation and
et0_fao_evapotranspiration, both in millimetres, using:
water balance = precipitation - reference ET0The response contains total precipitation, total ET0, total balance, weekly
balance summaries, and a server-generated dryness_note:
Balance at least 10 mm: Likely water surplus
Balance greater than -10 mm: Roughly balanced
Balance at or below -10 mm: Likely drying conditions; monitor soil moisture and irrigation needs
The note is a simple weather-based interpretation. It is not an irrigation recommendation and does not model crop type, soil storage, runoff, or field conditions.
get_soil_conditionsInput:
{
"lat": 42.36,
"lon": -71.06
}The server requests current and approximately 48 hours of forecast data for the available depths:
0_to_7cm
7_to_28cm
28_to_100cm
100_to_255cm
Soil temperature is returned in degrees Celsius. Soil moisture is volumetric
water content in m³/m³. Each depth contains current values plus next-48-hour
minimum, maximum, and average statistics for both variables.
The response also contains this clearly labeled rough sowing guide:
Many crops prefer about 8-10 °C at seed depth.This is not a crop-specific threshold or agronomic recommendation. Actual sowing decisions should use crop-specific local guidance, soil conditions, and field observations.
Example prompts:
“Find the three closest matches for Davis, California, then calculate April GDD using a 10 C base.”
“What is the frost risk for this location over the next seven days at 0 C?”
“Was the last month wetter or drier than reference crop demand?”
“What are the current and next-48-hour soil conditions at this location?”
Data comes from Open-Meteo, attributed as Open-Meteo (CC BY 4.0). The archive tool uses ERA5-style historical data and forecast requests use the Open-Meteo forecast API. Open-Meteo's free tier is for non-commercial use and has rate limits. Check the Open-Meteo terms and documentation for current limits before deploying repeated or commercial workloads.
Outputs are informational and are not agronomic advice. Weather, soil, crop, and management decisions require local expertise and appropriate observations.
Run the server through the MCP Inspector with the project command configured as
uv run agro-weather-mcp and transport set to stdio. The Inspector can list the
five tools and invoke them with JSON arguments without needing a hosted endpoint.
uv sync --extra dev
uv run ruff check .
uv run ruff format --check .
uv run pytestLive smoke tests are excluded by default. Set RUN_LIVE=1 to run them.
Find candidate places by name.
Returns up to count candidates, where count is 1 through 10. Latitude and
longitude are degrees, elevation is metres, and timezone is an IANA name.
This tool has no date input and resolves the range to the current date. Example:
geocode_location("Davis", "US", 3).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| count | No | ||
| country_code | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose useful behavior: a count of 1-10, units for latitude/longitude/elevation/timezone, and that no date input exists. However, the sentence 'resolves the range to the current date' is confusing and seemingly irrelevant for a geocoder, and nothing is said about no-match behavior or permissions.
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 definition is front-loaded with the purpose, followed by concrete constraints and a compact example. The 'no date input / current date' sentence is dead weight for this tool and slightly undermines an otherwise tight structure.
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 three-parameter tool with an output schema, the description supplies purpose, the count cap, return-unit conventions, and an example. The only real gap is the unexplained country_code behavior and the out-of-place date remark.
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. It adds the count range (1-10) beyond the bare integer schema and demonstrates country_code via the example, but it never explains country_code semantics or the behavior when it is omitted.
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 opening sentence 'Find candidate places by name' gives a specific verb and resource, making it unmistakably a forward-geocoding tool, distinct from the agronomic siblings. It lacks any explicit mention of siblings, but differentiation is obvious from the domain.
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 example call and by the nature of the tool (resolving a place name to coordinates), but there is no explicit statement of when to use it, prerequisites, or what to do when a name is ambiguous or unmatched.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess overnight frost risk for the next 1 to 16 forecast days.
threshold_c is degrees Celsius and days is a forecast horizon. A night is
low risk when its minimum is above threshold minus 2 C, moderate when it is
above threshold minus 5 C, and high at or below threshold minus 5 C. Any
hours below threshold make risk at least low. The result includes per-night
minimum temperature and hours below threshold, in the forecast timezone.
Example: get_frost_risk(45.52, -122.68, 7, 0.0).
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| days | No | ||
| threshold_c | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 defines the risk bands, explains that any hours below threshold make risk at least low, and states that results include per-night minimum temperature and hours below threshold. It does not cover operational concerns such as data source or limits, but the core behavior is transparent.
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 compact and front-loads the purpose before explaining risk semantics and output contents. Each sentence adds useful information, though the threshold explanation is somewhat detailed relative to the rest.
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 that an output schema exists and no annotations are provided, the description is nearly complete for correct invocation. It covers purpose, forecast range, threshold semantics, risk classification, and result contents, with only minor gaps around coordinate formatting.
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 0%, so the description must compensate. It defines threshold_c as degrees Celsius, defines days as a forecast horizon, states the valid 1 to 16 range, and the example clarifies the positional order of lat, lon, days, and threshold_c.
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 and resource: assess overnight frost risk for a forecast horizon. It is clearly distinct from the sibling tools, but it does not explicitly differentiate itself from alternatives such as get_growing_degree_days or get_soil_conditions.
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 makes the intended context clear through the 1 to 16 day forecast horizon and frost-risk framing. However, it gives no explicit when-to-use guidance or comparison against sibling tools, so an agent must infer the selection conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate accumulated growing degree days from daily temperatures.
Dates use ISO YYYY-MM-DD and the inclusive range is at most 366 days.
Temperatures and base/cap are degrees Celsius. The modified-average method
clamps Tmin and Tmax to the base and upper cap before averaging. Daily values
are returned for ranges up to 31 days, otherwise weekly summaries. Past dates
use ERA5 archive data and future dates use the forecast, merged when needed.
Example: get_growing_degree_days(38.54, -121.74, "2025-04-01", "2025-04-30").
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| method | No | modified_avg | |
| end_date | Yes | ||
| start_date | Yes | ||
| base_temp_c | No | ||
| upper_cap_c | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden well: it discloses the modified-average clamping behavior, daily versus weekly aggregation, ERA5 archive versus forecast data sourcing, and merging behavior. It does not discuss error handling, authentication, or rate limits, but the core behavioral traits are unusually transparent.
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 dense and front-loaded: it leads with the core operation, then documents date rules, units, method behavior, aggregation, data sources, and an example. Every sentence adds practical information without redundancy.
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 has an output schema, so return-value details need not be fully repeated. The description still covers date limits, units, aggregation granularity, and data sourcing, but it omits possible method alternatives and any limitations around coordinate validity or errors.
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 most parameters: date format and range, temperature units, base/cap semantics, and the modified-average method. It does not explain possible values for the method parameter beyond the default method's behavior, leaving a small 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?
The description states a specific verb and resource: "Calculate accumulated growing degree days from daily temperatures." This clearly identifies the agricultural metric and distinguishes it from sibling tools such as get_frost_risk or get_water_balance.
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 useful operating constraints, such as an inclusive date range of at most 366 days and daily versus weekly output. However, it does not explicitly state when to choose this tool over siblings or when not to use it; usage is implied rather than directly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize current and next-48-hour soil conditions.
Soil temperature is degrees Celsius and soil moisture is volumetric water
content in m³/m³ at the available 0-7, 7-28, 28-100, and 100-255 cm depths.
The forecast covers the current time through approximately 48 hours in the
resolved timezone. The sowing note is a rough guide only: many crops prefer
about 8-10 C at seed depth, but crop, soil, and local practice matter.
Example: get_soil_conditions(42.36, -71.06).
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well: it discloses units (Celsius, m³/m³), the four depth bands returned, the ~48-hour forecast horizon, timezone resolution behavior, and a caveat that the sowing note is a rough guide. It does not address error behavior or data source, which keeps it below a 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?
The purpose is front-loaded in the first sentence, followed by units, forecast window, caveat, and example in a logical order. Every sentence carries information; the caveat sentence is the only slightly padded one.
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 (two required numeric params) and an output schema exists, so return structure needn't be explained. The description covers semantics, units, horizon, and the interpretive caveat, leaving only coordinate validity/error handling unstated.
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 0% and neither lat nor lon has a description. The example call conveys decimal-degree coordinates and the lat-then-lon ordering, and the negative longitude implicitly signals the hemisphere convention, but no ranges or validation rules are given.
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 opens with a specific verb and resource (summarize soil conditions) plus an explicit temporal scope (current + next 48 hours). It is clearly distinguishable from siblings like get_frost_risk and get_water_balance by the soil temperature/moisture subject matter, though no sibling is named.
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 only implied: the sowing note context hints at agricultural decision-making use, but there is no explicit statement of when to prefer this over get_growing_degree_days or get_water_balance, nor any preconditions (e.g., that coordinates must already be resolved).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate precipitation minus reference evapotranspiration.
Dates use ISO YYYY-MM-DD, are inclusive, and span at most 366 days.
Precipitation, ET0, and the resulting balance are millimetres. ET0 is
et0_fao_evapotranspiration for a well-watered reference grass field.
Results include total precipitation, total ET0, total balance, weekly
breakdowns, and a plain-language dryness note. Past and future ranges are
merged from archive and forecast data. Example: get_water_balance(52.52, 13.41, "2025-06-01", "2025-06-30").
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| end_date | Yes | ||
| start_date | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 declares units (millimetres), defines ET0 as et0_fao_evapotranspiration for well-watered reference grass, discloses the 366-day span limit and the archive/forecast merge behavior, and previews the returned artifacts. Gaps remain around coordinate system expectations and error/failure behavior, which prevents a 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?
The core computation is front-loaded in sentence one, followed by usage constraints, output summary, and a concrete example — every element earns its place. It is on the longer side, but 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?
An output schema exists, so the description only needs to orient the agent on what comes back — and it does (totals, weekly breakdowns, dryness note). Combined with the date/span constraints and example, an agent has enough to invoke it correctly; only coordinate-system specifics are left implicit.
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 largely does: ISO YYYY-MM-DD date format, inclusivity, and the 366-day maximum are all documented, and the worked example (52.52, 13.41) conveys lat/lon order and approximate meaning. It stops short of stating WGS84/decimal-degree units or coordinate validity ranges, 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?
The description opens with a specific verb-plus-computation: 'Calculate precipitation minus reference evapotranspiration.' This is a precise, distinguishable resource that an agent can easily tell apart from siblings like get_growing_degree_days or get_frost_risk without opening 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?
It gives clear applicability context: dates are inclusive, span at most 366 days, and past/future ranges are merged from archive and forecast data — which tells the agent when the tool works as expected. It does not explicitly exclude cases or name alternatives among the siblings, so it falls 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0geocode_locationget_frost_riskget_growing_degree_daysget_soil_conditionsget_water_balanceScored across 5 tools
Each tool covers a clearly distinct agronomic concept: place lookup, growing degree days, frost risk, water balance, and soil conditions. There is virtually no overlap—the shared lat/lon/date signature is a consistent input convention, not a source of confusion, and the descriptions make each tool's specific output obvious.
All names follow a clean verb_noun snake_case pattern (geocode_location, get_growing_degree_days, get_frost_risk, get_water_balance, get_soil_conditions). The only minor deviation is 'geocode_location' using a domain-specific verb 'geocode' instead of the otherwise dominant 'get_' prefix, but it is still readable and predictable.
Five tools is a tight, well-scoped set for a focused agro-weather service, with each tool covering a distinct analytical need. Nothing feels redundant or missing at the count level; it sits comfortably in the ideal 3-15 range.
The surface covers geocoding plus the core agronomic analytics (GDD, frost, water balance, soil), giving a coherent lifecycle for planning decisions. However, there is no general-purpose raw weather forecast or daily temperature/precipitation retrieval tool, which agents might reasonably expect from an agro-weather server as a fallback.
Global weather via Open-Meteo: forecast, historical, marine, air quality, geocoding, elevation.
OpenWeather data for AI agents: list feeds, sign up, check balance, get a top-up link, fetch data.
NOAA weather for AI agents: conditions, forecasts, observed history. 3 tools, free, no key.
USDA farm data for AI agents: grain, fertilizer, WASDE, export sales. 27 tools, free, no key.
