Skip to main content
Glama

usda_nass_get_census_farms

Read-onlyIdempotent

Retrieves Census of Agriculture farm counts or land in farms for a given year, nationally, by state, or by county. Use it to compare farm totals across places.

Instructions

Census of Agriculture farm counts or land in farms for a year, national, by state or county.

The farm totals of the five-yearly Census (source_desc CENSUS, group_desc FARMS & LAND & ASSETS, commodity_desc FARM OPERATIONS, class_desc ALL CLASSES, prodn_practice_desc ALL PRODUCTION PRACTICES, domain_desc TOTAL), so the breakdowns by farm size, sales class, typology, organization and the like are left out; get_data reaches them. unit_desc tells the rows of one place apart: for OPERATIONS the number of farms ("OPERATIONS") and, above the county level, "PCT OF FARM OPERATIONS"; for AREA OPERATED the land in farms ("ACRES"), "ACRES / OPERATION", "ACRES / OPERATION, MEDIAN", "PCT OF TOTAL LAND" and, above the county level, "PCT OF AG LAND", as the 2022 Census publishes them; another year may carry fewer. value is the figure as published and value_number its parsed form; cv_percent is the coefficient of variation, None where upstream prints a code such as "(L)" or "(H)" in its place. Sorted by state, county and unit. Every county of the country is a large answer (2022: 3,078 rows for OPERATIONS, 12,312 for AREA OPERATED, counted 2026-10-28), well under the 50,000-record limit: the MCP tool returns its first rows within the result cap (64 KB, about 100 rows, a projected row being about 600 bytes) with a note, so give state there. A state's counties are cut too past about 100 rows, so for AREA OPERATED, four rows a county, a state of more than about 25 counties is cut.

Args: year: A Census year, e.g. 2022 or 2017; the Census of Agriculture is taken every five years, and a year without rows under these filters raises NotFoundError. statistic: FarmStatistic.OPERATIONS (the number of farms) or FarmStatistic.AREA_OPERATED (land in farms). state: Two-letter state code, e.g. StateAlpha.IA: that state's figures, or with by_county its counties'. None returns the national US TOTAL figures, or with by_county every county of the country. The 2022 Census counts no state rows for StateAlpha.PR, and a code without rows raises NotFoundError. by_county: True returns county figures (agg_level_desc COUNTY), of state when given; False, the default, the state or national ones.

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": {
      "year": "<year>",
      "statistic": "<statistic>"
    },
    "name": "usda_nass_get_census_farms"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearYes
stateNo
by_countyNo
statisticYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, open-world behavior, but the description adds substantial context they cannot: expected row volumes (3,078 / 12,312), the 64 KB / ~100-row result cap with truncation notes, sorting order, `cv_percent` being None when upstream emits codes like "(L)", and NotFoundError on unknown year or state. Only the return-value shape beyond field names (e.g. how the truncation note is expressed) is left implicit.

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

Conciseness4/5

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

Purpose is front-loaded in sentence one and the content is ordered purpose → scope boundary → return fields → size limits → parameters. It is long and occasionally over-precise ("counted 2026-10-28", "about 600 bytes"), but nearly every sentence carries decision-relevant information; a modest trim would make it a 5.

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?

There is no output schema, yet the description documents the returned fields (`value`, `value_number`, `cv_percent`, `unit_desc` variants), the sort order, and the truncation behavior. Combined with the year/state/statistic failure modes, an agent has everything needed to call this correctly and interpret the response.

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?

Top-level schema coverage is effectively nil (no property-level descriptions), so the Args block carries the load and does so thoroughly: `year` is a five-yearly Census year that raises NotFoundError if absent, `statistic` is spelled out as farm count vs land in farms, `state` explains None → US TOTAL or all counties plus the PR exception, and `by_county` explains the agg_level_desc switch and its default. This more than compensates for the 0% coverage.

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

Purpose5/5

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

The first sentence names the exact resource (Census of Agriculture farm counts and land in farms), the grain (year, national/state/county), and the description later pins down the precise upstream slice (CENSUS / FARM OPERATIONS / ALL CLASSES / TOTAL), which separates it from generic siblings. It also explicitly names usda_nass_get_data as the tool for the breakdowns this one omits.

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

Usage Guidelines5/5

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

It states when to use this tool (the farm-total slice) versus when to reach for get_data (farm size, sales class, typology, organization breakdowns), and adds operational routing advice: supply `state` when pulling county rows because of the result cap. Exclusion and alternative are both explicit.

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