Provides access to historical daily climate data since 1981 via the NASA POWER API, enabling AI agents to retrieve and analyze long-term agricultural climate patterns and site assessment data.
MCP server providing AI agents with agriculture and farming data — soil conditions, crop weather, climate history, global statistics, and food products.
soil_conditions — Soil temperature (0-54cm), moisture, evapotranspiration forecast
crop_weather_forecast — Agricultural weather: temp, rain, wind, radiation, water balance
climate_history — Historical daily climate data since 1981 (NASA POWER)
climate_averages — Long-term monthly climate averages for site assessment
country_agriculture_profile — Full agriculture profile of any country
compare_countries — Compare agriculture indicators across countries
food_product_lookup — Look up food products by barcode (nutrition, eco-scores)
food_search — Search 3M+ food products by name or category
Related MCP server: CropProphEU
pip install agriculture-mcp-server.mcp.json:
{
"mcpServers": {
"agriculture": {
"type": "stdio",
"command": "python",
"args": ["-m", "src.server"]
}
}
}All APIs are free and require no API key:
API | Data |
Open-Meteo | Soil temperature, moisture, evapotranspiration, crop weather |
NASA POWER | Historical climate data since 1981 (agricultural community) |
World Bank | Country-level agriculture statistics (20+ indicators) |
Open Food Facts | 3M+ food products with nutrition and eco-scores |
MIT
Langjährige Klimamittelwerte für einen Standort (NASA POWER).
Zeigt monatliche Durchschnittswerte für Temperatur, Niederschlag, Solarstrahlung und Bodenfeuchtigkeit (2001-2020). Ideal zur Standortbewertung für neue Anbauflächen.
Args: lat: Breitengrad lon: Längengrad
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses data source (NASA POWER), specific time range (2001-2020), and return content (monthly averages for four metrics) despite having no annotations to rely on.
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?
Well-structured with clear separation between general description and Args section; every sentence conveys essential 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?
Appropriately complete for a simple 2-parameter tool; explains return values (necessary due to missing output schema) and covers data provenance and ideal use case.
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?
Compensates effectively for 0% schema description coverage by providing German translations and semantic meaning for lat/lon parameters in the Args section.
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?
Clearly states it retrieves long-term climate averages (2001-2020) from NASA POWER for temperature, precipitation, solar radiation and soil moisture, implicitly distinguishing it from the sibling 'climate_history' through the specific averaging period.
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?
Provides a specific use case ('Ideal für Standortbewertung für neue Anbauflächen') but lacks explicit guidance on when to prefer this over 'climate_history' or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Historische Agrar-Klimadaten für einen Standort (NASA POWER, ab 1981).
Zeigt Temperatur, Niederschlag, Solarstrahlung, Bodenfeuchtigkeit und Evapotranspiration. Perfekt für Standortbewertung und Klimaanalyse.
Args: lat: Breitengrad lon: Längengrad start_date: Startdatum (YYYYMMDD, z.B. "20240601") end_date: Enddatum (YYYYMMDD, z.B. "20240630")
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| start_date | Yes | ||
| end_date | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses data source (NASA POWER) and temporal coverage (ab 1981), but omits other behavioral traits like rate limits, authentication requirements, or return format structure.
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?
Well-structured with front-loaded key information (source, date range, metrics); Args section efficiently documents parameters 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?
Adequate for the tool's low complexity, though absence of output schema could have been mitigated by describing the return structure beyond listing metrics.
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?
Excellent compensation for 0% schema description coverage by providing parameter meanings (German translations) and critical format examples (YYYYMMDD) in the Args section.
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?
Clearly states it retrieves historical agricultural climate data from NASA POWER (since 1981) and lists specific metrics (temperature, precipitation, solar radiation, soil moisture, evapotranspiration); 'historical' distinguishes it from sibling forecast 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?
Mentions implied use cases (site evaluation, climate analysis) but lacks explicit guidance on when to use this versus climate_averages or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Agrar-Indikator zwischen Ländern vergleichen.
Args: countries: Länder-Codes getrennt mit Semikolon (z.B. "DEU;USA;BRA;IND;CHN") indicator: Indikator-Name (z.B. "cereal_yield", "arable_land_pct", "fertilizer_consumption", "agriculture_gdp_pct") year_range: Zeitbereich (z.B. "2020" oder "2018:2023")
| Name | Required | Description | Default |
|---|---|---|---|
| countries | Yes | ||
| indicator | No | cereal_yield | |
| year_range | No | 2018:2023 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fails to disclose return format, error handling for invalid country codes, data sources, or rate limits; only provides input format hints.
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?
Appropriately brief, front-loaded with purpose statement, followed by structured Args section with clear formatting guidance.
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?
Critical gap given no output schema exists: fails to describe what data structure is returned (time series, aggregates, comparison metrics) or data coverage limitations.
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?
Effectively compensates for 0% schema description coverage by providing concrete examples for all three parameters (country code format, indicator examples, year range syntax).
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 specific action (compare) and resource (agricultural indicators between countries) clearly in German, though lacks explicit differentiation from sibling 'country_agriculture_profile'.
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?
Provides no guidance on when to use this versus 'country_agriculture_profile' or other alternatives, nor any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Komplettes Agrar-Profil eines Landes.
Zeigt Ernteerträge, Landnutzung, Produktionsindizes, Düngereinsatz, Agrar-Anteil am BIP und Beschäftigung. Quelle: World Bank.
Args: country: ISO3-Ländercode (z.B. "DEU", "USA", "BRA", "IND", "CHN")
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses data source (World Bank) which is valuable behavioral context given no annotations, but omits error handling, data freshness, or rate limit information.
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?
Extremely concise with no fluff; front-loaded purpose followed by data specifics, source attribution, and parameter definition.
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?
Adequately covers the simple single-parameter input and compensates for missing output schema by enumerating returned data categories.
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?
Excellently compensates for 0% schema description coverage by specifying the ISO3 format and providing concrete examples (DEU, USA, BRA, IND, CHN).
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?
Clearly states it retrieves comprehensive agricultural profiles listing specific metrics (yields, land use, GDP share) that distinguish it from weather-focused siblings like climate_averages and product-focused food_search.
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?
Provides no explicit guidance on when to use versus alternatives (e.g., when to use this instead of crop_weather_forecast for agricultural planning).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Agrar-Wetter-Vorhersage für einen Standort.
Zeigt Temperatur, Niederschlag, Wind, Sonnenstrahlung und Evapotranspiration — optimiert für Landwirtschaft und Pflanzenbau.
Args: lat: Breitengrad lon: Längengrad days: Vorhersage-Tage (1-16)
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses what data is returned (temp, precipitation, wind, etc.) but lacks information on rate limits, caching, or side effects given no annotations exist.
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?
Well-structured with purpose front-loaded, followed by output details and Args section; every sentence provides unique value without repetition.
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?
Appropriately complete for the tool's complexity; mentions agricultural optimization and specific output metrics to compensate for missing output 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?
Effectively compensates for 0% schema description coverage by defining all three parameters and adding the critical 1-16 day range constraint not present in the schema.
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?
Clearly states it provides agricultural weather forecasts with specific ag-focused metrics (evapotranspiration, solar radiation) and distinguishes from siblings via 'Vorhersage' (forecast) versus historical climate 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?
Provides no guidance on when to use this versus climate_averages/history or other weather-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lebensmittel per Barcode nachschlagen.
Zeigt Nährwerte, Nutri-Score, Eco-Score und NOVA-Gruppe. Quelle: Open Food Facts (3+ Millionen Produkte).
Args: barcode: EAN/UPC Barcode (z.B. "3017620422003" für Nutella)
| Name | Required | Description | Default |
|---|---|---|---|
| barcode | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return data (Nährwerte, Nutri-Score, Eco-Score, NOVA-Gruppe) and data source (Open Food Facts) despite no annotations or output 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?
Well-structured with purpose, return value, source, and args sections; every sentence adds value; appropriately brief.
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?
Explains return values comprehensively given lack of output schema; single parameter is adequately documented.
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?
Compensates for 0% schema description coverage by specifying format (EAN/UPC) and concrete example (Nutella barcode).
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?
Specific verb+resource ('Lebensmittel per Barcode nachschlagen') clearly distinguishes from sibling food_search and agriculture/climate 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?
Implies usage context through 'per Barcode' but lacks explicit when/when-not guidance regarding food_search alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lebensmittel suchen nach Name oder Kategorie.
Args: query: Suchbegriff (z.B. "organic rice", "chocolate") category: Kategorie-Filter (z.B. "cereals", "dairy", "beverages") limit: Max. Ergebnisse (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| category | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and description lacks disclosure of return values, rate limits, or side effects beyond the basic search operation.
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 purpose statement followed by structured Args documentation; appropriately concise though could benefit from additional behavioral context.
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?
Covers basic invocation needs (purpose + parameters) but gaps remain regarding output format and sibling tool differentiation given the agricultural domain complexity.
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?
Compensates effectively for 0% schema coverage by providing descriptions and examples for all 3 parameters (query, category, limit) in the Args section.
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 clear action ('Lebensmittel suchen') and resources (by name/category) but fails to differentiate from sibling 'food_product_lookup'.
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?
No guidance on when to use versus alternatives like 'food_product_lookup' or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aktuelle und prognostizierte Bodenbedingungen für einen Standort.
Zeigt Bodentemperatur (0-54cm Tiefe), Bodenfeuchtigkeit und FAO-Evapotranspiration. Ideal für Aussaat-Entscheidungen und Bewässerungsplanung.
Args: lat: Breitengrad (z.B. 52.52 für Berlin) lon: Längengrad (z.B. 13.41 für Berlin) days: Vorhersage-Tage (1-16, Standard: 7)
| Name | Required | Description | Default |
|---|---|---|---|
| lat | Yes | ||
| lon | Yes | ||
| days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Provides concrete behavioral details absent from annotations: soil depth range (0-54cm) and forecast horizon (1-16 days), though omits rate limiting or error 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?
Well-structured with purpose front-loaded, followed by specific metrics, use cases, and Args section; no redundant or filler content.
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 no output schema exists, description adequately specifies return values (soil temp, moisture, FAO evapotranspiration) for the tool's moderate complexity.
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?
Effectively compensates for 0% schema description coverage by providing concrete examples (Berlin coordinates) and constraint documentation (1-16 range, default 7) for all parameters.
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?
Clearly states it retrieves current and forecasted soil conditions (temperature at 0-54cm depth, moisture, evapotranspiration), specifically distinguishing it from climate and crop weather 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?
Explicitly identifies ideal use cases (sowing decisions, irrigation planning) but lacks explicit guidance on when to prefer crop_weather_forecast or climate tools instead.
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. Dates show when Glama detected each change.
v0.1.2climate_averagesclimate_historycompare_countriescountry_agriculture_profilecrop_weather_forecastfood_product_lookupfood_searchsoil_conditionsTools are generally well-differentiated by domain (climate vs. soil vs. country stats vs. food). The pair `climate_averages` and `climate_history` could cause slight confusion as both retrieve historical NASA POWER climate data for a location, though they are distinguished by monthly averages versus specific date ranges. Food tools are clearly separated by barcode lookup versus text search.
Most tools follow a consistent noun_phrase pattern (e.g., `climate_averages`, `soil_conditions`, `country_agriculture_profile`). However, `compare_countries` uses a verb_noun structure, creating a minor deviation from the otherwise consistent convention. All use snake_case consistently.
Eight tools is an appropriate count for this scope, covering field-level environmental data (climate averages, history, forecasts, soil), macro-level country agricultural statistics (profile and comparison), and food product databases (search and lookup) without redundancy or bloat.
The toolset provides comprehensive read-only coverage across distinct agricultural data domains: temporal climate data (past averages, historical range, forecasts), soil conditions, country-level indicators, and food product information. No obvious CRUD gaps exist for a data-retrieval server, though it lacks analytical tools that might combine these datasets (e.g., crop suitability scoring).
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Unlock the power of food transparency with our Open Food Facts MCP server. Easily look up any food
This MCP server provides seamless access to Malaysia's government open data, including datasets, w…
Brazilian foreign trade, crop and commodity data as a remote MCP server. Exports and imports from MDIC/ComexStat since 2000, by HS code (SH4/SH6/NCM) and partner country, in USD FOB and kilograms — plus crop production, supply-and-demand balances, climate readings and production forecasts for hubs such as soybean, coffee, corn, beef and cocoa. Every comparison is like-for-like: two windows of equal length, each labelled with the period it actually measures, and every answer names its window and its source. 14 read-only tools, metered in credits. Nothing to install: Streamable HTTP at https://mcp.kyrodata.com/mcp with a bearer key or OAuth 2.1 (PKCE). Official registry: com.kyrodata/kyrodata.
Hosted MCP server for Xweather weather data: conditions, forecasts, alerts, and more.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AiAgentKarl/agriculture-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
