USDA farmland values and county cash rents for AI agents. NASS data, 3 tools, free, no key.
Scored across 3 tools
Each tool targets a distinct dataset or purpose: cash rents, land values, and coverage metadata. Descriptions explicitly cross-reference alternatives ('use get_land_values instead for land values', 'use list_coverage to confirm'), leaving no realistic path to misselection.
Consistent snake_case verb_noun pattern throughout (get_cash_rents, get_land_values, list_coverage). Verbs are chosen appropriately per operation type (get for data, list for enumeration).
Three tools is on the thin side, but each earns its place for a narrowly scoped read-only survey dataset: two data endpoints plus one coverage probe. Nothing feels redundant or padded.
The surface covers both datasets plus a coverage/introspection tool, which is the right shape for a read-only survey lookup. Minor gaps exist — no aggregation or trend/time-series helper, and county-level land values are unavailable by survey design — but these are documented workarounds rather than dead ends.
County cash rents in dollars per acre, from the USDA NASS annual Cash Rents survey — each row is one county (or an 'OTHER COUNTIES' aggregate) in one year and one practice category (irrigated_cropland, non_irrigated_cropland, or pasture), with the average rent in USD per acre. Use for what farmland rents for; use get_land_values instead for land values (what the land is worth), and list_coverage to check covered states, counties, and years. Read-only lookup of stored survey data; no API key. The survey is annual and the stored copy refreshes once a year after the August NASS release — the latest stored year is 2026. state takes a two-letter code (case-insensitive), county a county name exactly as stored (uppercase, e.g. 'HANCOCK'), and year a single survey year. Returns up to limit rows (default 1000), newest year first; a filter combination with no stored rows returns a no-data result rather than an empty list.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Survey year as an integer, e.g. 2026 (currently the only stored year — see list_coverage) | |
| limit | No | Max rows to return (default 1000, max 1000) | |
| state | No | Two-letter state code, e.g. 'IA' (case-insensitive; stored uppercase) | |
| county | No | County name exactly as stored (uppercase, e.g. 'HANCOCK'); some rows are 'OTHER COUNTIES' aggregates covering counties NASS does not publish individually |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/no-destructive, and the description adds genuinely non-structured context: no API key needed, the data refreshes once a year after the August NASS release, the latest stored year is 2026, results are sorted newest-year-first, and a no-match filter returns a no-data result rather than an empty list. That last detail materially changes how an agent should interpret the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the resource and grain, then usage routing, then storage/behavioral caveats — every sentence carries information. It is dense and long for a single-paragraph description, with some repetition between the prose and the schema, which keeps it off a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description takes on the burden of describing return values and does so: rows keyed by county, year, practice category with average USD/acre, up to `limit` rows default 1000, newest first, no-data result semantics. Nothing an agent needs in order to call or interpret this tool is missing.
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 100%, so the baseline is 3; the description goes modestly beyond by restating the state case-insensitivity, the exact-match uppercase county convention and OTHER COUNTIES aggregates, and by tying `limit` to the newest-year-first ordering. It adds ordering/return-shape meaning rather than new per-parameter syntax, so a 4 rather than 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?
States a specific verb and resource ('County cash rents in dollars per acre... USDA NASS annual Cash Rents survey') and defines the row grain precisely (one county or OTHER COUNTIES aggregate, per year, per practice category). It explicitly distinguishes itself from get_land_values and list_coverage, so the agent can route without opening schemas.
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?
'Use for what farmland rents for; use get_land_values instead for land values... and list_coverage to check covered states, counties, and years' gives explicit when-to-use plus two named alternatives with the condition that selects each. No exclusions are left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Average farmland values in dollars per acre by state, from the USDA NASS annual Land Values survey — each row is one state, year, and land category (farm_real_estate for the headline farm-real-estate value including buildings, cropland, or pasture) with its per-acre value (USD/acre). Use for what farmland is worth; use get_cash_rents instead for what it costs to rent, and list_coverage to confirm which states and years are stored before querying. Read-only lookup of stored survey data; no API key. The survey is annual and the stored copy refreshes once a year after the August NASS release — the latest stored year is 2026. state takes a two-letter code (case-insensitive) and year a single survey year; land values are state-level, so county fields are empty and a county filter normally matches nothing. Returns up to limit rows (default 1000), newest year first; a filter combination with no stored rows returns a no-data result rather than an empty list.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Survey year as an integer, e.g. 2026 (currently the only stored year — see list_coverage) | |
| limit | No | Max rows to return (default 1000, max 1000) | |
| state | No | Two-letter state code, e.g. 'IA' (case-insensitive; stored uppercase) | |
| county | No | County name as stored (uppercase, e.g. 'HANCOCK'). Accepted for parity with the REST endpoint and get_cash_rents, but land values are state-level rows with no county, so this normally matches nothing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent safety, and the description adds substantial context beyond them: no API key, annual refresh after the August NASS release, latest stored year is 2026, state-level rows mean county filters match nothing, newest-year-first ordering, and a no-data result instead of an empty list.
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?
A single dense paragraph that front-loads what the tool returns and then the disambiguation, with no filler sentences. It is on the long side but each clause carries distinct information (grain, units, alternatives, cadence, parameter quirks).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still tells the agent the row shape, units, default/max limit, ordering, and the no-data behavior, so an agent can both select and invoke this correctly without further probing.
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 100%, so the baseline is 3; the description still adds real meaning by clarifying that `state` is case-insensitive two-letter and `year` is a single survey year, and by flagging that `county` normally matches nothing despite being accepted for parity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Average farmland values in dollars per acre by state, from the USDA NASS annual Land Values survey') and defines the row grain (state, year, land category) with per-acre units. It is unmistakable next to get_cash_rents and list_coverage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing: 'Use for what farmland is worth; use get_cash_rents instead for what it costs to rent, and list_coverage to confirm which states and years are stored before querying.' Both alternatives and their selecting conditions are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists what the Farmland API actually holds: row counts and the year range for each dataset (land values and cash rents), the total number of distinct states and counties covered, and the state codes present in each dataset. Use before get_land_values or get_cash_rents to confirm a state or year is covered — the stored data is currently a single survey year, 2026 — or to size a query. Read-only; no API key. This mirrors the REST /v1/status summary and adds the per-dataset state lists. It takes no parameters.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, non-destructive), so the description adds value by disclosing no API key is needed, that it mirrors the REST /v1/status summary plus per-dataset state lists, and that the underlying data is a single 2026 survey year. The data-staleness disclosure is genuinely useful context not available in annotations; a minor gap is no note on response size or cost, though for a no-param status call that is negligible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the payload contents, then the when-to-use guidance, then the caveat. Four clauses with minimal waste, though the enumeration of return fields is slightly dense and could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining returns and does so thoroughly: counts, year ranges, totals, and state lists. Combined with the data-freshness caveat and no-param confirmation, an agent has everything needed to call it and interpret the result.
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?
Zero parameters, so the baseline applies; the description correctly closes with 'It takes no parameters', removing any doubt. No further parameter meaning is possible here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Lists what the Farmland API actually holds') and then enumerates the exact payload: row counts, year range per dataset, distinct state/county totals, and per-dataset state codes. This is clearly distinguishable from the sibling getters, which retrieve data rows rather than coverage metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use before get_land_values or get_cash_rents to confirm a state or year is covered ... or to size a query', naming both siblings and the conditions that select them. It also warns that stored data is currently a single survey year, 2026, which directly prevents wasted calls.
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.
get_cash_rentsget_land_valueslist_coverageUSDA farm data for AI agents: grain, fertilizer, WASDE, export sales. 27 tools, free, no key.
NOAA weather for AI agents: conditions, forecasts, observed history. 3 tools, free, no key.
Primary-source commodities data for AI agents — EIA, FRED, CFTC, USDA, USGS via x402 on Base.
Crypto yield data for AI agents: lending, savings, staking, borrowing & stablecoin rates. 18 tools.
Add one secure layer between your agents and this server.
