Skip to main content
Glama

usda_nass_get_data

Read-onlyIdempotent

Fetches USDA NASS Quick Stats estimates for filtered queries. It pre-counts results and splits by year to handle data over the 50,000-record limit.

Instructions

Fetch published Quick Stats estimates for a set of filters, up to 50,000 records a call.

Without split_by_year, calls get_counts first: a count of zero returns an empty result without a second call, and a count above 50,000 raises QueryTooLarge with the count and a hint (narrower filters, or split_by_year) before anything is fetched. With split_by_year, a two-sided year range is fetched year by year, each year counted first and no count of the range sent; year__GE alone is counted first and split by year only when that count is above 50,000; year is counted first, and above 50,000 still raises QueryTooLarge. meta.total is the count get_counts reported, 0 for the empty result, and the yearly counts summed for a split. Each record carries every Quick Stats column; value is the published figure as a string ("510,000", or a suppression code such as "(D)") and value_number the parsed number.

Args: filters: Quick Stats columns, optionally suffixed with an operator, mapped to values; the same shape and the same checks as for get_counts: an unknown value of a packaged parameter raises UnknownCode naming the list, its fetch date and the closest known values, or pointing at list_param_values (the tool usda_nass_list_param_values) when none is close. A query that stays well under the limit names the commodity, the statistic, the level and the time, e.g. {"commodity_desc": "CORN", "statisticcat_desc": "AREA PLANTED", "agg_level_desc": "STATE", "state_alpha": "VA", "year": 2012}. Quick Stats keeps one bound on year per query (recorded 2026-10-28): it counts year__GE with year__LE as year__GE alone, in either order, and drops year__GE beside year__LT, so a two-sided year range is served only by split_by_year. split_by_year: True fetches the years one at a time where one call cannot serve them, splitting one call into at most 20 years in Python and over HTTP and 5 by default on the MCP server, whose --split-years sets 1 to 20. The filters bound the years in one of three forms, checked before any call: year (2022), year__GE with year__LE (2020 and 2023), or year__GE alone, up to the current UTC year. Another year filter (year__LE alone, year__GT, year__NE, ...), a mix or none raises InvalidRequestError naming the three forms, and a year__GE or year__LE past the current UTC year raises it naming that year. year is counted and fetched once, as without the flag; over the limit it raises QueryTooLarge naming the year. year__GE with year__LE is always split, without a count of the range, which Quick Stats would count as year__GE alone; more years than the ceiling raise InvalidRequestError naming it before any call. year__GE alone is counted first and fetched once when the count is within the limit, however far back it starts; over the limit it is split, and more years than the ceiling raise InvalidRequestError naming it after that count, before the split. A split counts each year with year=<y> in place of the year filters, every year before the first fetch, so a year over 50,000 on its own raises QueryTooLarge naming it before anything is fetched; it then fetches each year holding records, the records in year order, each year's in upstream's order. A year counting 0 is skipped: it has no records, or none published yet, which Quick Stats does not tell apart; meta.vintage stays None, since Quick Stats names no release. Cost: up to two keyed calls per year, plus the first count for year__GE alone, paced at 30 a minute, so 5 years take up to 11 calls and 20 years up to 41, about 80 seconds. meta.request carries split_by_year beside the filters. False, the default, never splits.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "filters": "<filters>"
    },
    "name": "usda_nass_get_data"
  }
}

Input Schema

NameRequiredDescriptionDefault
filtersYes
split_by_yearNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only cover readOnly/idempotent/openWorld; the description goes far beyond them, disclosing the pre-flight count call, precisely which errors fire and in what order (QueryTooLarge, InvalidRequestError, UnknownCode), the 30-calls-per-minute pace, and the call/time budget (5 years ≈ 11 calls, ~80 seconds). It also documents that a zero-count year is silently skipped and that the empty case still returns meta.total=0, which an agent could not otherwise infer.

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

Conciseness3/5

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

The purpose is front-loaded and the error/cost facts are valuable, but the piece runs roughly 600 words for two parameters and covers the same three year-filter forms three times (header paragraph, split_by_year section, and split sub-section). Implementation leakage such as 'in Python and over HTTP and 5 by default on the MCP server, whose --split-years sets 1 to 20' and the 'recorded 2026-10-28' note consume space without helping an agent decide or invoke.

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

Completeness5/5

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

For a tool with no output schema, a nested untyped filter object, and a complex split pathway, the description covers everything an agent needs: input shape, operator behavior, failure modes, ordering of results across a split, the record payload (value vs value_number), and meta fields including meta.total and meta.request. Nothing material is left to guesswork.

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

Parameters5/5

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

Schema coverage is 0% and the nested filters object is opaque (additionalProperties only), so the description carries the full burden and does so: it explains the column-plus-operator suffix convention, which year operators Quick Stats actually honors and which it silently drops, and supplies a complete literal example. split_by_year is given exact semantics for each accepted year-filter form plus the default and server-side ceiling.

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

Purpose4/5

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

Opens with a specific verb and resource: 'Fetch published Quick Stats estimates for a set of filters, up to 50,000 records a call', which immediately tells the agent what it gets and the hard cap. It does not, however, distinguish this generic fetch tool from the many specialized siblings (usda_nass_get_production, usda_nass_get_prices_received, usda_nass_get_crop_progress, etc.), so an agent cannot tell from this text alone when the raw endpoint beats the named shortcut.

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

Usage Guidelines3/5

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

Selection guidance is only implied: the worked filter example ('a query that stays well under the limit names the commodity, the statistic, the level and the time') sketches a good usage pattern, and list_param_values is named as the escape hatch for unknown codes. There is no explicit statement of when to prefer this tool over the dozens of commodity-specific siblings, and no when-not-to-use guidance beyond the size ceiling.

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