agrobr-mcp gives LLMs real-time access to Brazilian agricultural data from 10+ public sources (CEPEA/ESALQ, CONAB, IBGE, NASA POWER, INPE, B3), covering prices, crop production, climate, and deforestation.
preco_diario — Fetch daily spot prices for 15 commodities (soybeans, corn, cattle, coffee, cotton, etc.) from CEPEA/ESALQ, up to 60 recent days
futuros_b3 — Retrieve daily settlement prices for agricultural futures contracts (corn, cattle, coffee, ethanol, soybeans) traded on the B3 exchange
estimativa_safra — Get current crop season estimates (area, production, yield) by state for 7 crops including soybeans, corn, rice, and coffee (CONAB/IBGE)
producao_anual — Access historical annual crop production by state for 12 crops (soybeans, corn, sugarcane, cassava, oranges, etc.) from IBGE PAM
balanco — View supply and demand balance sheets (stocks, consumption, exports) for major crops from CONAB
progresso_safra — Track weekly planting and harvesting progress by state for 6 crops from CONAB
clima — Retrieve climate data (temperature, precipitation, radiation, humidity, wind) for any Brazilian state, aggregated daily or monthly, from NASA POWER
desmatamento — Query annual deforestation rates (PRODES) or real-time alerts (DETER) by biome (Amazon, Cerrado, Atlantic Forest, etc.) from INPE
listar_produtos — Discover valid products and parameters for any tool before making a call
health_check — Verify the status of all underlying data source APIs to diagnose errors or outages
Accesses NASA POWER data to provide climate information by state, including temperature, precipitation, and radiation metrics.
Click on "Install 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., "@agrobr-mcp Show me the current soybean prices and harvest progress in Brazil"
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.
MCP server that gives LLMs access to real-time Brazilian agricultural data — prices, crop estimates, climate, deforestation and more from 10 public sources from agrobr.
pip install agrobr-mcpRelated MCP server: Base dos Dados MCP
Add to claude_desktop_config.json:
{
"mcpServers": {
"agrobr": {
"command": "python",
"args": ["-m", "agrobr_mcp"]
}
}
}Settings > MCP Servers > Add:
{
"agrobr": {
"command": "python",
"args": ["-m", "agrobr_mcp"]
}
}claude mcp add agrobr python -- -m agrobr_mcpIf the above fails due to
-mflag parsing, create a wrapper script:Linux/macOS:
echo 'python -m agrobr_mcp' > run.sh && chmod +x run.sh && claude mcp add agrobr ./run.shWindows:
echo python -m agrobr_mcp > run.bat && claude mcp add agrobr run.bat
docker build -t agrobr-mcp .
docker run --rm -i agrobr-mcpAdd to claude_desktop_config.json:
{
"mcpServers": {
"agrobr": {
"command": "docker",
"args": ["run", "--rm", "-i", "agrobr-mcp"]
}
}
}10 tools available out of the box:
Tool | Description |
| Daily spot prices for agricultural commodities (CEPEA/ESALQ) |
| Daily settlement prices for agricultural futures on B3 exchange |
Tool | Description |
| Current crop season estimate by state (CONAB/IBGE) |
| Historical annual production by state (IBGE PAM) |
| Supply and demand balance — stock, consumption, exports (CONAB) |
| Weekly planting and harvesting progress by state (CONAB) |
Tool | Description |
| Climate data by state — temperature, precipitation, radiation (NASA POWER) |
| Deforestation rates and real-time alerts by biome (INPE) |
Tool | Description |
| List valid products for each tool |
| Check status of all data sources |
"Qual o preço da soja nos últimos 5 dias?"
"Estimativa de safra de milho por estado"
"Progresso da colheita de soja"
"Dados de desmatamento na Amazônia"
"Quais produtos estão disponíveis?"User (natural language)
│
MCP Client (Claude Desktop / Cursor / Claude Code)
│
agrobr-mcp (this server — thin layer, text formatting)
│
agrobr library (data collection, parsing, caching)
│
19 public APIs (CEPEA, CONAB, IBGE, INPE, B3, NASA POWER…)agrobr-mcp is a thin wrapper. All data logic lives in the agrobr library.
git clone https://github.com/bruno-portfolio/agrobr-mcp.git
cd agrobr-mcp
pip install -e ".[dev]"
# Run tests
pytest tests/ -m "not integration" -v
# Lint
ruff check src/ tests/
ruff format src/ tests/MIT
Servidor MCP que dá acesso a dados agrícolas brasileiros em tempo real para LLMs. Preços, safras, clima, desmatamento e mais — tudo de fontes públicas como CEPEA, CONAB, IBGE, INPE e B3.
pip install agrobr-mcpAdicione ao seu client MCP (Claude Desktop, Cursor ou Claude Code) conforme as instruções acima.
docker build -t agrobr-mcp .
docker run --rm -i agrobr-mcppreco_diario — Preço spot de commodities agrícolas (CEPEA/ESALQ)
futuros_b3 — Ajustes diários de futuros agrícolas na B3
estimativa_safra — Estimativa da safra corrente por UF (CONAB/IBGE)
producao_anual — Produção histórica por UF (IBGE PAM)
balanco — Balanço de oferta e demanda (CONAB)
progresso_safra — Progresso semanal de plantio e colheita (CONAB)
clima — Dados climáticos por UF (NASA POWER)
desmatamento — Taxa de desmatamento e alertas por bioma (INPE)
listar_produtos — Lista produtos válidos por tool
health_check — Status das fontes de dados
agrobr library — biblioteca de dados agrícolas
MCP Protocol — Model Context Protocol
mcp-name: io.github.bruno-portfolio/agrobr
Supply and demand balance (stock, consumption, exports).
Products: soja, milho, arroz, feijao, algodao, trigo, cafe.
Args:
produto: Crop name (e.g. "soja", "milho")
| Name | Required | Description | Default |
|---|---|---|---|
| produto | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the tool returns supply and demand balance data for specified crops, which is adequate for a simple read operation. However, it does not mention potential errors, rate limits, or data availability conditions.
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 extremely concise: two sentences covering purpose and parameter. It is front-loaded and every word adds value without extraneous 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?
Given the tool's simplicity (one required parameter, output schema exists), the description fully covers the necessary context. It explains what the tool does and how to use the parameter, making it complete for selection and 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?
The input schema has 0% description coverage, so the description compensates well. It specifies the parameter 'produto' as a crop name and provides examples ('soja', 'milho'), along with a full list of valid products. This adds clear meaning beyond 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?
The description clearly states the tool provides supply and demand balance data for specific crops. It mentions the resource (balance) and lists valid products, distinguishing it from sibling tools like clima or preco_diario. However, it lacks an explicit verb like 'get' or 'fetch'.
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 usage when needing stock, consumption, or exports data, but it does not provide explicit when-not-to-use guidance or alternatives. Sibling tools exist for similar data (e.g., estimativa_safra, producao_anual) but no differentiation is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent climate data by state (temperature, precipitation, radiation, humidity, wind).
Valid states: AC, AL, AM, AP, BA, CE, DF, ES, GO, MA, MG, MS,
MT, PA, PB, PE, PI, PR, RJ, RN, RO, RR, RS, SC, SE, SP, TO.
Args:
uf: State abbreviation (e.g. "MT", "PR", "RS")
ano: Year (default: current year)
agregacao: "diario" or "mensal" (default: "mensal")
| Name | Required | Description | Default |
|---|---|---|---|
| uf | Yes | ||
| ano | No | ||
| agregacao | No | mensal |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It describes the data fields and parameters but does not disclose whether the operation is read-only, any limitations on data range, or error behavior. It is minimally 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 concise and well-structured: one line for purpose, a bulleted list of valid states, and a clear parameter section. Every sentence adds value with no 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?
Given the presence of an output schema, the description does not need to detail return values. It covers purpose, parameters, and valid inputs adequately. Could mention data coverage (recent years) or output format but overall complete for a simple retrieval 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?
With 0% schema description coverage, the description fully compensates by explaining each parameter's meaning, including a list of valid state abbreviations, default values, and allowed values for 'agregacao'. This adds significant value beyond 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?
The description clearly states 'Recent climate data by state' with specific data types (temperature, precipitation, radiation, humidity, wind), providing a specific verb (retrieve) and resource (climate data) that distinguishes it from 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?
The description lists valid states and default values but does not explicitly mention when to use this tool versus alternatives (e.g., 'desmatamento' or 'balanco'). It implies use for climate queries but lacks exclusions or comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deforestation rates and alerts by biome.
Biomes: amazonia, cerrado, mata_atlantica, caatinga, pampa, pantanal.
Systems: prodes (annual rate), deter (real-time alerts).
Args:
bioma: Biome name (e.g. "amazonia", "cerrado")
sistema: "prodes" (annual) or "deter" (alerts)
| Name | Required | Description | Default |
|---|---|---|---|
| bioma | No | amazonia | |
| sistema | No | deter |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not explicitly state that the tool is read-only or safe. The purpose (rates and alerts) implies data retrieval, but behavioral traits like idempotency or resource consumption are not disclosed.
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, uses bullet points for readability, and front-loads the core purpose. The 'Args' section is well-structured. Every sentence serves a purpose 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?
Given the presence of an output schema, the description adequately covers parameter semantics and purpose. However, it lacks a note on the tool's read-only nature or any prerequisites, which would make it more complete for a tool with no annotations.
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?
With 0% schema description coverage, the description adds significant value by enumerating valid biome names (amazonia, cerrado, etc.) and system types (prodes, deter) with explanations. This goes beyond the schema's minimal type and title 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 description clearly states the tool returns deforestation rates and alerts by biome, with a specific list of biomes and systems. It differentiates itself from sibling tools (e.g., clima, estimativa_safra) which handle other environmental or agricultural data.
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 lists valid inputs (biomes and systems) but does not provide explicit guidance on when to use this tool versus alternatives like clima or preco_diario. Usage is implied by the topic, but no when-not-to-use or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current crop season estimate by state (area, production, yield).
Products: soja, milho, arroz, feijao, algodao, trigo, cafe.
Args:
produto: Crop name (e.g. "soja", "milho")
safra: Crop season in "YYYY/YY" format (default: current season)
| Name | Required | Description | Default |
|---|---|---|---|
| produto | Yes | ||
| safra | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description makes clear this is a read operation (estimate query). Adds context on product list and default season. Could mention aggregation level more explicitly.
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 concise: one sentence for purpose, one line listing products, two lines for parameters. No redundant 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?
Has output schema (assumed covers return format), description mentions state-level data and components (area, production, yield). Adequate for typical use, though could explicitly mention that results are per state.
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?
Input schema has zero description coverage; description fully explains parameters: produto with examples of crop names, safra with format and default. Adds significant meaning beyond 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 current crop season estimates by state (area, production, yield) and lists specific products, differentiating it from sibling tools focused on other agricultural metrics.
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?
Indicates it provides estimates by state and lists parameters, but does not explicitly state when to use this tool over alternatives like balanco or clima.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily settlement prices for agricultural futures on B3 exchange.
Contracts: boi_gordo, milho, cafe_arabica, cafe_conillon,
etanol, soja_cross, soja_fob.
Args:
contrato: Futures contract name (e.g. "milho", "boi_gordo")
data: Date in "YYYY-MM-DD" format (default: today)
| Name | Required | Description | Default |
|---|---|---|---|
| contrato | Yes | ||
| data | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read-only data retrieval operation ('Daily settlement prices'), lists parameters, and gives examples. It does not mention authentication, rate limits, or error behavior, but for a simple query tool, these omissions are acceptable. No contradiction with annotations (none present).
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: a single sentence stating purpose, a comma-separated list of contracts, and two parameter lines. No wasted words. The most important information is front-loaded.
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 data retrieval tool with an output schema present (context signal), the description covers input parameters, valid contracts, and date format. No further details about return values are needed. The description is complete enough for an agent to use the tool effectively.
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 has 0% description coverage, leaving the description to explain parameters fully. The description adds value by listing valid contract names, specifying the date format 'YYYY-MM-DD' with a default of today, and providing examples (e.g., 'milho'). This is far beyond what the schema provides.
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 it provides 'Daily settlement prices for agricultural futures on B3 exchange' and lists specific contracts (e.g., boi_gordo, milho). This distinguishes it from siblings like preco_diario, which likely handles spot prices. The verb+resource combination is specific and 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 implicitly suggests use for retrieving agricultural futures settlement prices, but does not explicitly state when to use this tool versus alternatives like preco_diario or balanco. No exclusions or context for when not to use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of agrobr data sources.
Returns which APIs are responding and which have issues. Useful to diagnose when a tool returns an error.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully conveys that it is a read-only diagnostic tool that returns status information, which is sufficient for its simple purpose.
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 extremely concise with two sentences that front-load the purpose and provide immediate value, with no 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?
Despite no parameters or annotations, the description fully covers what the tool does and when to use it, which is adequate for a simple health check tool with an 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?
There are no parameters, and the schema coverage is 100%, so the description does not need to add parameter information beyond what is already clear.
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 verb 'Check the status' and the resource 'agrobr data sources', distinguishing it from sibling tools that provide specific data.
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 provides explicit guidance that the tool is useful for diagnosing when other tools return errors, but does not mention when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List valid products/parameters for each agrobr-mcp tool.
Useful to discover which values to pass before calling another tool.
If no tool is specified, lists all.
Args:
tool: Tool name (e.g. "preco_diario"). Empty = all tools.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only listing operation but does not explicitly state safety, rate limits, or other behavioral traits. It discloses the basic behavior but lacks depth.
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 short, with front-loaded purpose and no unnecessary words. It achieves clarity in two sentences and a concise parameter description.
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 simplicity of the tool and the presence of an output schema (not shown), the description covers the main purpose and usage. Missing error handling or result details, but it is largely complete for a discovery 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?
The description adds significant meaning beyond the schema, explaining the 'tool' parameter with an example and default behavior. Since schema coverage is 0%, this compensation is valuable and clear.
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 lists valid products/parameters for each tool, which distinguishes it from sibling data tools. However, the phrase 'products/parameters' is slightly ambiguous, preventing a top score.
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 mentions it is useful for discovering values before calling another tool, providing clear context. It does not explicitly state when not to use it or name alternatives, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily spot prices for Brazilian agricultural commodities (CEPEA/ESALQ).
Products: soja, milho, boi_gordo, cafe_arabica, cafe_robusta,
algodao, trigo, arroz, acucar, etanol_hidratado, etanol_anidro,
frango_congelado, suino, leite, laranja_industria.
Args:
produto: Commodity name (e.g. "soja", "milho", "boi_gordo")
dias: Number of recent days to return (default: 5, max: 60)
| Name | Required | Description | Default |
|---|---|---|---|
| produto | Yes | ||
| dias | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the function as retrieving daily prices, which is a read operation, but does not disclose any behavioral traits like rate limits, data freshness, or required 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 description is concise with a main sentence and a bullet-style Args list. Every sentence provides value, no redundancy, and information is front-loaded.
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 simplicity (2 parameters, output schema present), the description fully covers purpose, valid inputs, and parameter constraints. The output schema handles return value documentation, so completeness is achieved.
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?
With 0% schema coverage, the description compensates by listing example products ('soja', 'milho') and specifying defaults and constraints for 'dias' (default 5, max 60). This adds meaning beyond the schema's type and required 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 description clearly states it provides daily spot prices for Brazilian agricultural commodities, lists products and parameters. However, it does not explicitly differentiate from sibling tools like balanco or clima, which also deal with agricultural data.
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 includes parameter details and defaults but lacks explicit guidance on when to use this tool versus alternatives like estimativa_safra or futuros_b3. Usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Historical annual crop production by state (IBGE PAM).
Products: soja, milho, arroz, feijao, algodao, trigo, cafe,
cana_de_acucar, mandioca, laranja, cacau, sorgo.
Args:
produto: Crop name (e.g. "soja", "milho")
ano: Reference year (default: previous year)
| Name | Required | Description | Default |
|---|---|---|---|
| produto | Yes | ||
| ano | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only lists parameters and examples, but does not state that it is read-only, idempotent, or any side effects. Lacks behavioral context.
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?
Description is concise, uses bullet points for products, and clearly separates args. Efficient but lacks some detail.
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?
Has output schema but description does not explain return format (e.g., units, per-state data). Given no annotations and low schema coverage, it leaves significant gaps for an agent to know how to interpret results.
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%. Description adds list of allowed crop names for 'produto' and notes default year for 'ano' (previous year), but 'ano' default in schema is 0, which may be ambiguous. Provides some value beyond schema but incomplete.
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 historical annual crop production by state from IBGE PAM. Lists example products. Distinguishes from siblings like estimativa_safra (estimate) and preco_diario (price), but does not explicitly differentiate.
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 this tool versus alternatives. Does not mention prerequisites, limitations, or recommended contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Weekly planting and harvesting progress by state.
Products: soja, milho, arroz, feijao, algodao, trigo.
Args:
produto: Crop name (e.g. "soja", "milho")
uf: State abbreviation filter (e.g. "MT", "PR"). Empty = all states.
| Name | Required | Description | Default |
|---|---|---|---|
| produto | Yes | ||
| uf | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention side effects, authentication needs, rate limits, data freshness, or read-only nature, leaving significant gaps.
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 very concise, with a single introductory sentence and a bullet-like list for parameters. Every sentence is necessary and efficiently conveys the 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?
Given the simplicity (2 params, one required) and presence of an output schema, the description adequately covers purpose and parameters. However, it lacks behavioral transparency and usage guidance, leaving gaps in completeness for a tool with no annotations.
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 value beyond the schema (which has 0% coverage) by explaining both parameters: the list of crop names and the state filter with default behavior. It provides examples and clarifies usage, though it could be more explicit about valid values.
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 purpose: 'Weekly planting and harvesting progress by state.' It specifies the resource and verb, lists the products, and explains parameters, making it distinct from siblings like 'estimativa_safra' or 'preco_diario'.
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 instructions (specify product, optionally state, empty for all) but does not explicitly guide when to use this tool over alternatives, nor does it mention exclusions or context.
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.2balancoclimadesmatamentoestimativa_safrafuturos_b3health_checklistar_produtospreco_diarioproducao_anualprogresso_safraEach tool covers a distinct aspect of agricultural data: balance, climate, deforestation, crop estimates, futures prices, spot prices, annual production, planting progress, plus utilities. There is no significant overlap.
Names are mostly noun phrases with underscores (e.g., estimativa_safra, preco_diario) but include one verb (listar_produtos) and one English term (health_check), creating mild inconsistency.
With 10 tools covering key data categories for Brazilian agribusiness, the count is well-scoped—neither too few nor too many for the domain.
The set covers major areas: production, prices, weather, deforestation, balance, and progress. Minor gaps like export/storage data exist, but the core is robust.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
MCP server giving AI agents one-connection access to China A-share market intelligence: financials,
The Dappier MCP server connects LLMs and AI agents to real-time, rights-cleared, proprietary data from trusted sources across various domains. It provides specialized knowledge through real-time web search, financial stock market and crypto data access, AI-powered content recommendations from premium publishers, and structured outputs with sub-300ms response times, enabling AI systems to respond to current events and trends.
MCP server giving AI agents one-connection access to crypto & DeFi data: DeFi protocol TVL, stableco
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bruno-portfolio/agrobr-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
