Skip to main content
Glama
Sign In
xippios-mcp

xippios-mcp

by xippios
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

usda_nass_get_county_yield

Read-onlyIdempotent

Retrieve USDA NASS county-level crop yield estimates for a commodity and year, optionally filtered by state, with units, utilization, and practice details.

Instructions

County yields of a crop for a year, one row per county, utilisation and practice.

Annual final estimates (statisticcat_desc YIELD, reference_period_desc YEAR) at agg_level_desc COUNTY, sorted by state, county, utilisation and practice. unit_desc names the unit, "BU / ACRE" for grain and "TONS / ACRE" for silage; value is the yield.

Args: commodity: Upstream commodity_desc, e.g. "CORN", "SOYBEANS", "WHEAT". year: Crop year, e.g. 2023. County estimates for a year appear the following spring. state: Two-letter state code to restrict to one state; None returns every county in the country, which stays under the 50,000-record limit for one crop and year.

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": {
      "commodity": "<commodity>",
      "year": "<year>"
    },
    "name": "usda_nass_get_county_yield"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearYes
stateNo
commodityYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely non-derivable behavior: the 50,000-record ceiling, that omitting state still stays under that ceiling for one crop-year, the deterministic sort order, and how unit_desc and value should be interpreted. It does not describe error behavior or whether an unsupported commodity/state returns empty versus an error, which keeps it from a 5.

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?

The scope statement is front-loaded, followed by a clean Args block with one entry per parameter, so an agent can scan it quickly. Minor waste: 'utilisation and practice' appears both in the opening sentence and again in the sort clause, and the nested backtick markup adds visual noise without information.

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 three-parameter read tool with no output schema, the description supplies row granularity, sorting, the meaning of key returned fields (unit_desc, value), unit conventions for grain versus silage, data-availability timing and the result-size bound. That is enough for an agent to call it correctly and interpret the response without guessing.

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

Parameters4/5

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

Schema description coverage is 0%, so the description carries the burden and mostly does: commodity is tied to upstream commodity_desc with concrete examples, year is a crop year with the spring-availability caveat, and state is explained as an optional two-letter filter whose None value changes scope to the entire country. The state explanation adds scope semantics beyond the enum list in $defs. Commodity validation rules (must the string be uppercase? what happens on unknown values?) remain unaddressed.

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?

The description names a specific resource and scope: county-level crop yields, one row per county/utilisation/practice, for a given year. It pins the exact statistic (statisticcat_desc YIELD, reference_period_desc YEAR, agg_level_desc COUNTY), which makes it clearly distinguishable from the county-production and national production siblings. It stops short of explicitly naming a sibling as the alternative, so it lands at 4 rather than 5.

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?

Usage is implied rather than stated: an agent can infer this is the county-grain-yield source and that estimates lag the crop year by a spring release. There is no explicit when-to-use/when-not-use guidance, e.g. no pointer to usda_nass_get_county_production for volumes instead of per-acre yields, and no statement about coverage for non-grain crops.

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

Deploy Server

Other Tools